One way to fix your rubbish password database • Hacker News Board

Re: One way to fix your rubbish password database

#71

Post by desas » Fri, Jun 08, 2012, 10:48 PM UTC

donpdonp wrote: post #36

jcromartie wrote: post #13

This is a good step, but unfortunately all of the actual passwords are still out there, so they need to be changed. I think a better idea would be to establish an easily implemented pattern for "password bankruptcy" that companies could follow in the case of a leak.

What would a password bankruptcy pattern look like? One thought is to invalidate all passwords and fall back on email password recovery when a login is attempted. This leads me to an idea I've tried once - if access to the inbox is equivalent to password credentials, why not use an email to login? By this I mean the web site login is a single field - email address. The system emails a one-click-login URL to the user…

Emailing a link to login was one of two supported login methods for redhats mugshot social network. The other was sending the link via xmpp.

In practice I end up doing this for little used sites because I use either my phone, tablet, and two laptops for browsing the internet.

It's annoying if you work somewhere that doesn't allow access to personal email accounts and you want to log-in to something.

Re: One way to fix your rubbish password database

#72

Post by heretohelp » Sat, Jun 09, 2012, 12:00 AM UTC

rb2k_ wrote: post #65

Even if you run a bad codebase that just uses unsalted MD5 and you don't want to add a new crypto algorithm: Couldn't you just run your whole database through X more rounds of MD5 and do the same in your authentication function? That way, script kiddies couldn't use precomputed rainbow tables they downloaded somewhere off Bittorrent. Each additional round will also reduce the speed of a brute force attack while still…

Pretty easily detected. This is a bad idea. Amateurs need to stop attempting their own patchwork solutions to their already bad fuck-ups.

Re: One way to fix your rubbish password database

#73

Post by rb2k_ » Sat, Jun 09, 2012, 12:02 AM UTC

heretohelp wrote: post #72

rb2k_ wrote: post #65

Even if you run a bad codebase that just uses unsalted MD5 and you don't want to add a new crypto algorithm: Couldn't you just run your whole database through X more rounds of MD5 and do the same in your authentication function? That way, script kiddies couldn't use precomputed rainbow tables they downloaded somewhere off Bittorrent. Each additional round will also reduce the speed of a brute force attack while still…

Pretty easily detected. This is a bad idea. Amateurs need to stop attempting their own patchwork solutions to their already bad fuck-ups.

Is the "easily detected" part really a problem? The idea isn't to try security by obscurity.

The main advantage is that it would still keep people from using precomputed rainbow tables and slow down brute force attacks with a minimum of additional code, wouldn't it? (similar to the switch from DES to triple DES back in the day)

Re: One way to fix your rubbish password database

#74

Post by heretohelp » Sat, Jun 09, 2012, 12:12 AM UTC

rb2k_ wrote: post #73

heretohelp wrote: post #72

Earlier quoted context omitted.

Pretty easily detected. This is a bad idea. Amateurs need to stop attempting their own patchwork solutions to their already bad fuck-ups.

Is the "easily detected" part really a problem? The idea isn't to try security by obscurity. The main advantage is that it would still keep people from using precomputed rainbow tables and slow down brute force attacks with a minimum of additional code, wouldn't it? (similar to the switch from DES to triple DES back in the day)

Rainbow tables are the least and most trivial of your problems to solve.

Using a fast hash algorithm for storing passwords is fucking braindead and a DOA decision to make about security.

Your "solution" doesn't solve anything.

Re: One way to fix your rubbish password database

#75

Post by frisco » Sat, Jun 09, 2012, 1:41 AM UTC

rb2k_ wrote: post #73

heretohelp wrote: post #72

Earlier quoted context omitted.

Pretty easily detected. This is a bad idea. Amateurs need to stop attempting their own patchwork solutions to their already bad fuck-ups.

Is the "easily detected" part really a problem? The idea isn't to try security by obscurity. The main advantage is that it would still keep people from using precomputed rainbow tables and slow down brute force attacks with a minimum of additional code, wouldn't it? (similar to the switch from DES to triple DES back in the day)

(Sorry rb2k_, I didn't mean to downvote you.)

Re: One way to fix your rubbish password database

#76

Post by drivebyacct2 » Sat, Jun 09, 2012, 2:54 AM UTC

Ineffable wrote: post #70

kbanman wrote: post #62

Earlier quoted context omitted.

The subscript i denotes that the variable belongs to a single user i. The tick at the top is pronounced 'prime' and is used to differentiate between versions or iterations.

Is that called "prime" by most people? I've always heard it just pronounced "dash", as in "s-dash" or "f-dash".

>Is that called "prime" by most people?

yes.

Re: One way to fix your rubbish password database

#77

Post by yathern » Sat, Jun 09, 2012, 4:29 AM UTC

The article states that LinkedIn was using salted SHA-1 hashes, but I thought that wasn't the case. Either way, aren't salted hashes essentially uncrackable by all means except full out brute force?

If my password is "password", and I change it to "#b1@password%3dy", and then hash it, isn't it secure from basic dictionary/rainbow table attacks?

I'm a bit new to cryptography, so please forgive me if I'm not understanding some of this correctly.

Re: One way to fix your rubbish password database

#78

Post by IgorPartola » Sat, Jun 09, 2012, 4:39 AM UTC

rb2k_ wrote: post #69

IgorPartola wrote: post #67

Earlier quoted context omitted.

I think the conventional wisdom is that you should not re-invent security. I am slowly learning this, but the give-away seems to be questions that start with "Couldn't you just..."

It also was conventional wisdom that banks were too big to fail ;) Are there any actual arguments against using this as an 'easy' fix to the precomputed rainbow tables scenario? Multiple rounds of a cipher seem to be a relatively common operation in crypto and have helped other old ciphers. One of the more prominent ones would probably be the move from DES to triple DES. I guess dictionary attacks on GPUs would still…

I am no security expert. I can't tell bcrypt from a hole in the ground. All I know is that it's all fun and games until there is a problem with this home-brew implementation and then it's too late. That is why I think it's best to avoid anything like this and instead go with bcrypt/scrypt, etc. and re-evaluate periodically based on latest industry standards. Perhaps an actual security expert on here can evaluate your idea. I seem to remember it being raised many times on here, so there may be an answer to this on one of the discussions of bcrypt vs scrypt or some such.

Re: One way to fix your rubbish password database

#79

Post by IgorPartola » Sat, Jun 09, 2012, 4:43 AM UTC

yathern wrote: post #77

The article states that LinkedIn was using salted SHA-1 hashes, but I thought that wasn't the case. Either way, aren't salted hashes essentially uncrackable by all means except full out brute force? If my password is "password", and I change it to "#b1@password%3dy", and then hash it, isn't it secure from basic dictionary/rainbow table attacks? I'm a bit new to cryptography, so please forgive me if I'm not understand…

Brute force is sometimes all you need. The problem is that using GPU's you can compute so many hashes a second that a short password simply cannot withstand such an attack for long. The salt helps a bit, but if someone is brute-forcing the hashes all it means is that once they have your password they don't have the other person's who happens to use the same one.

Re: One way to fix your rubbish password database

#80

Post by yathern » Sat, Jun 09, 2012, 4:54 AM UTC

IgorPartola wrote: post #79

yathern wrote: post #77

The article states that LinkedIn was using salted SHA-1 hashes, but I thought that wasn't the case. Either way, aren't salted hashes essentially uncrackable by all means except full out brute force? If my password is "password", and I change it to "#b1@password%3dy", and then hash it, isn't it secure from basic dictionary/rainbow table attacks? I'm a bit new to cryptography, so please forgive me if I'm not understand…

Brute force is sometimes all you need. The problem is that using GPU's you can compute so many hashes a second that a short password simply cannot withstand such an attack for long. The salt helps a bit, but if someone is brute-forcing the hashes all it means is that once they have your password they don't have the other person's who happens to use the same one.

I see, but isn't brute-forcing "aecd8c83718c381cpassworda3802..." going to take far, far longer? Even on some huge botnet clusters, I still don't imagine how it could be possible to crack that very quickly.