in reply to Re^2: OT: Storing encryption keys securely
in thread OT: Storing encryption keys securely

> 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,

Replies are listed 'Best First'.
Re^4: OT: Storing encryption keys securely
by Beatnik (Parson) on Jan 24, 2017 at 13:40 UTC
    Thanks for the feedback!!

    Technically, you could already host the database on a secondary server. Either way, there has to be a conduit to the application server (which can be exploited). Adding a second host to the setup (for smaller applications), will not make your users happy. Additionally, the DB credentials also are stored somewhere (code or other place). To be honest, I don't know that many applications that use an outside authentication service for the system keys/passphrases. There's always systems like TACACS+, RADIUS, LDAP but in some way, shape or form, they all require a key of their own to confirm and with the key, it's fairly simple to decode the authentication stream and find out the functional credentials. What I meant by password recovery is that if you 'forget' the encryption keys, there's no way of easily changing the keyphrase. I agree that a passphrase on startup sounds a good idea but it still needs to be stored somewhere, even in memory.. Plus, it's preventing a normal startup process. I can't recall any applications that take this approach. Having a compiled application, for instance, to hide the keyphrase is only slightly less effective as it should be fairly easy to pass the same authentication request as the script is using.

    ... I'm belgian but I don't play one on TV.