2. If you can remember your password, it is probably weak.
This actually isn't true, though one might think so. See new reasearch by Steve Gibson: https://www.grc.com/haystack.htm 
Topic: 7 simple rules to mitigate most threats related to passwords - page 2. (Read 4973 times)
Those are good tips, however, I think we need a 'best practices' for web developers. I would say:
- Use Sha512 - not MD5 for hashes
- Salt passwords with at least 20 characters - DO NOT STORE SALT WITH HASHES
- Do not store email addresses as plain text, store encrypted
- Use parameterized input for SQL to avoid SQL injection attacks
- Use form tokens to prevent CSRF attacks
Using Sha512 instead of MD5 will change nothing.
If possible, I'd suggest to use scrypt (http://www.tarsnap.com/scrypt.html). If there's no available scrypt implementation for the language your using use bcrypt (http://en.wikipedia.org/wiki/Bcrypt).
You also have to realize that the complexity of your password doesn't really matter. Why? Because hackers these days get the passwords through other methods (ie. stealing the database and cracking the passwords).
Not entirely true, as the recent issue confirms. If an attacker gets access to a list of password hashes, the complexity of the password is a huge factor in how long it takes to determine your password. 
Guys, this thread was not intended as educational resource for PHP programmers. It is and the password handling rules are for regular users. How this could not be obvious?
Please continue your "how to develop secure web apps" discussion elsewhere.
Please continue your "how to develop secure web apps" discussion elsewhere.
3, 4 and 5 are good, but I don't think you understand how password hash systems work.
1) MD5 is fine for passwords, when used in a salted iterated hashing system.
2) Passwords are salted with a set number of bits, that depends on the system you are using, not some number of characters. And the salt must be stored with the password, otherwise you don't know how to compare them. Unless you are talking about a having a secret that you append to all passwords before sending them through the salt and hash procedure.
Ideally, using a different salt for each password is good - but storing the salt in plaintext inside the database defeats the purpose (only means that attackers can't rely on pre generated hash databases).
At the bare minimum, they could've salted the passwords inside the source code and only stored the resulting hash to the database.
So that, password "12345" becomes "12345lkj3409ruflk30rjfsldk4lkljflkj234%%#$4324", which is then hashed and stored in plaintext.
This simple step would've prevented the entire MtGox issue that we've seen yesterday.
Those are good tips, however, I think we need a 'best practices' for web developers. I would say:
- Use Sha512 - not MD5 for hashes
- Salt passwords with at least 20 characters - DO NOT STORE SALT WITH HASHES
- Do not store email addresses as plain text, store encrypted
- Use parameterized input for SQL to avoid SQL injection attacks
- Use form tokens to prevent CSRF attacks
3, 4 and 5 are good, but I don't think you understand how password hash systems work.
1) MD5 is fine for passwords, when used in a salted iterated hashing system.
2) Passwords are salted with a set number of bits, that depends on the system you are using, not some number of characters. And the salt must be stored with the password, otherwise you don't know how to compare them. Unless you are talking about a having a secret that you append to all passwords before sending them through the salt and hash procedure.
Those are good tips, however, I think we need a 'best practices' for web developers. I would say:
- Use Sha512 - not MD5 for hashes
- Salt passwords with at least 20 characters - DO NOT STORE SALT WITH HASHES
- Do not store email addresses as plain text, store encrypted
- Use parameterized input for SQL to avoid SQL injection attacks
- Use form tokens to prevent CSRF attacks
Yea web server security is 100x more important.
You could have the most complex password ever, but if the website is not secure then your screwed.
1. Do not use mt.gox
2. Do not use mt.gox
2. Do not use mt.gox
Yes, if you are using bitcoin7.com instead, then you're probably alright.
1. Do not use mt.gox
2. Do not use mt.gox
2. Do not use mt.gox
Those are good tips, however, I think we need a 'best practices' for web developers. I would say:
- Use Sha512 - not MD5 for hashes
- Salt passwords with at least 20 characters - DO NOT STORE SALT WITH HASHES
- Do not store email addresses as plain text, store encrypted
- Use parameterized input for SQL to avoid SQL injection attacks
- Use form tokens to prevent CSRF attacks
1. Do not use the same password in more than one place.
2. If you can remember your password, it is probably weak.
3. If your password is less than 12 character long it is probably weak.
4. If your password does not contain numbers, upper-case letters and some weird symbols, it is probably weak.
5. Use password management software to store and generate passwords, such as firefox's password manager, keepass etc...
6. Use long mnemonic pass phrases as master passwords for password managers and and other accounts which you need to be able to access without using password management software (like gmail account and truecrypt containers, for example)
7. Consider writing some important passwords down on paper and storing it in secure location.
Your mileage may vary.
2. If you can remember your password, it is probably weak.
3. If your password is less than 12 character long it is probably weak.
4. If your password does not contain numbers, upper-case letters and some weird symbols, it is probably weak.
5. Use password management software to store and generate passwords, such as firefox's password manager, keepass etc...
6. Use long mnemonic pass phrases as master passwords for password managers and and other accounts which you need to be able to access without using password management software (like gmail account and truecrypt containers, for example)
7. Consider writing some important passwords down on paper and storing it in secure location.
Your mileage may vary.
You also have to realize that the complexity of your password doesn't really matter. Why? Because hackers these days get the passwords through other methods (ie. stealing the database and cracking the passwords).
The only real thing a complex password protects you from is bruteforce attack. Bruteforce attack only works if your password is insanely simple or the webserver doesn't ban your ip after 3-4 failed login attempts.
Now I am not saying that your rules are bad. They are good rules to follow. What I am saying is that people need to take more precautions than just making a complex password and thinking they are safe. You need to make it so that even IF a hacker gets into your account that they can't do much damage and that you always have the upper hand.
1. Do not use the same password in more than one place.
2. If you can remember your password, it is probably weak.
3. If your password is less than 12 character long it is probably weak.
4. If your password does not contain numbers, upper-case letters and some weird symbols, it is probably weak.
5. Use password management software to store and generate passwords, such as firefox's password manager, keepass etc...
6. Use long mnemonic pass phrases as master passwords for password managers and and other accounts which you need to be able to access without using password management software (like gmail account and truecrypt containers, for example)
7. Consider writing some important passwords down on paper and storing it in secure location.
Your mileage may vary.
2. If you can remember your password, it is probably weak.
3. If your password is less than 12 character long it is probably weak.
4. If your password does not contain numbers, upper-case letters and some weird symbols, it is probably weak.
5. Use password management software to store and generate passwords, such as firefox's password manager, keepass etc...
6. Use long mnemonic pass phrases as master passwords for password managers and and other accounts which you need to be able to access without using password management software (like gmail account and truecrypt containers, for example)
7. Consider writing some important passwords down on paper and storing it in secure location.
Your mileage may vary.
Jump to: