![]() You might consider this sort of symmetric encryption an advantage because you can automatically re-encrypt every password in the database if ever you decide to change the key (you may even have policies that require that), or to shift to a more secure algorithm to keep ahead of cracking tools.īut don’t encrypt your password databases reversibly like this. Even though 56 bits gives close to 100,000 million million possible passwords, modern cracking tools can get through that many DES passwords within a day. Using DES for anything in the real world is a bad idea, because it only uses 56-bit keys, or seven characters’ worth. → For the sample data above we chose the key DESPAIR and encrypted each of the passwords with straight DES. ![]() This is the approach Adobe took, ending up with something similar to this: That way, users’ passwords never need to be written to disk in unencrypted form you can’t accidentally view them in the database and if the password data should get stolen, it would just be shredded cabbage to the crooks. ![]() You could even arrange to have the decryption key for the database stored on another server, get your password verification server to retrieve it only when needed, and only ever keep it in memory. Attempt Two – encrypt the passwords in the databaseĮncrypting the passwords sounds much better. It’s not about trust, it’s about definition: a password ought to be like a PIN, treated as a personal identification detail that is no-one else’s business. ![]() The point is that neither you, nor any of your fellow system administrators, should be able to look up a user’s password. Worse still, they get a glimpse into the sort of password that each user seems to favour, which could help them guess their way into other accounts belonging to that user.Īlfred, for example, went for his name followed by a short sequence number David used a date that probably has some personal significance Eric Cleese followed a Monty Python theme while Charlie and Duck didn’t seem to care at all. That way, if someone forgets their password, you can just look it up and tell them what it is.ĭon’t do this, for the simple reason that anyone who gets to peek at the file immediately knows how to login as any user. If you are running a small network, with just a few users whom you known well, and whom you support in person, you might even consider it an advantage to store passwords unencrypted. On the grounds that you intend – and, indeed, you ought – to prevent your users’ passwords from being stolen in the first place, it’s tempting just to keep your user database in directly usable form, like this: Attempt One – store the passwords unencrypted Just to clarify: this article isn’t a programming tutorial with example code you can copy to use on your own server.įirstly, we don’t know whether your’re using PHP, MySQL, C#, Java, Perl, Python or whatever, and secondly, there are lots of articles already available that tell you what to do with passwords. The leaked data revealed that Adobe had been storing its users’ passwords ineptly – something that was surprising, because storing passwords much more safely would have been no more difficult.įollowing our popular article explaining what Adobe did wrong, a number of readers asked us, “Why not publish an article showing the rest of us how to do it right?” Not only was it one of the largest breaches of username databases ever, with 150,000,000 records exposed, it was also one of the most embarrassing. You probably didn’t miss the news – and the fallout that followed – about Adobe’s October 2013 data breach.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |