Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Eliminating userid/passwords in code

by ksublondie (Friar)
on Jul 13, 2017 at 16:56 UTC ( #1195056=perlquestion: print w/replies, xml ) Need Help??
ksublondie has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks!

In an effort to *try* to make my code more secure, I'd like to eliminate passwords from my code. So far, the "best" solution I've found is to put them into a separate encrypted file, then unencrypting/encrypting them when I need them. Are there any better solutions I'm not finding?

A lot of them are MS sql server connections from a linux/apache machine. Is there a module or solution out there that could replicate a windows authentication on linux so I don't have to hard-code passwords? I'm currently using DBI::Sybase and DBI:ODBC for my db connections.

Replies are listed 'Best First'.
Re: Eliminating userid/passwords in code
by thanos1983 (Vicar) on Jul 13, 2017 at 17:12 UTC
Re: Eliminating userid/passwords in code
by shmem (Chancellor) on Jul 13, 2017 at 23:13 UTC
    So far, the "best" solution I've found is to put them into a separate encrypted file, then unencrypting/encrypting them when I need them.

    If the encrypted token lives on the same system where the decryption key is, you've gained nothing. The key and the encrypted credential can be obtained in the same way as the plain password, just with a bit more amount of fiddling.

    So the secret has to be stored somewhere else. And the instance holding the secret has to be able to verify the requiring party to make sure it really is what it claims to be, and not being impersonated by something/someone else. That's hard - "it is damned hard to make a program fool proof, because fools are so ingenious." And good hackers (in the evil meaning of "good hackers") aren't fools.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      It is very critical(!), in any and every such discussion, to know whether one is dealing with an intranet deployment, or an internet one!

      Most of the statements that I made in my previous reply to this thread actually originate from my previous ... embarrassment(!) ... in which I had dutifully concocted an elaborate website-login mechanism that would have been entirely suitable to “the wild-and-wooly Internet,” for an ... internal-only ... intranet ... application!   Only to subsequently be told that I was entirely wasting my time.

      (In other words, “all of my oh-so-clever prestidigitations ... and they sure were gosh-darned clever(!) ... were completely unnecessary.”)

      Little did I know ... at that time ... that the application which I was then designing could not be reached at all by anyone who was not authorized (by “Corporate™”) to do so.   And, little did I know ... ditto ... that I could therefore have my web-programming simply ask whether my (authoritatively(!) known to someone else(!) ...) user, should or should not be permitted to do this-or-that.

      Oh. ... ... ... Really? ... ... How (koff, koff) very interesting ...

      Once I realized the error of my ways, existing CPAN libraries provided me with all of the interface-magic that I required to actually ask those questions, and to implement an appropriate control mechanism for this context.

      (Hey, “mea culpa” ... egg on my mustache ... I don’t mind.)

        Why don't you just write plain text?

        All those fancy markups and emphasizings make your posts look like a one-man-orchestra, complete with strung bells, whistles, pipes, strings and whatnot irrupting a candle-lit dinner for two.

        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
        "It is very critical..."


        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Re: Eliminating userid/passwords in code
by sundialsvc4 (Abbot) on Jul 13, 2017 at 19:54 UTC

    The most-common strategy that I see being used in corporations is based upon either LDAP (Microsoft OpenDirectory) or Kerberos.   MySQL sells (but does not give away for free) plugins like this, as well a Linux authentication tool that is based on “PAM = Pluggable Authentication Modules,” a Linux-only facility.   They also sell plug-ins that allow authentication wth Windows.   (A general discussion can be found e.g. over here on StackOverflow.)   All other database vendors do exactly the same thing.

    (And of course, there are good “open source” alternatives ...)

    In all cases, the general idea is that the various subsystems authenticate and authorize one another based on a central authority of some kind, instead of any sort of shared-secret, i.e. passwords.   This also means that the subsystems will not accept any sort of connection where those central mechanisms do not reach, such as “the outside world.”   The credentials within any application, if any, are just meaningless “nonces,” used only to uniquely identify the application to the central authority.

    Exactly the same concept is also routinely used to validate internal (intranet) web sites, whether-or-not those sites also include a (now, obligatory ...) password challenge.   Since your “single sign-on” login, within the Corporation, is already being validated by some central corporate authority within the same Corporation, the web server (by consulting the selfsame authority), “knows who you are,” and therefore can be informed whether you should or should not be allowed access to the internal web site.   Thus, a user who has been authorized (by the security department) to use the application might be able to do so without any apparent impediment or challenge, whereas anyone else in the company would be turned-aside at the gate.

    Fortuitously for the intranet application designer, these central authority mechanisms handle both authentication, for users and for applications, and authorization.   Your requirements are vastly easier than if you were facing the internet!   From a central console or set of consoles, the Corporate Security Department can now handle everything (for you).

    If you know that you are operating “on the inside” (such that any “outside” users are using VPN solutions to become “inside”), then I think that these strategies are definitely the right way to go.   “Shared secrets are evil” in this world.

    It goes without saying that Perl, like other languages, has a rich library of tested-and-reliable CPAN modules to provide the necessary “glue and plumbing” to make your application a Good Corporate Netizen.

      Yawn. Contradicting your previous rants. Stop googling answers and posting grade A bullplop

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1195056]
Approved by ww
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (2)
As of 2018-05-23 03:46 GMT
Find Nodes?
    Voting Booth?