Yes, thanks for the clarification, it only increases the time by preventing the use of rainbow tables (or, nowadays, simply googling the hash).

The advantage is that many people use the same password on multiple systems, so revealing a plaintext password to, say, Slashdot may also reveal your bank password. A hashed password can't be used to directly log into another account, though it can be cracked by a determined attacker if the password is simple. A salted and hashed password vastly increases the time required for an attacker to crack a hashed password, to the point where it is infeasible unless the password is very simple.

Of course everybody knows (or should know) that using the same password for Slashdot and your bank is a bad idea (you could have a bank support rep using up your precious karma!), but it is still very common, and it's irresponsible for a developer to expose their users' passwords if they have made this common mistake.

RAM of a running process is accessible to root via the debugger, so doesn't really provide better security than a file only root can read, although it may slow an attacker down a bit or foil a dim-witted attacker. As others have mentioned, there is also some systems management difficulty if services do not function until a password is entered into them.

At any rate, lots of interesting schemes are possible, but I was wondering if any of them were in wide use?

Thanks,

------Scott.

Most applications I've worked with have stored passwords hashed and salted and stored credit card data offsite or not at all, but have kept other sorts of personal data (address, phone, etc.) in the database in plaintext.

I've always reasoned that encrypting the data is of little value, since the decryption keys would have to be on the server, and a server compromise would give the keys along with the data. This case is interesting though, since it seems only the database was compromised, so encrypted data in the database with keys outside of the database would have provided some protection.

I can come up with lots of simple schemes for encrypting personal data in the database, but what I'm wondering is, how is this typically handled? Is it common to encrypt this sort of data? If so using what techniques for encryption and key management? Are there some well-known best practices that I haven't come across?

Thanks!

----Scott.

Does this release include installer support for software RAID? I've been waiting for that for awhile; the elaborate dance to convert a system to RAID after installation is getting old. :-)