in reply to Re^5: encrypt passwords
in thread encrypt passwords

What would you do to try to help with the cleartext-in-module issue?

You cannot make a silk purse from a sow's ear. The system you describe is terminally broken, and layering any level of obfuscation on top does not unbreak it.

In world where most data breaches are due to insiders not external hackers, any mechanism based upon trusting your employees is broken.

When all that is needed to "discover" the obfuscated password is to run the script with perl -d:Trace theScriptThatContainsThePassword.pl > secrets then grep the output for the connection string; anything that happens before password is passed as plain text, is irrelevant. If the script is accessible to the "bad guy", then any passwords it contains, however "concealed" are also accessible. And if the script is not accessible, then the obfuscation is redundant.

I would make it clear that anything less than a proper revamp of the authentication mechanism is a pointless exercise that will cost money and achieve nothing.

In the Windows environment, single sign-on (integrated authentication), is the norm. From what I read (briefly scan) this is known as GSSAPI in *nix world.

Basically, compliant DBs map the calling processes logon ID to a DB role and access is granted based upon the DBs role definitions.


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

Replies are listed 'Best First'.
Re^7: encrypt passwords
by marinersk (Priest) on Apr 17, 2015 at 22:13 UTC

    In summary, even you are admitting that without compromise, your only recourse is to tell your boss 'no'.

    If you aren't going to tell your boss 'no', the remaining choice is to compromise and get the cleartext passwords out of the module as requested. It's a feeble endeavor, to be sure, but it satisfies the request under its given constraints.

    You have offered no alternative; in the absence of one, what is given is considered sufficiently proven for management.

    Now -- I concur that under those constraints, the system cannot be unbroken. I argue that it can be made, however marginally, better.

    Yes, someone who speaks Perl (or any of a dozen other C-like languages) will probably be able to hack the passwords if they have access to the module. But that does add a layer of knowledge required.

    As they say in some southern regions in the USA, "It ain't much -- but it ain't nuthin'."

    All of this is moot in the face of the actual task requested: Get the cleartext passwords out of the Perl module.

    However stupid, however, moronic, however pointless, ultimately your job is to advise your boss, and then to do what your boss says -- or leave.

    Those skilled in manipulating the politics and culture of a company have additional options; these are not directly available to me. I couldn't sell water to a rich man crawling across the Arizona desert.

    I could write a Perl script to find the closest convenience store, though.

      In summary, even you are admitting that without compromise, your only recourse is to tell your boss 'no'.

      If that's your summary, you didn't read what I wrote.

      You don't tell your boss: "No!". You tell your boss: "There are things we could do, but there is no point in doing them." And then you explain why.

      You have offered no alternative

      I have. Fix the authentication mechanism. Properly.

      To get into the detail of how to go about that would require much more than your vague description.

      Yes, someone who speaks Perl (or any of a dozen other C-like languages) will probably be able to hack the passwords if they have access to the module. But that does add a layer of knowledge required.

      Sorry, but protecting against those with no skills is like wearing a pinafore in a war zone.

      And offering obfuscation as security is tantamount to fraud.


      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

        As usual, I have no particular argument with the facts you have presented; only that you are ignoring facts presented to you.

        You tell your boss the right way to fix it. He says,

              "Well, Mike Richardson owns that server. He set it up, his people maintain it, and we've asked him to change authentication to something which can be globalized. But he won't budge. And my management won't back me on trying to force him to change the way he does business -- it just isn't in our corporate culture.      
         
        However, they do have a bug up their behind about getting cleartext passwords out of this module.
         
        Short of revamping the entire system, which I cannot do, what can you do for me to meet this requirement?"

        So, esteemed BrowserUk, I ask you again -- laying out more fully what I suspect you were smart enough to know was my point all along -- what is your response in this hypothetical situation? Is this really the issue you'd really stand tall on and stake your career path, or would you be inclined to bend a little, and help your boss?

        And, assuming you don't choose to tender your resignation (or at least put the nail in the coffin of your future with this company), what would your approach be toward developing a solution for your boss?

        Which comes as close as I dare to presenting a condition which might require the assistance requested by the OP.