Hacker News Reader

Comment by viraptor | Hacker News Reader

Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part.

But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)

View on HN

In the most likely implementation of reversably encrypted passwords, an attacker who gets read control of the database can trivially brute-force passwords. Encryption isn't magic.

But in the meantime, I'm curious about what web-based attacks relevant to password storage reversably encrypted passwords protect against. Were you thinking SQLI? Because I do not believe this to be the case.

Don't store reversably encrypted passwords.

Let's assume I store base64 encoded versions of encrypted passwords in my database. The key is 128 random bits in a file in the filesystem. How does sqli get you anything useful? Why do you not believe that's "safe"? (let's ignore other attacks or better solutions. Just sqli)

Update: from other posts, I'm guessing you're assuming that anyone with sqli has other problems too, and that's why you don't think it's safe from sqli?

It's vulnerable to a known-plaintext attack. Eg, you have an account on the system, so you know your own password. You can encrypt your password with different keys until it matches the stored, encrypted version. Then you know the master key.

Edit: Of course you did say 128 bits, which is pretty good. But if you do manage to break it, you do have the master key, which can't happen with hashed passwords.

That's a good idea, but nobody who actually knows how to generate an AES key will be vulnerable to it.

I'm not going to answer this, because I don't want to deal with the 15 counterfactuals someone else is going to come up with for how they'd deal with the way I'd implement this attack (now that they've heard one way to do it). I think you should take my word for it.

Oh well, I had to ask.

It's not personal. Sorry!

I just want to underlay a point here that the previous poster may not have made explicit, i can give you 20 attacks, and you can most definitely think of 20 different ways to prevent whatever it is i'm talking about, the point is, you do not know what i'm going to do in advance as an attacker. Thats why hashed passwords are an important element of security, sure in a theoretically perfectly secure system, it does not matter at all, the problem is, you are not smart enough to get it perfectly right, nobody is, that's why you have the safest "failure modes" you can practically muster.

> Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part.

Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained.

> But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)

This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.

I'm not aware of any operating system that allows perusal of swap through the filesystem. That'd be a pretty serious hole.

I should have clarified that I was referring to accessing the swap as root. This also requires another privilege escalation, and is a separate issue I probably should have left out.

you've got to have the key somewhere so that the machine can restore itself after a reboot

In many very secure systems, this "somewhere" is in the brains/completely secondary data stores of a group of admins who enter that key when a reboot occus.

I think it's unlikely enough to ignore it here, though. Is someone who's willing to send an email in plaintext going to do this? Why bother when simply hashing would do the job more effectively?

I agree it's possible for high security situations where passwords need reversibility, though. e.g. I wouldn't be surprised if Intuit used a system like this when they store passwords for external services. (They should still be hashing users' primary passwords, though.)

No.

If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access.

However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?

If you are storing something in database which needs to be decrypted (i.e., you are storing credentials to access some other system) it is common sense not to have that key in the database.

The key should be provided to your application on startup.

Or sometimes, the key can be in the wallet and that wallet can open only during startup of the application: application should prompt admin to enter password needed to open the wallet.

At least that how I design my systems... Maybe I'm wrong...

Prompt the admin for a password? So there's no way to do an unattended reboot of the application? That doesn't sound very practical.

Hey... If you want to be secure that what you need to do. The keys must not be easily accessible.

Anyway application which need to be secure are not the one you also would like to be restarted automatically or unattended: automatically restart can in many cases just make situation worse (i.e., data corruption)

You can always pay big bucks and use Oracle Database with Transparent Data Encryption: in that case, you need to enter password to open the wallet only on startup of a database.

We're required to have our sensitive data on an encrypted volume by a client (a major financial firm). Sometimes, calling the 24/7 techs to enter a passphrase is a perfectly appropriate solution, especially if you have enough capacity to let a server or two wait until the morning.

Reply on news.ycombinator.com