StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h1>Definitive Article</h1> <h3>Sending credentials</h3> <p>The only practical way to send credentials 100% securely is by using <a href="http://en.wikipedia.org/wiki/SSL" rel="noreferrer">SSL</a>. Using JavaScript to hash the password is not safe. Common pitfalls for client-side password hashing:</p> <ul> <li>If the connection between the client and server is unencrypted, everything you do is <a href="https://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding">vulnerable to man-in-the-middle attacks</a>. An attacker could replace the incoming javascript to break the hashing or send all credentials to their server, they could listen to client responses and impersonate the users perfectly, etc. etc. SSL with trusted Certificate Authorities is designed to prevent MitM attacks.</li> <li>The hashed password received by the server is <a href="https://security.stackexchange.com/questions/45254/owasp-recommendation-on-client-side-password-hashing">less secure</a> if you don't do additional, redundant work on the server.</li> </ul> <p>There's another secure method called <strong>SRP</strong>, but it's patented (although it is <a href="http://srp.stanford.edu/license.txt" rel="noreferrer">freely licensed</a>) and there are few good implementations available.</p> <h3>Storing passwords</h3> <p>Don't ever store passwords as plaintext in the database. Not even if you don't care about the security of your own site. Assume that some of your users will reuse the password of their online bank account. So, store the hashed password, and throw away the original. And make sure the password doesn't show up in access logs or application logs. OWASP <a href="https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Impose_infeasible_verification_on_attacker" rel="noreferrer">recommends the use of Argon2</a> as your first choice for new applications. If this is not available, PBKDF2 or scrypt should be used instead. And finally if none of the above are available, use bcrypt.</p> <p>Hashes by themselves are also insecure. For instance, identical passwords mean identical hashes--this makes hash lookup tables an effective way of cracking lots of passwords at once. Instead, store the <strong>salted</strong> hash. A salt is a string appended to the password prior to hashing - use a different (random) salt per user. The salt is a public value, so you can store them with the hash in the database. See <a href="http://www.codeproject.com/Articles/704865/Salted-Password-Hashing-Doing-it-Right" rel="noreferrer">here</a> for more on this.</p> <p>This means that you can't send the user their forgotten passwords (because you only have the hash). Don't reset the user's password unless you have authenticated the user (users must prove that they are able to read emails sent to the stored (and validated) email address.)</p> <h3>Security questions</h3> <p>Security questions are insecure - avoid using them. Why? Anything a security question does, a password does better. Read <strong><em>PART III: Using Secret Questions</em></strong> in <a href="http://srp.stanford.edu/license.txt" rel="noreferrer">@Jens Roland answer</a> here in this wiki.</p> <h3>Session cookies</h3> <p>After the user logs in, the server sends the user a session cookie. The server can retrieve the username or id from the cookie, but nobody else can generate such a cookie (TODO explain mechanisms).</p> <p><a href="http://en.wikipedia.org/wiki/Session_hijacking" rel="noreferrer">Cookies can be hijacked</a>: they are only as secure as the rest of the client's machine and other communications. They can be read from disk, sniffed in network traffic, lifted by a cross-site scripting attack, phished from a poisoned DNS so the client sends their cookies to the wrong servers. Don't send persistent cookies. Cookies should expire at the end of the client session (browser close or leaving your domain).</p> <p>If you want to autologin your users, you can set a persistent cookie, but it should be distinct from a full-session cookie. You can set an additional flag that the user has auto-logged in, and needs to login for real for sensitive operations. This is popular with shopping sites that want to provide you with a seamless, personalized shopping experience but still protect your financial details. For example, when you return to visit Amazon, they show you a page that looks like you're logged in, but when you go to place an order (or change your shipping address, credit card etc.), they ask you to confirm your password.</p> <p>Financial web sites such as banks and credit cards, on the other hand, only have sensitive data and should not allow auto-login or a low-security mode.</p> <h3>List of external resources</h3> <ul> <li><a href="http://pdos.csail.mit.edu/papers/webauth:sec10.pdf" rel="noreferrer">Dos and Don'ts of Client Authentication on the Web (PDF)</a><br> 21 page academic article with many great tips. </li> <li><a href="http://news.ycombinator.com/item?id=205572" rel="noreferrer">Ask YC: Best Practices for User Authentication</a><br> Forum discussion on the subject </li> <li><a href="http://www.codinghorror.com/blog/archives/000953.html" rel="noreferrer">You're Probably Storing Passwords Incorrectly</a><br> Introductory article about storing passwords</li> <li><a href="http://news.ycombinator.com/item?id=55660" rel="noreferrer">Discussion: Coding Horror: You're Probably Storing Passwords Incorrectly</a><br> Forum discussion about a Coding Horror article.</li> <li>Never store passwords in a database!<br> Another warning about storing passwords in the database.</li> <li><a href="http://en.wikipedia.org/wiki/Password_cracking" rel="noreferrer">Password cracking</a><br> Wikipedia article on weaknesses of several password hashing schemes.</li> <li><a href="http://www.securityfocus.com/blogs/262" rel="noreferrer">Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes</a><br> Discussion about rainbow tables and how to defend against them, and against other threads. Includes extensive discussion.</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload