|
fionbarr has asked for the wisdom of the Perl Monks concerning the following question:
working Crypt::CBC example
use strict;
use warnings;
use Crypt::CBC;
my $cipher = Crypt::CBC->new(
-key => 'goldfish',
-cipher => 'Blowfish'
);
my $string = 'some data';
my $encrypted_string = encrypt("$string");
my $decrypted_string = decrypt($encrypted_string);
print "\n$string\n";
print "\n$encrypted_string\n";
print "\n$decrypted_string\n";
# -----------------------------------------------------------
sub encrypt {
my $str = shift;
return ( $cipher->encrypt_hex($str) );
}
# -----------------------------------------------------------
# -----------------------------------------------------------
sub decrypt {
my $str = shift;
return ( $cipher->decrypt( pack( "H*", $str ) ) );
}
# -----------------------------------------------------------
|
Re: encrypt passwords
by mr_mischief (Monsignor) on Apr 17, 2015 at 18:18 UTC
|
TL;DR :: OP should use Kerberos or PAM or some other pluggable authentication method on the MySQL end.
I think the discussion is about the particular case in the thread. It's absolutely true that the authentication system should have one-way hashed passwords. However, the OP appears to be wanting to store actual decryptable, non-hashed credentials used to connect to another system.
Now there are reasons this is a bad idea, and that's what people are asserting. In the OP's case, something needs to decrypt these passwords to achieve what OP is trying to do. Therefore anyone who can access these non-hashed encrypted passwords is likely to also have access to the decryption routine, rendering encryption mostly moot. That's why it's a bad idea.
There are ways to set up a password vault that addresses some of these concerns, but anything that must run from cron is going to have a weak link in security somewhere. The cron system would need access to the vault in this case, so it's still basically plaintext passwords. The only real fix is to use something like public key cryptography.
Thankfully, database software tends to have lots of ways to authenticate. MySQL has pluggable authentication which support Kerberos, PAM, etc. Postgres has its own auth methods including GSSAPI with Kerberos.
Since this is running under cron, there's still going to be a bit of a weak link in that some likely unmanned and unwatched user account will house the private keys, but it's still a lot better than depending on plaintext passwords on disk.
Edit: changed version-specific URL to track current version for Postgresql after a suggestion from erix
| [reply] |
|
|
In the Linux environment, PAM is usually the “glue” that is ordinarily used, as it was designed and intended to be, although implementations vary. “Password” authentication is commonly superseded, and even disallowed. Thus, the corporate security team has definitive and exclusive control. (A “password” alternative would be tantamount to a “back door,” from their very-sensible point of view.)
| [reply] |
|
|
| [reply] |
Re: encrypt passwords
by vinoth.ree (Monsignor) on Apr 17, 2015 at 12:37 UTC
|
Unfortunately, if you store an encrypted password in a file, you'll also have to store the decryption method, so an attacker can run the decryption and recover your password.
All is well. I learn by answering your questions...
| [reply] |
|
|
"...if you store an encrypted password in a file, you'll also have to store the decryption method..."
Cautious reply, as always ;-)
I think this isn't mandatory. What made you jump to this conclusion - with the poor information given by the OP?
Regards, Karl
«The Crux of the Biscuit is the Apostrophe»
| [reply] |
|
|
As he wanted to store the passwords encrypted, how does he gets the original password afterwards ? somewhere he should have method to decrypt and get the original password to use.
Alternatively we can have configuration files to hold the password, like in this node Re: best way to store login information for a perl script?, Your Mother explained.
All is well. I learn by answering your questions...
| [reply] |
|
|
|
|
|
|
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
Re: encrypt passwords
by karlgoethebier (Abbot) on Apr 17, 2015 at 12:13 UTC
|
| [reply] |
|
|
@LoH = (
{
database => 'PQxxxxLD',
hostname => 'wpx0z051xsi.xxxx.com',
servicename => 'pqospxxxbld.xxxx.com',
port => '9010',
username => 'username',
password => 'password',
} env => 'prod',
)
This data is stored in a Perl module. There will be perhaps 100 databases. The program is run vi a cron file and there is no user action so
the vulnerablity is only through the info stored in the program code. I'm thinking of having two columns in a
protected table where one column is the plain-text key and the other column is the actual password | [reply]
[d/l] |
|
|
| [reply] |
|
|
|
|
Re: encrypt passwords
by sundialsvc4 (Abbot) on Apr 17, 2015 at 15:02 UTC
|
Since we seem to be on the general subject of authentication and authorization, here’s a good introduction to how LDAP, Kerberos, and RADIUS technologies work together. There are many others, including quite a few from Microsoft and Apple, both of whom embraced these things a long time ago.
To briefly quote three bullet-points from that article:
- LDAP - The Who, What, and How: LDAP is what's called a Directory System. It‘s a database system, essentially, used to store information about the various entities on your network ...
-
Kerberos - I’m really who I say I am: While LDAP stores the information about you, Kerberos is responsible for telling services on the network who you are ...
-
RADIUS - He’s with me, let him in: Unless a device is actually on the network, it can’t use Kerberos (or LDAP) to authenticate itself. But your network would hardly be secure if you allowed anyone to connect to it without authenticating themselves first. This Catch-22 has been solved using a system called RADIUS ...
| [reply] |
Re: encrypt passwords
by sundialsvc4 (Abbot) on Apr 17, 2015 at 14:11 UTC
|
Naturally, “a file of several hundred database passwords” would be a juicy prize. By definition, the software would have to have some means of decrypting the password, which means that anyone who stole the software (presuming that the password table is most-likely embedded somewhere in it), would get the prize. He would, by definition, possess both the encrypted values and the means to decrypt it. (Even if, as sometimes is done, some additional secret (sic) word must be entered separately.) No matter how you try to dress it up, it’s never good enough.
Long and short of it is ... you really don’t want to do it that way, at all. Instead, use LDAP (nee OpenDirectory, or Kerberos, etc.) to specify the autonomous program’s “role” and the permissions that “he” is therefore to have. The central authentication mechanism takes care of identifying the autonomous program (and the specific computer that it’s on), and of informing the database server what this program is permitted to do, without any further challenge. There’s no monkey-business of: “prove it, say the magic word.”
The program, being recognized, can do what he is authorized to do. (And every such request is specifically identified by the database server as “known to be coming from him.)” None of the rules that are used to authenticate, and none of the rules subsequently used to authorize, are anywhere within reach. If the program is compromised, a few clicks on a distant security-console and the authentication drops-dead on the spot. A few more clicks on the security-log then provide a complete run-down of what this credential had done.
Furthermore, it is highly desirable to carry this strategy one step further, to include identifying any user who’s, say, making requests of this autonomous program. This applies also to intra-net websites: ask the user for a magic word if you want to, but don’t allow a user who’s not authorized to be there, to even get the opportunity to enter one. (“Web-site? What web-site? Nahh, never heard of it. It’s 404 Not Found for you, pal.”)
Every database server, et al, out there, has the ability to do these things. (And Perl, of course, can query LDAP, Kerberos, etc., too.) Don’t authenticate based on what a user or a program “knows.” Rely on an independent, trusted authority, used enterprise-wide, that knows who he is. Trustworthy, open, technologies exist that can even do this across the public Internet, and your enterprise is already using them.
| [reply] |
|
|
| [reply] |
|
|
No, there doesn't have to be any means of decrypting the passwords. Nor should there be.
A lovely sentiment, but it's a bit rose-colored. The statement only applies in a perfect world, and many of us are stuck keeping an imperfect world running effectively and doing what we can to make it better within the confines of limited resources (including time, as well as arbitrary process rules).
If you are handed a system where thousands of access routines managed by hundreds of non-IT folks are being used, the task of converting their access to more modernized and secure authentication techniques may not be permissible.
Under those circumstances, obfuscation may be your only hope (Obi-wan).
While I generally agree that the only thing worse than bad security is fake security, there are times when that's the only tool left in the toolbox.
In the end, our job is to help. Sometimes poorly, sometimes over-constrainedly -- but help, as best we can, is the mission.
I can already hear sundialsvc4's skin crinkling as he cringes at all the things that will go wrong in the future when such a decision is made -- and he's right.
I suppose if you really felt strongly about it you could stake your job on it say 'no' to your boss.
To that I can only say: Choose your battles wisely.
| [reply] |
|
|
|
|
| A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
