[OWASP-Security101] Security101 Digest, Vol 2, Issue 4
michael.coates at owasp.org
Wed Mar 14 15:29:26 UTC 2012
On Mar 13, 2012, at 6:59 PM, Bill Sempf wrote:
> On Tue, Mar 13, 2012 at 8:35 PM, <security101-request at lists.owasp.org> wrote:
>> Yes, its good to adhere to best security practices at all times. Understanding the full threat model and risks throughout the system also help prioritize where security improvements should be spent. For instance, we certainly shouldn't send passwords over email, but as we see from all systems, password resets are often sent over email. The difference is that these are single use tokens with rapid expiration times, but it still points to the larger issue that it's tough to build a secure communication if we're all over unencrypted email.
> My problem is that if MailMan sends the email in plaintext, it stores
> it in plaintext. Now, I remember that from my Unix Admin days, but
> that was back in 1992. Surely there is a better way these days.
Yes, I haven't personally dug into the internals of mailman, but if any website sends you your clear text password they are doing 1 of 2 things:
1. Storing the password in a database in the clear
2. Storing the password using symmetric encryption with the key accessible to the application for decryption
In case 1, a SQL injection that provides access to the database provides the attacker with all clear text passwords for all users. Very bad.
In case 2, a SQL injection on its own would give the attacker encrypted passwords. If they key was also stored somewhere in the db then the attacker could just grab this value and decrypt the passwords on his device. Also very bad. Even if the key is stored outside the db on the file system, this approach is still really a bad idea since its so easy for an admin or rogue employee to get at the passwords.
To keep things in perspective - this is a mailing list and the random password for mailman helps prevent others from unsubscribing you. Not a ton of risk and just use a unique value provided by the mailing software
But, diving into the larger issue - What is the best way to do password storage?
Password hashing - But not just password hashing on its own. You need to use a per user salt and a hashing method that is not fast (e.g. iterate the hash). That second part is often missed during design. The important part about iterating the hash is to introduce an element of work (e.g. time). By introduces a small amount of work to verify a password you increase the relative amount of time to check one password by a small percentage, but increase the overall amount of time to brute force an entire range of passwords by a very large value.
More reading here:
I recommend checking out bcrypt or scrypt specifically to find out more on password iterations:
Michael Coates | OWASP
michael.coates at owasp.org | @_mwc
More information about the Security101