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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^7: encrypt passwords
by marinersk (Priest) on Apr 17, 2015 at 22:13 UTC | |
by BrowserUk (Patriarch) on Apr 17, 2015 at 23:18 UTC | |
by marinersk (Priest) on Apr 18, 2015 at 01:43 UTC | |
by BrowserUk (Patriarch) on Apr 18, 2015 at 07:45 UTC | |
by marinersk (Priest) on Apr 19, 2015 at 02:53 UTC | |
| |
by AnomalousMonk (Archbishop) on Apr 18, 2015 at 04:09 UTC | |
by marinersk (Priest) on Apr 19, 2015 at 02:55 UTC |