Hacker News new | past | comments | ask | show | jobs | submit login

> so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5.

Interesting. This suggests you're storing all passwords in plain, is that true?




correct, which is far from ideal (essentially we're trapped by our CRAM-MD5 support)

we've thought long and hard about this too, and don't consider it to be a large threat, as the only two people with access to the box[1] could silently replace the AUTH code and log all the passwords anyway, rendering any secured password store irrelevant.

[1]: it's not even known outside the core where the box lives, and it's also essentially completely isolated from the internet at large.


[deleted]


as I said it's not ideal.

the only point of entry onto the machine is via the auth service, so if you get in that way you have access to it.

it's not a matter of injecting code, it's literally one line to run spin up gdb attached to the process, and then one/two more more lines inside gdb to put a breakpoint on the line and print the variables on the stack when it's hit.

add in the fact that something like 95% of our users reconnect every 24 hours, so you get the vast majority very quickly.

yes, if the admins go rogue then we're screwed, but the same is true nearly always as they're the guys that set up the defences in the first place.


Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol.

What year is this?


Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords.

Add on a layer of encryption (unique key per password, keys in a separate encrypted table) and you're way better off than you are now.

Also, since MD5 can be collided, consider SSL for the login process.


> Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords.

In real CRAM-MD5 this is not true. It uses HMAC-MD5 of the key directly. To be able to calculate that, you need to do

    MD5((key XOR opad) || ...)
Which means that you either store "key XOR opad" (not meaningfully different from storing key), or an intermediate result from MD5, which is tricky.

Quakenet's authentication mechanisms, except for LEGACY-MD5, call MD5, SHA1 and SHA256 before using it as the key, so they could store just each of those different hashes (unsalted). The LEGACY-MD5 mechanism does require the plain text password to be known by the server.


That's what I mean - store the intermediate result of the MD5(key XOR ipad) and MD5(key XOR opad). The only trickery is implementing the HMAC wrapper, but that's not very difficult.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: