[Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
* Andrew Rodland and...@cleverdomain.org [2010-04-10 09:00]: the complexity of storing them separately Does not compute. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
Andrew Rodland and...@cleverdomain.org writes: On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote: On 08/04/10 22:49, Daniel Pittman wrote: ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. .. if they are using sufficiently weak passwords, such that they're present in a rainbow table? (Or do such rainbow tables contain every single possible SHA-1 value, ie. from random-looking strings that happen to correspond to the same sha-1 as the actual password?) The table of every possible 8-byte values is ~ 197MB, and only about 2.3PB for all possible 12-byte values. If you eliminate characters that are not going to be present in passwords (since that is 12! permutations * 256 byte-values * 20 bytes of SHA1) you increase length for the same rainbow table. So, yes, those contain everything. You can even download pregenerated rainbow tables for some lengths, or pay commercial companies for use of theirs, if you wish. Or weak enough to brute-force. Not using salt reduces the difficulty of brute- forcing passwords by an order of magnitude (well, some number of orders of magnitude depending on the number of users you have) because you can make a single cracking run against *all users' passwords in parallel* rather than attacking each account individually. *nod* Also. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
Toby Corkindale toby.corkind...@strategicdata.com.au writes: On 08/04/10 16:21, Andrew Rodland wrote: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * You use Catalyst::Authentication::Credential::Password. * With the hashed password_type. * And your database is compromised. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? Unless you are passing the hashed passwords around as authentication tokens, yes. Plus, at that point you have already lost. I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. From the app-dev perspective, though, you already lost. :) But, yes, it's still worth looking into fixing then I think. *nod* Unix did, decades back, for much the same reasons other people have given here. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
On 08/04/10 22:49, Daniel Pittman wrote: Toby Corkindaletoby.corkind...@strategicdata.com.au writes: On 08/04/10 16:21, Andrew Rodland wrote: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * You use Catalyst::Authentication::Credential::Password. * With the hashed password_type. * And your database is compromised. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? Unless you are passing the hashed passwords around as authentication tokens, yes. Plus, at that point you have already lost. I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. .. if they are using sufficiently weak passwords, such that they're present in a rainbow table? (Or do such rainbow tables contain every single possible SHA-1 value, ie. from random-looking strings that happen to correspond to the same sha-1 as the actual password?) From the app-dev perspective, though, you already lost. :) But, yes, it's still worth looking into fixing then I think. *nod* Unix did, decades back, for much the same reasons other people have given here. Daniel Although Unix had the problem that the /etc/passwd file was visible to all users on the machine, prior to the introduction of the shadowed version, and thus anyone could try and brute-force the password hashes. In most (all) websites today, the authentication database is not user-visible. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote: On 08/04/10 22:49, Daniel Pittman wrote: ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. .. if they are using sufficiently weak passwords, such that they're present in a rainbow table? (Or do such rainbow tables contain every single possible SHA-1 value, ie. from random-looking strings that happen to correspond to the same sha-1 as the actual password?) Or weak enough to brute-force. Not using salt reduces the difficulty of brute- forcing passwords by an order of magnitude (well, some number of orders of magnitude depending on the number of users you have) because you can make a single cracking run against *all users' passwords in parallel* rather than attacking each account individually. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
