Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It's also worth noting that you shouldn't store your users' passwords (plaintext) in the database.<br> It's extremely insecure and exposes your user in bad ways. </p> <p>To quote the Coding Horror article <a href="http://www.codinghorror.com/blog/archives/000953.html" rel="nofollow noreferrer">You're Probably Storing Passwords Incorrectly</a>:</p> <blockquote> <p>Users collect usernames and passwords like they do Pokemon. It's a sorry state of affairs, but for better or worse, that's the way it is. We, as software developers, are trusted with storing all these usernames and passwords in some sort of database. The minute we store a user's password, we've taken on the responsibility of securing their password, too. Let's say a hacker somehow obtains a list of all our usernames and passwords. Either it was an inside job by someone who had access to the database, or the database was accidentally exposed to the public web. Doesn't matter how. It just happened.</p> <p>(...)</p> <p>You might think it's relatively unimportant if someone's forum password is exposed as plain text. After all, what's an attacker going to do with crappy forum credentials? Post angry messages on the user's behalf? But most users tend to re-use the same passwords, probably because they can't remember the two dozen unique usernames and passwords they're forced to have. So if you obtain their forum password, it's likely you also have the password to something a lot more dangerous: their online banking and PayPal.</p> </blockquote> <p>Those two article cover a little bit of the issue and I suggest you take a read on it.</p> <p><a href="http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database" rel="nofollow noreferrer">Never store passwords in a database!</a></p> <p><a href="http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html" rel="nofollow noreferrer">Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes</a></p> <p>For a good compilation of authentication related advice you can also check this StackOverflow question:</p> <p><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta">The Definitive Guide To Website Authentication (beta)</a></p> <hr> <h3>Edit in response to OP's comment:</h3> <p>Yeah, I'm dumb and only saw that after posting but the comment is still valid. </p> <p>You're using MD5 hashes but if you look at the linked articles you will see that MD5 alone is not enough and one can easily pick "most" of your passwords back if they have your database.<br> For a quick test, just throw an MD5 hash into google and you will see that unless your password is really wicked, you will get it back.</p> <p>For a better approach you'd need the md5hash and a salt for each password, but I'm better pointing you to read the linked article <a href="http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html" rel="nofollow noreferrer">Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes</a> than trying to explain it here.</p> <p>It has a simple, easy way to do it right. :)</p> <p>I'm sure I would do it wrong if I tried to explain it in my own words! :)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

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