Can you tell if this ECB mode mitigation idea is "OK"? The context: you have to encrypt passwords (reversible, for accessing external services), and also some customer data for privacy reasons, and you need to use AES-ECB mode...

The idea to mitigate the worst of ECB is, we encrypt each single ''message'' with a new random key. Then we encrypt this unique key with a master key, and store it alongside the ''message'', while the master key is kept somewhere else completely.

(As additional measure, also ensuring that the encrypted unique key has its padding block filled with randoms, so the padding doesn't show up as repeating pattern either between the unique keys.)

When considering the general ECB issues, I take note of the fact that: 


the master key will ever encrypt only random, single-block ''messages'' (the unique keys), and that 
the most critical data to be protected is passwords, also of a single-block nature.


Makes any sense? Has any major issue? I was mainly concerned with avoiding the textbook-messup situation of an ecb mode password db where you could see every repetition of common passwords, making for extremely easy, non-specialist ''attacks''.
As already mentioned, if you've got ECB you can certainly design other modes of operation. Probably the easiest one to implement is CTR mode: you simply line up a number of counters (each of the block size of the underlying cipher) and then encrypt them using ECB. You can XOR the result with the plaintext to encrypt or decrypt data.

You'd still have to use a nonce for the initial counter value of course, if you want to reuse the same key.



Limiting passwords to a certain size is a bad idea. So is storing an encrypted password instead of storing a hash of the password.

If you use CTR mode I'd say limit the password size to 64 bytes and pad the password to that size using zero padding - then encrypt the result. That way you'd allow longer passwords and you would not leak the password size right away.