Storing Credentials for Secured Resources? 64
diverman asks: "It is very common for web applications (be them Java, Perl, PHP, .NET, or shell script) to need knowledge about credentials to access another resource. Perhaps it's a relational database login, an FTP account for transferring files, or maybe a authentication credentials to another web service. Whatever it is, most developers have likely had to write a program that needs to keep a password for later use. The big issue now is: where do you put them?"
"Having passwords sitting around in clear-text isn't the wisest of ideas, and is against most security 'best practice' guidelines. Some apps and servers have chosen to base64 encode it (I believe WebSphere does this), and that's about as safe as clear-text. What I've been trying to find is a mechanism that behaves like how Apache loads properly signed SSL certs, that require a password when starting up the web server. The password could be used to decrypt a key-store for various application/resource credentials, and then make them available. Exact implementation isn't the question, as much as ANYTHING that does this at all. Are there any Apache modules that can place authentication information in ENV variables for executed apps, after decrypting them on server startup? Are there ways to have Java containers do something similar? It seems like this is something that is a very common problem, but not a very common question, with an even less common solution."
Perl module (Score:2)
In the application, you read the hash from the module and decrypt it prior to authentication.
Sure, someone who has both the code for the application ( which must contain the decryption routine ) and the perl module can decrypt the credentials, but it does prevent someone from reading a text / base_64 file for your username / pass
Uhh (Score:1)
Re:Uhh (Score:3, Informative)
Re:Uhh (Score:2)
Bingo.
A set of key/value pairs. There's even a wikibook on the subject:
http://en.wikibooks.org/wiki/Programming:Perl_Has
A hash of hashes is a multidimensional array.
Re:Uhh (Score:2)
I think when the parent refers to a 'hash' he means a perl hash, not a cryptographic hash.
And for those who don't use perl but did take some CS classes, a 'perl hash' is just an implementation in perl of the data structure commonly called a hash table.
So the OP was proposing implementing a library that provided password lookup services. Applications would submit a keyword to the library and get back the password needed for authentication.
I guess the goal is to make the attacker's life very easy by p
Re:Perl module (Score:2)
And where do you get the encryption key from?
However, it would be pretty easy to write a mod_perl module that asks for a passphrase at server start time, decrypts the database password, and sticks it in an environment variable (or the Apache->server object).
I'm not sure what security advantage this provides, though. If your password file is only readable by root, then your system would be compromised by the time the attacker got the password. As root, you can chan
Re:Perl module (Score:2)
I really wonder, however, if anyone actually has an implementation for this issue. I guess
Re:Perl module (Score:2)
Re:Perl module (Score:2)
In all honesty, I would think that such an feature/module would be something that many would benefit
Re:Perl module (Score:2)
here (Score:2)
Re:here (Score:2)
PasswordSafe pretty good, and has several linux ports
Okay, so where do you put the passphrase used to secure the PasswordSafe database?
Re:here (Score:1)
You put it in another PasswordSafe database! Duh!
Re:here (Score:2)
But yeah i confess, i didn't even read the summary before posting this one
Re:here (Score:2)
Most?!? (Score:3, Funny)
MOST?!?
Which security guidlines say it is ok and what companies are using them?
Re:Most?!? (Score:3, Insightful)
Which security guidlines say it is ok and what companies are using them?
Companies that build real security systems often intentionally store on-disk passwords in cleartext, just to make the point that on-disk passwords are inherently insecure -- no matter how you obfuscate them -- and to encourage the use of hardware security modules.
Re:Most?!? (Score:2)
Personally, I consider El-Gamal to be encryption rather than "obfuscation", and quite happily store authentication token ciphertext in mysql.
Hasn't scratched yet.
Re:Most?!? (Score:3, Insightful)
Personally, I consider El-Gamal to be encryption rather than "obfuscation", and quite happily store authentication token ciphertext in mysql.
And where do you store the decryption key? It's still just obfuscation, no matter how good the cipher is, as long as the attacker can get the key.
Re:Most?!? (Score:2)
Re:Most?!? (Score:2)
In an encrypted keychain, naturally. It's standard best practice.
And where is the password that unlocks that keychain? You can continue pushing the issue away as many layers as you like, but at some point you have to have the secret that unlocks all of the rest of the secrets, and the question remains -- where do you put that? As long as the application has to have unattended access to it, all the rest is just layers of obfuscation.
Re:Most?!? (Score:2)
that plaintext is "obfuscated" by the physical complications of access to it. It doesn't matter whether it is inside
Re:Most?!? (Score:2)
It is true that key management always boils down to obfuscation.
No, it isn't. There's a fundamental difference between storing the key in software on a general-purpose machine and storing it in a tamper-resistent (or even tamper-reactive) secure module. The difference is primarily in the location of tools required. In software, all of the information and all of the tools needed to extract the key are on the machine. They must be. In the case of the secure module, if the tools exist at all, they are
Re:Most?!? (Score:2)
It is true that key management always boils down to obfuscation.
Reading something else this morning made me realize there's another non-obfuscation case that I didn't mention in my other post: That's the case where all of the information needed to recover the key is not on the machine. For example, an encrypted store like, say, PasswordSafe. It's not obfuscaction because without the passphrase which gets hashed into a decryption key, an attacker would have to break the cryptography in order retrieve
Re:Most?!? (Score:2)
I've just started considering these questions in preparation to handle some online creditcard processing.
I had thought about the "require a password on server startup to decrypt the passwords into RAM" method, but that prevents unattended server restarts and so in the (hopefully rare) case of an unscheduled service/process restart you'd have to get onto the server and enter the password before the application would be available again. Not optimal in my opinion.
Regarding best practices I've found The Ope [owasp.org]
Re:Most?!? (Score:2)
I'm quite familiar with OWASP. I'm planning on going t
Re:Most?!? (Score:2)
Hell, if I REALLY want a secret safe, I encrypt it twice, with two significantly different algorithms, since the odds of both algorithms having a flaw is highly unlikely... but that's for the truly paranoid.
Bah. I'm about as paranoid as they come, and the odds of 3DES being broken is so small it's worth less consideration than a meteor smashing into the planet. In a few more years, I'll probably say the same of AES. The real issue that needs to be addressed is: Where do you put the keys?. Amateurs at
Re:Most?!? (Score:2)
Re:Most?!? (Score:2)
A good question to ask is how secure does it need to be in order for the level of concern to be acceptable?
Absolutely. All real-world security engineering, like all real-world engineering of any sort, is about cost vs benefit. Many of the systems that I work on fully justify the greater cost, but a lot are marginal and many clearly don't justify it, even though it would be useful if the cost were only a bit lower.
That's why I'd like to see TCPA TPMs become standard in servers, and for all of the majo
Don't use passwords (Score:5, Informative)
In the web world, CAS [ja-sig.org] provides proxy tickets, which can even be forwarded (for example, to an FTP server) as a stand-in for passwords via PAM.
Re:Don't use passwords (Score:3, Insightful)
Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management".
Sometimes. In other cases, what you want to do is to authenticate the server that is making the request. The user's identity isn't relevant, and that user may not even have any privileges to use the protected service directly. Instead, the "front end" service cares about who the user is and is willing to make some requests of the back-end service on the user's behalf, so it's actua
Re:Don't use passwords (Score:2)
What you really want for identity is a token that is easy for the owner to create, easy to validate, and very hard to capture and replay. Beyond Kerberos, X.509 certifica
Re:Don't use passwords (Score:2)
So, while it would be
You really have little choice (Score:2)
If you require access to a remote resource that wants some kind of credentials
presented, and you don't want to get a human involved, then you have little choice
other than to store something that someone could take a copy of and use to impersonate
your system.
Set file permissions properly. Make password-containing config files only readable by the processes that need to read them. chmod 0400. Keep each of your apps separated in this way so that a compromise of one doesn't affect the others. This is the be
Re:You really have little choice (Score:2)
Re:You really have little choice (Score:2)
Re:You really have little choice (Score:2)
However, if the credentials used by apps are encrypted (cryptographically strong) and the decryption passphrase is entered only at the time of server startup, then a physical compromise of the system, backup tapes, or the harddrive will not result in a compromise of your secret information. The attacker would still need to know the passphrase used when starting up the system... which is s
Re:You really have little choice (Score:2)
What I was asking about protects much beyond using simple file permissions to protect the secrets. In your suggestion, if an application running as the web server's user (which would otherwise be needed for apps that need to read their resource credentials) were to contain a flaw allowing access to the file system, those secrets could then be disclosed. Additionally, as someone mention, a physical reboot with access to the server or a stolen hard drive, or a stolen backup
autoboot vs secure passwords (Score:4, Interesting)
There are two solutions I can think of off hand:
1. If the application allows, make the database or other sensitive resources append-only by the basic app. Further access requires the user to login with higher level credentials.
2. Have some sort of media with "read-once" properties; when the system is rebooted (which typically triggers a reset of some sort), the read-once is reset. The necessary connection parameters can be stored here then.
TPM (Score:2)
2. Have some sort of media with "read-once" properties; when the system is rebooted (which typically triggers a reset of some sort), the read-once is reset. The necessary connection parameters can be stored here then.
This is a good application for a TCPA TPM -- actually, a TPM can make this solution very strong. With a TPM, keys can be "bound" to a particular system state, as determined by the value in a register that stores a hash of all of the system state fed to it. If you encrypt the passwords (or
Obvious? (Score:3, Funny)
I'll trade a paper version for a candy bar.
I am your users!
Use a keypair and agent (Score:3, Interesting)
Whenever the agent doesn't have a key added, I can just do ssh-add, then enter my passphrase and it is stored in the agent. When I exit, that agent is left running and all scripts then source the env to get to the PID/Sock for my agent.
This works for shell scripts, but you could use it in other areas too with some code. So even if someone stole the keypair, the would have to brute force the passphrase to use it. And no passwords are kept in my scripts.
Only requirement is you add a key as soon as you reboot the box or your scripts don't work. A simple ssh-add -l will show keys and you can have the scripts exit/email error if no keys are added to the agent.
Is ssh-agent Safe? (Score:2)
Whenever the agent doesn't have a key added, I can just do ssh-add, then enter my passphrase and it is stored in the agent. When I exit, that agent is left running and all scripts then source the env to get to the PID/Sock for my agent.
I do exactly this for my rsync backup. Arguably it's really the best/only way. But what would be better is a k
Re:Use a keypair and agent (Score:2)
And there's the problem -- what if you need unattended rebooting, e.g. a box that undergoes an automated reboot to clear a problem? You won't be there to enter the passphrase for the key.
--Paul
Re:Use a keypair and agent (Score:2)
what if you need unattended rebooting, e.g. a box that undergoes an automated reboot to clear a problem?
Even if you have some sort of lousy daemon that gets wedged occasionally and has to be restarted, why would you reboot the entire machine? Just restart the service.
I could see a problem if the machine rebooted due to some other cause, though, such as a power outage that lasted longer than the UPS could manage.
Re:Use a keypair and agent (Score:2)
Granted, it's not a solution for all... but it's good for many. This is the same problem if you're using a signed SSL certificate requiring a password fo
Re:Use a keypair and agent (Score:2)
Largely, I'm looking for options for different environments that I am likely to have to review, and be able to offer solutions that are viable with given constraints.
Don't store passwords, store cryptographic hashes (Score:1, Informative)
When the user submits their password (over an encrypted channel!), you compute the salted hash for t
Re:Don't store passwords, store cryptographic hash (Score:2)
The situation is not with authenticating user input credentials, but with an application needing to authenticate to remote services/resources (ie. the database connection, an FTP connection, etc). In this case the w
Password Hash (Score:1)
The credential check would then be a comparison of the hash and a hashed entry in a database. This way, the password is never stored in plaintext.
Another method that I've seen involves a one time pad with sessions (stored on the server), so that no single side has sufficient information to determine the password. The only problem with this is that the password length would be revealed
Of course, you could then just take advantage of sessi
Re:Password Hash (Score:2)
I don't think he's talking about storing client passwords; that's a separate beast. He's talking about the password his web application uses to communicate with the database or the merchant account or WebServiceFoo or... you get the idea.
Personally I keep the passwords in an encrypted file th
Re:Password Hash (Score:2)
Anyway... I would b
It's easy. (Score:3, Funny)
Put it into a tiny sample jar of pineapple jam which you give to your aunt Emma (aunt Emma doesn't like pineapple jam) for her to put in the barley hopper. So, this way, nobody will know the password and be able to know, unless they read /.
Problem is retarded 'complexity' requirements (Score:4, Informative)
Pick a person's name, say, Annakin.
Add a number or two to the name, Annakin123.
When the password expires, change to Annakin234, then Annakin345...
3) Profit!
Our AD guys are constantly battling the Infosec weenies who claim we need to have even stricter passwd policies, which will result in even MORE Post-It notes underneath keyboards.
If you share an account over which you have no control, get Passkeeper, or develop a "seed" algorithm, that knowing the code, and the seed word, and the hostname, you can derive the password, so you can easily remember it, i.e.
Seed is "slash"
Algorithm = seed + 3rd octet of hostname + first letter of hostname + last letter of hostname.
(or similar, I just thought this up off the top of my head)
Immune to all but dictionary attacks, and you and coworkers can easily derive it on the fly.
Potential security breach? Just change the seed word.
Your InfoSec guys are idiots (Score:2)
If your company has InfoSec guys, it can afford an audit to point out that they're idiots. If your InfoSec guys are confident they'll be happy for outside verification. As you say, Post-It notes. If security is really that important y'all need to be relying on multi-factor authentication, not some dork who wants attention.
There are other options (Score:2)
Re:There are other options (Score:2)
JBoss has something for this (Score:2)
A coworker who has also been looking for options on this came across this page on JBoss's site. At first glance, it seems this is an attempt to deal with the issue first mentioned. I think it's JBoss specific though. And it's just an interface. And of course, RedHat bought them, so who knows what the future of JBoss will be.
Re:JBoss has something for this (Score:2)
http://forum.java.sun.com/thread.jspa?threadID=55