Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Storing Credentials for Secured Resources? 64

Posted by Cliff from the security-and-web-applications dept.
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."
This discussion has been archived. No new comments can be posted.

Storing Credentials for Secured Resources? More

Storing Credentials for Secured Resources?

Comments Filter:
  • For perl, you could use a module which contains a hash of hashes. This stores only cyphertext keyed to values ( username => 'qifhhfwqe', password => 'aiuherg' for instance ).

    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
    • Hashes can't be decrypted (at least, the ideal hash cannot). That's why they're so secure (ideally, again). When the user enters a password, that password is hashed and compared with the stored hash. Thus the real password is never required to be decrypted or exposed.

      • Re:Uhh (Score:3, Informative)

        by Phillup ( 317168 )
        I think when the parent refers to a 'hash' he means a perl hash, not a cryptographic hash.
        • I think when the parent refers to a 'hash' he means a perl hash, not a cryptographic hash.


          Bingo.

          A set of key/value pairs. There's even a wikibook on the subject:
          http://en.wikibooks.org/wiki/Programming:Perl_Hash _Variables [wikibooks.org]

          A hash of hashes is a multidimensional array.

        • 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

    • > decrypt it prior to authentication

      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
      • Yes. That was my question when I read this first reply. An encryption of values is exactly what I was proposing (whether it's ain a Perl hash or any other implementation). The real key, however, is being PROMPTED for a password on server start. Anything other than prompting would require storing it on the server, and thus compromising the notion of truly securing those secrets (ie. the passwords and credentials).

        I really wonder, however, if anyone actually has an implementation for this issue. I guess
        • If you didn't get a satisfactory answer, e-mail me and I'll code this module up. I don't really like the way we're doing password management at work right now, and this is an improvement. (I have to type the passphrase for the SSL keys anyway, one more doesn't make a difference.)
          • Thanks. I don't have a specific need exactly. However, the question has come up a number of times in the last few months (I work as an application security analyst), and know what would be a good idea in certain environments, but not have an existing solution. I was about to just write an apache module myself (thought it'd be an interesting project to try at least once)... but just never got around to it.

            In all honesty, I would think that such an feature/module would be something that many would benefit
  • PasswordSafe [sourceforge.net] pretty good, and has several linux ports

  • Most?!? (Score:3, Funny)

    by NevarMore ( 248971 ) on Friday April 21, 2006 @06:00PM (#15177624) Homepage Journal
    "Having passwords sitting around in clear-text isn't the wisest of ideas, and is against most security 'best practice' guidelines."

    MOST?!?

    Which security guidlines say it is ok and what companies are using them?

    • Re:Most?!? (Score:3, Insightful)

      by swillden ( 191260 )

      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.

      • I'm sure that companies who build disk encryption hardware do.

        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)

          by swillden ( 191260 )

          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.

          • In an encrypted keychain, naturally. It's standard best practice.

            • 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.

              • It is true that key management always boils down to obfuscation. For example, I obfuscate the key stored on a USB flash drive by putting it in my pocket, or I might obfuscate it by putting it in a locked, armored safe. If these are the semantics of obfuscation, I am content to play the game according to your rules, now that they are clear. As long as a computer must operate on a plaintext,
                that plaintext is "obfuscated" by the physical complications of access to it. It doesn't matter whether it is inside

                • 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

                • 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

    • 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]

      • True, a password on restart does create an issue with unintentional system restarts. Although, how often do those occur? And do you really want your system becoming publicly available when it unintentionally reboots? You have the same issue with a signed SSL cert. Personally, I'd rather a system be unavailable on an unintentional reboot until it can be reviewed. In an enterprise environment, the server is likely part of a cluster or balanced group.

        I'm quite familiar with OWASP. I'm planning on going t

        • 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

          • I totally agree. Other solutions are likely better than sticking with passwords if you're wanting to clamp down even more. I think that there are degrees of security, degrees of due diligence, degrees of concern. A good question to ask is how secure does it need to be in order for the level of concern to be acceptable? In most cases, we are talking about business decision to weigh against the pros and cons of various measures of securing information. Much like people who argue that human intervention f

            • 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)

    by forsetti ( 158019 ) on Friday April 21, 2006 @06:08PM (#15177669)
    Passwords are for "Authentication". Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management". Do not use passwords are your Identity Token. Look at technologies like Kerberos, which use your password for authentication, give you a identity token in the form of a TGT (Ticket Granting Ticket), and then allow you to request unique (and optionally forwardable) tokens for each service you are looking to access.

    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.

    • 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

    • Absolutely right. Passwords are a way for humans to authenticate, not the only way and not even the best way. Identity is quite another matter. In an identity sense, passwords hold the same position as symmetric keys, trivial to replay if ever captured. For this reason, they're terrible as a way for systems to identify to each other.

      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

    • This makes an assumption about the technologies available and supported. Sure, a single sign-on, ticket-based authentication/identity management solution would be great. However, that is not always a reality. I'd even venture to say it is much less often a reality. I've known many who try to go down this path, and seem to run into problems with systems that do not support them, and then try to come up with a hack to make it work, ultimately creating vulnerabilities with their hack.

      So, while it would be

  • 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

    • chmod 0400 doesn't do jack if I can boot your machine into single user mode from CD.
      • Which is why I said "It's the best you can do".
    • Sorry, but I completely disagree.

      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)

    by vanyel ( 28049 ) * on Friday April 21, 2006 @06:27PM (#15177803) Journal
    You either have to store passwords on the system in a way that programs can get to them, which no matter what you do, is insecure, or you have to have someone there whenever the system reboots. And if you've got a vhost server with hundreds or thousands of domains hosted...

    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.

    • 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)

    by Ahnteis ( 746045 ) on Friday April 21, 2006 @06:31PM (#15177831)
    Plain text. On my desktop. Named "sensitive passwords.txt".

    I'll trade a paper version for a candy bar. :)

    I am your users!

  • Use a keypair and agent (Score:3, Interesting)

    by linuxkrn ( 635044 ) <gwatson@lRASPinuxlogin.com minus berry> on Friday April 21, 2006 @06:40PM (#15177884)
    I do this on my servers without using passwords. What I have is a keypair (ssh) that has a very long (256+ chars) passphrase. Then I have a ssh-agent running on the box. Each bash script then sources a file I create in ~/.ssh/my-agent.env that sets $SSH_AGENT_PID and $SSH_AUTH_SOCK.

    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.
    • ... Then I have a ssh-agent running on the box. Each bash script then sources a file I create in ~/.ssh/my-agent.env that sets $SSH_AGENT_PID and $SSH_AUTH_SOCK.

      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

    • 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.

      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

      • 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.

      • That's true. Needing a password on entry is a problem if you have a requirement of allowing a system to perform unattended reboots. In many environments, however, this is not an issue. In most cases, I rather a server NOT come back on its own if it somehow reboots on its own. If I'm not rebooting it, I question the trustworthiness of the system anyway.

        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
    • Hmmm... possibly a viable solution in some situations. Thanks. I'll have to look at what ssh-agent can offer and how easily it can be utilized by web apps.

      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)

    by Anonymous Coward
    One approach is to compute a salted cryptographic hash of the user's password and store that instead of the password. A cryptographic hash is a fixed-length 'fingerprint' of some string and provides reasonable guarantees that, given a particular hash it is difficult to determine the string that created it (i.e. the original password) and that finding any string that results in the same hash is also difficult.

    When the user submits their password (over an encrypted channel!), you compute the salted hash for t
    • I think you missed the point. This is not storing passwords for the purposes of authenticating users that enter their passwords. Yes, in that case, a hash function should be used (although, why anyone would reimplement such a thing that has been implemented a billions times over is beyond me).

      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
  • Why not just store the username/a hash of the password in a cookie?
    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

    • Why not just store the username/a hash of the password in a cookie? 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.

      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

      • Yes, you are right about the clarification of what I was asking. So then, my question to you... what do you use to handle the decryption and loading of passwords in memory for your applications? is it something home grown, or something out there for public use/access. I'm just surprised at the lack of solutions for this. It seems that so many applications out there still just rely on file system permissions to protect secrets, or that combined with base64 (many PHP apps come to mind).

        Anyway... I would b

  • It's easy. (Score:3, Funny)

    by Pig Hogger ( 10379 ) <(moc.liamg) (ta) (reggoh.gip)> on Friday April 21, 2006 @07:43PM (#15178267) Journal
    You write it encoded with a super secret reel (found in all package of Admiral Crunch Hacker Cereals) down on a piece of banana paper using cherry juice so it is only visible when you heat it with a hemp flame, then fold it in 64 and tie it up with a piece of wire, put it in a tiny ziplock bag, dip it in sealing wax and put it in a film canister, which you dip in tar, then wrap it securely in wax paper.

    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)

    by Gothmolly ( 148874 ) on Friday April 21, 2006 @11:49PM (#15179075)
    Where I work, you must have a capital letter, and at least one number. You must change it every 4 weeks, and you cannot reuse any of the last 9. I consider this just on the verge of silly, but it can easily be circumvented like so:

    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.
    • 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 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 ways than storing a password. For example in Windows ASP/ASP.NET you could use a domain account to run your app and then use windows integrated authentication on a SQL Server database.
    • True. There are other ways, and other technologies. Kerberos or other token based single sign-on oriented technologies. Domain logins are fine, IF you're using all MS-based technologies. But combine a system that needs to access an LDAP resource, a PostgreSQL database, AND an SQL Server database... it gets a little tricky. Ideally, identity-session type approaches would be ideal, but is unfortunately not standardized across the board, and not always an option. Heck, just look at one of the most common
  • http://wiki.jboss.org/wiki/Wiki.jsp?page=JaasSecu r ityDomain [jboss.org]

    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.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close