6 ms·

Just to be clear: there is no significant difference between either of these and simply storing in plaintext. "In a recoverable form" means that a) there's a s

by shubber 15y ago

Just to be clear: there is no significant difference between either of these and simply storing in plaintext. "In a recoverable form" means that a) there's a single key with which to decrypt the passwords. If I can get the password list, the key isn't far away. And it might not be worth the effort to track it down, since it's practically equivalent to have the (two-way) encrypted passwords and to have the plaintext.

viraptor 15y ago
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...)
- Xk 15y ago
  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?
  - cHalgan 15y ago
    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...
    - theBobMcCormick 15y ago
      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.
      - cHalgan 15y ago
        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.
        deleted 15y ago
        [deleted]
      - ceejayoz 15y ago
        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.
- tptacek 15y ago
  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.
  - deleted 15y ago
    [deleted]
    - tedunangst 15y ago
      I don't see how rainbow tables are relevant. How would you use a rainbow table to crack passwords encrypted with an unknown key?
      - deleted 15y ago
        [deleted]
      - 16s 15y ago
        You couldn't. It's not possible. If you don't know, then it's not possible to pre-compute. Many people fail to understand that. Rainbow tables (while sounding magical, are not). Edit: But they are great for standard unsalted hashes. md4, md5, sha1, sha512, etc.
  - tedunangst 15y ago
    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?
    - gkop 15y ago
- dpark 15y ago
  > 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.
  - tedunangst 15y ago
    I'm not aware of any operating system that allows perusal of swap through the filesystem. That'd be a pretty serious hole.
    - dpark 15y ago
      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.
  - cdcarter 15y ago
    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.
    - dpark 15y ago
      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.)
pbreit 15y ago
Yes, there is. In most companies, the database is significantly more accessible than any encryption keys. For goodness sake, marketers typically have query access to the DB. And the issue of emailing a password is different. The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords that a company, not you, chose to drop into your email account. But to be clear, user-created passwords should be stored one-way hashed and never emailed.
- shubber 15y ago
  Trying not to be pedantic, but this is something everyone should know. If I can pull a list of two-way encrypted passwords, breaking that is way faster than extracting passwords from a properly crypted list. Essentially it's a huge list of short (almost known plaintext) messages. If you know a cryptosystem that will resist attack in that circumstance, please share. Properly crypted, passwords admit to local brute forcing, which is bad for any particular account. "Recoverable" passwords, the whole list admits to statistical attacks that break the whole list.
- AgentConundrum 15y ago
  > For goodness sake, marketers typically have query access to the DB. That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA. > The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email. It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good. I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.
desigooner 15y ago
I had to ask this as I am dealing with a DotNetNuke based system right now which stores authentication details in a table (aspnet_membership) with the passwords encrypted with a private key (in web.config in IIS) and a password salt. How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!
- deleted 15y ago
  [deleted]
- aaronblohowiak 15y ago
  > "How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!" Change the system.
  - desigooner 15y ago
    I wish it was that easy. Working in higher ed means dealing with legacy and proprietary systems at low budgets. "Change the system" isn't always the option in the real world a lot many times.
- ams6110 15y ago
  You can change it so that DotNetNuke (really aspnet_membership) uses hashed passwords. They are then not recoverable, but DotNetNuke will allow a user to request a new password which is then emailed (rather than a slightly safer "reset password" link)
coin 15y ago
> If I can get the password list, the key isn't far away. What makes you think the key isn't far away?
- po 15y ago
  Because the email server (or application server or whatever is creating the text for that email) can access it to decrypt it. If that server gets hacked, then you can decrypt all of the passwords.
- jws 15y ago
  As an example: The password list might consist of entries encrypted with a public key. The private key might only exist on an air gapped laptop with its communication ports filled with epoxy in a secured facility using trusted humans to enter the encrypted password and retrieve the decrypted plaintext. I have no reason to believe the above is true, but there is also no reason to automatically believe there is a mechanism available to attackers of a compromised machine to decrypt all encoded materials on the machine.

by shubber 15y ago

viraptor 15y ago

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...)

Xk 15y ago
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?
- cHalgan 15y ago
  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...
  - theBobMcCormick 15y ago
    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.
    - cHalgan 15y ago
      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.
      - deleted 15y ago
        [deleted]
    - ceejayoz 15y ago
      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.
tptacek 15y ago
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.
- deleted 15y ago
  [deleted]
  - tedunangst 15y ago
    I don't see how rainbow tables are relevant. How would you use a rainbow table to crack passwords encrypted with an unknown key?
    - deleted 15y ago
      [deleted]
    - 16s 15y ago
      You couldn't. It's not possible. If you don't know, then it's not possible to pre-compute. Many people fail to understand that. Rainbow tables (while sounding magical, are not). Edit: But they are great for standard unsalted hashes. md4, md5, sha1, sha512, etc.
- tedunangst 15y ago
  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?
  - gkop 15y ago
dpark 15y ago
> 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.
- tedunangst 15y ago
  I'm not aware of any operating system that allows perusal of swap through the filesystem. That'd be a pretty serious hole.
  - dpark 15y ago
    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.
- cdcarter 15y ago
  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.
  - dpark 15y ago
    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.)

pbreit 15y ago

Yes, there is. In most companies, the database is significantly more accessible than any encryption keys. For goodness sake, marketers typically have query access to the DB. And the issue of emailing a password is different. The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords that a company, not you, chose to drop into your email account. But to be clear, user-created passwords should be stored one-way hashed and never emailed.

shubber 15y ago
Trying not to be pedantic, but this is something everyone should know. If I can pull a list of two-way encrypted passwords, breaking that is way faster than extracting passwords from a properly crypted list. Essentially it's a huge list of short (almost known plaintext) messages. If you know a cryptosystem that will resist attack in that circumstance, please share. Properly crypted, passwords admit to local brute forcing, which is bad for any particular account. "Recoverable" passwords, the whole list admits to statistical attacks that break the whole list.
AgentConundrum 15y ago
> For goodness sake, marketers typically have query access to the DB. That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA. > The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email. It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good. I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.

desigooner 15y ago

I had to ask this as I am dealing with a DotNetNuke based system right now which stores authentication details in a table (aspnet_membership) with the passwords encrypted with a private key (in web.config in IIS) and a password salt. How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!

deleted 15y ago
[deleted]
aaronblohowiak 15y ago
> "How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!" Change the system.
- desigooner 15y ago
  I wish it was that easy. Working in higher ed means dealing with legacy and proprietary systems at low budgets. "Change the system" isn't always the option in the real world a lot many times.
ams6110 15y ago
You can change it so that DotNetNuke (really aspnet_membership) uses hashed passwords. They are then not recoverable, but DotNetNuke will allow a user to request a new password which is then emailed (rather than a slightly safer "reset password" link)

coin 15y ago

> If I can get the password list, the key isn't far away. What makes you think the key isn't far away?

po 15y ago
Because the email server (or application server or whatever is creating the text for that email) can access it to decrypt it. If that server gets hacked, then you can decrypt all of the passwords.
jws 15y ago
As an example: The password list might consist of entries encrypted with a public key. The private key might only exist on an air gapped laptop with its communication ports filled with epoxy in a secured facility using trusted humans to enter the encrypted password and retrieve the decrypted plaintext. I have no reason to believe the above is true, but there is also no reason to automatically believe there is a mechanism available to attackers of a compromised machine to decrypt all encoded materials on the machine.