Re: OT: Storing encryption keys securely
by choroba (Cardinal) on Jan 23, 2017 at 14:54 UTC
|
| [reply] [d/l] |
|
| [reply] |
|
> Adding a second node adds complexity
Yes, and complexity means it's harder to hack you.
> storing the key in clear text in the database
I'd store it encrypted with the passphrase.
> they cannot be re-encrypted
What do you mean?
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
$Data::Dumper::Useqq = 1;
# In reality, use a better algorithm, add salt, etc.
sub encrypt {
my ($password, $passphrase) = @_;
my $long_passphrase = $passphrase;
$long_passphrase .= $passphrase
until length($password) < length $long_passphrase;
substr $long_passphrase, -1, 1, q()
until length($password) == length $long_passphrase;
return $password ^ $long_passphrase
}
*decrypt = *encrypt{CODE};
# This comes from the users.
my %real_passwords = ( john => 'pas$$w0rd',
jane => 'bailey2012',
);
# This comes from the admin.
my $passphrase = 'Perl FTW!';
# This gets saved in the DB.
my %stored_passwords = map {
$_ => encrypt($real_passwords{$_}, $passphrase)
} keys %real_passwords;
print Dumper \%stored_passwords;
# When changing the passphrase, just update the passwords:
my $new_passphrase = 'Invalidate all passwords!';
$_ = encrypt(decrypt($_, $passphrase), $new_passphrase)
for values %stored_passwords;
print Dumper \%stored_passwords;
# We can now retrieve the passwords using the new passphrase.
print Dumper +{
map { $_ => decrypt($stored_passwords{$_}, $new_passphrase)
} keys %stored_passwords
};
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply] [d/l] [select] |
|
Re: OT: Storing encryption keys securely
by BrowserUk (Patriarch) on Jan 24, 2017 at 14:26 UTC
|
- You should never store passwords themselves, even if encrypted, if the encryption method is reversible.
- You should only store the result of combining the password with a per user (derived) salt and passing it through a slow, one-way encoding algorithm.
- To authenticate, you obtain the password combine with the derived salt and encode again. If the result matches the stored value, you authorise.
- To handle the forgotten password scenario, you generate a random password, encode and replace the encoded token in your database.
Get the randomly chosen password to the user somehow* and then force them to change it immediately the first time they log in.
Preferably, they should have to log in and choose their new password within a short time period; and where possible, from a previously known location/machine.
In this way, if your datastore for the encoded authentication tokens is ever stolen, the thieves would have to brute force every single token, because although the encryption method is the same for every token, and they may have also determined the derivation of the salts, the salt is different for each user. Thus they cannot just encode a dictionary of pass phrases with a single salt and search the database to see if any of the tokens match the result.
Ie. They would need to encode every word or phrase in their dictionary with the derived salt for each and every account. Choose a nice slow encryption mechanism and it becomes too time consuming to bother.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
| [reply] |
|
| [reply] |
|
So, basically, it sounds like someone has "solved" their security problem by pushing it off on you. Good luck.
| [reply] |
Re: OT: Storing encryption keys securely
by eyepopslikeamosquito (Archbishop) on Jan 25, 2017 at 10:02 UTC
|
In case it gives you ideas for improving your security,
I'll make some general comments on key management,
based on my limited experience in this domain.
Ideas, corrections, and feedback welcome.
Companies with high security needs and big budgets
tend to employ
Key Management Servers (KMS)
and/or
Hardware Security Modules (HSMs) to protect their keys.
I have some experience with writing (C++) client code that uses a KMS.
I have no first-hand experience with HSMs.
The overall strategy is to setup a dedicated and separate physical machine -
a Key Management Server - to manage and protect all keys in your system.
The KMS is configured to talk to trusted clients only.
KMS's can be expensive - and physically isolated if required.
Clients of the KMS must supply a set of credentials (e.g. a certificate issued by the KMS vendor).
- All keys are stored in the KMS.
- Keys are never stored in client code; they are always fetched from the KMS.
- Each key has a name and an identifier (id).
- Client code gets by id when decrypting; gets by name when encrypting. Doing that enables you to rotate the keys on the KMS at any time, and as often as you wish, without affecting client code. Getting by name gets the latest key; getting by id gets the original key (for decryption), even after a key has been rotated on the KMS.
- Keys are rotated regularly on the KMS - immediately if a key is known to be compromised.
References
| [reply] |
|
All of which misses the point. If a client is compromised, an attacker can use its credentials to request any key he wants from the KMS.
| [reply] |
Re: OT: Storing encryption keys securely
by eyepopslikeamosquito (Archbishop) on Jan 25, 2017 at 21:58 UTC
|
To get a feel for how folks in the cloud are tackling
security and key management, I found
this AWS security talk
by Bill Shinn interesting.
Some items discussed:
- Limited Blast Radius. Contain the damage caused by the loss of a single key.
- Key Hierarchies. Symmetric Key + Master Key -> Encrypted Data Key. You store the encrypted data key with the data. That key is encrypted with a master key that is stored elsewhere. How to protect the master key? Well, you could have an Application Key ... encrypted with a Server Key ... encrypted with a Region Key ... encrypted with an Availability Zone Key, say. That is, design your own key hierarchy - with the goal of reducing the blast radius of the loss of a single key.
- Auditing. Log key management activity and security-related events to one or more external agents (e.g. via syslog). Important when investigating a breach.
Update: See also Re: Security techniques every programmer should know (Security References)
| [reply] |
Re: OT: Storing encryption keys securely
by Anonymous Monk on Jan 24, 2017 at 05:32 UTC
|
Intranet or Internet... no system is 100% safe... you are describing a problem that does not require a software solution. | [reply] |
Re: OT: Storing encryption keys securely
by Anonymous Monk on Jan 24, 2017 at 19:13 UTC
|
Database encryption is largely meaningless because of this problem. Point-of-sale systems sometimes require a human to enter an encryption key to unlock them when they start up, but nobody wants to do that on the web. You might have the webserver switch to an unprivileged user so it can't get the password again after it starts up. If an attacker breaks root on your server, there's really no way to stop them.
Schneier described a way to address the password-in-memory problem in his book Applied Cryptography. He called it a "boojum"... unfortunately, I can't seem to find a good explanation of it online.
| [reply] |
|
Boojum is described here.
Essentially it consists of generating a random number, and xoring the secret data with that random number, and then storing both xored data and the random number in different places in memory. When the secret value is required, xoring the two back together recovers it; but the actual secret doesn't appear anywhere in memory.
It goes on to suggest generating a new random number and re-xoring once a second, and trying to ensure that both pieces of data are stored on different chips.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |