I was just wondering if any of you store encrypted passwords rather than hashes. A friend suggested that encrypted password''s make retrieval easier for the end user - they can just be emailed their login details, no need to reset anything. With the recent news of md5 and sha-1 collision attacks, is a hash really much more secure than an encrypted password? I''ve never been a fan of resetting forgotten passwords, but I guess it''s the best method we have. or is it?
Hello, If I would go through the trouble of storing something that needs to be encrypted, I would do the best to avoid allowing any automatic decryption to happen on the same server. Because if your server is compromised, then there is a chance that they got hold of your encryption/decryption mechanism and your data is not safe. At least that''s how I would see it. And even if sha-1 has attacks, they still require 2^69 operations at least, which makes it still quite impractical ... of course, time to move on to something else but ... :-) Just my 2 cents, /B On Mon, 21 Feb 2005 10:01:57 +0000, Dylan <b9704-Ku7NbOBBH+dBDgjK7y7TUQ@public.gmane.org> wrote:> I was just wondering if any of you store encrypted passwords rather than > hashes. > > A friend suggested that encrypted password''s make retrieval easier for > the end user - they can just be emailed their login details, no need to > reset anything. > > With the recent news of md5 and sha-1 collision attacks, is a hash > really much more secure than an encrypted password? I''ve never been a > fan of resetting forgotten passwords, but I guess it''s the best method > we have. or is it? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Bruno Mattarollo <bruno.mattarollo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Currently in: Sydney, Australia
* Steven Critchfield (critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org) [050221 11:42]:> What I remember of the MD5 "hack" was that it was possible to change a > portion of a larger file and still produce a valid/same md5 signature. > On a small enough file/password, you should still be safe.The cryptographic break in md5 showed that it is possible to generate two plaintexts with the same hash. To my knowledge it is still considered effectively intractable to generate a new string with an identical hash to another string. Worse still if the original string is unknown (as it would be in the case of a password, further worse in the case of a salted password).> The trouble is that there are places trying to generate a lookup table > for password size md5 signatures. Storage was the only thing making this > form of attack impractical, but now it isn''t very expensive.That and the widespread use of salts. It is still prohibitively expensive.> sha-1 is still fairly compute intensive.All of these attacks are compute intensive (note that the SHA-1 and MD5 engines both rely on the same type of compression function). In SHA-1''s case 2^69 is the number of tests to make to find a collision. Given that it''s easier to break fingers than to search a space of that size I''m going to guess that the weakness of the hashing algorithm is far from the weakest security link on any given system. Further, most sites'' data isn''t worth even breaking a finger over. Noone''s going to harness thousands of machines for a year or more to get some guy''s credit card number. I''ve seen some mathematicians recommending larger entropy hashing algorithms such as SHA-256. Those same folks seem to be expecting a NIST competition for new hash functions in the near future, but expect vetting of any new functions to take at least 3-4 years.> Consider it also in the light of a larger admin base as well. A > disgruntled admin can take your password list and decrypt it with little > effort if you use an encryption method with a known/available key to the > admins. The one way hash would then be a bit more difficult to get very > many accounts broken into.This is true, and one of the reasons Unix has used trapdoor functions for decades to store passwords. For more coverage on some of these topics I''d recommend Peter Wayner''s "Translucent Databases" (http://www.amazon.com/exec/obidos/ASIN/0967584418/002-1999395-9360816). Rick -- http://www.rickbradley.com MUPRN: 812 | came on the list, and random email haiku | I found his name to be | pretty funny then.
On 21-Feb-2005, at 13:05, Steven Critchfield wrote:> On Mon, 2005-02-21 at 10:01 +0000, Dylan wrote: >> I was just wondering if any of you store encrypted passwords rather >> than >> hashes. >> > The trouble is that there are places trying to generate a lookup table > for password size md5 signatures. Storage was the only thing making > this > form of attack impractical, but now it isn''t very expensive. > >Would it be feasible to: user.password = Digest::MD5(entered_password * 100) (or SHA1) that would take care of the "password size md5 signatures," wouldn''t it? In my opinion, all security is an afterthought, unless it is built into the kernel of the operating system. When I get caught up (haha!) I plan to learn SELinux. It''s good enough that you can find "play" sites on the internet that will give you root access and a shell prompt to try your hand at breaking it. That''s secure! Regards, JJ
On Mon, 2005-02-21 at 10:01 +0000, Dylan wrote:> I was just wondering if any of you store encrypted passwords rather than > hashes. > > A friend suggested that encrypted password''s make retrieval easier for > the end user - they can just be emailed their login details, no need to > reset anything. > > With the recent news of md5 and sha-1 collision attacks, is a hash > really much more secure than an encrypted password? I''ve never been a > fan of resetting forgotten passwords, but I guess it''s the best method > we have. or is it?What I remember of the MD5 "hack" was that it was possible to change a portion of a larger file and still produce a valid/same md5 signature. On a small enough file/password, you should still be safe. The trouble is that there are places trying to generate a lookup table for password size md5 signatures. Storage was the only thing making this form of attack impractical, but now it isn''t very expensive. sha-1 is still fairly compute intensive. As for storing one way hashes or encypted passwords, it depends on how secure you feel you need to be with your data. As has been mentioned here already, if you are encrypting and your app is compromised, the attacker has the mechanism and your key to decrypt the all the passwords. If you one way hash them, each password is going to be relatively difficult to crack. Consider it also in the light of a larger admin base as well. A disgruntled admin can take your password list and decrypt it with little effort if you use an encryption method with a known/available key to the admins. The one way hash would then be a bit more difficult to get very many accounts broken into. -- Steven Critchfield <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>