in reply to encrypt passwords

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.

Replies are listed 'Best First'.
Re^2: encrypt passwords
by BrowserUk (Patriarch) on Apr 17, 2015 at 14:21 UTC
    By definition, the software would have to have some means of decrypting the password,

    No, there doesn't have to be any means of decrypting the passwords. Nor should there be.

    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.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[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 lovely sentiment, but it's a bit rose-colored. The statement only applies in a perfect world,

        That's garbage! Passwords do not need to be decrypted. Ever!

        You encrypt the password with a one-way hash and only store the hash.

        To verify: you accept the password from the user; encrypt it using the same one-way hash and compare the result against the stored, encrypted value. If they match; he's authorised.

        The password is never stored in any form that can be decrypted; and can only be discovered by encrypting every possibility and comparing them with the stored, encrypted result.

        That has been the simple, correct way to do things since forever.

        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.

        More utter twaddle. No wonder the web leaks like a sieve when the obvious is ignored by so many "experts".

        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.

        sundialsvc4 is a joke of a programmer; and you'll do yourself no good by hitching your skirts to his wagon train.

        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.
        "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
        In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom