Re^4: encrypt passwords

[BrowserUk]

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.

[marinersk]

BrowserUk, I have a great respect for your abilities in algorithmic and systemic thinking -- and thus, from an engineering perspective, I find myself siding with you very nearly always.

So I am left to conclude that either I am not describing the problem sufficiently, or you are missing something. I'd be interested to see which.

So -- how would you address this situation:

You work for a company which has a heavily distributed base of employees. Culturally, policy and responsibility is pushed down to the lowest level; there is very little truly controlled from a central location.

The culture also honors this approach, taking the cost of destandardization as a good trade for increased productivity from empowering the individual and permitting local management to . . . well, manage. So you will be limited in making cultural, procedural, and administrative changes.

However, you have locally-controlled, but corporately-accessible databases scattered all over the company, and one of the things that is needed is for people to query these various databases a lot -- custom work, looking for things happening in other parts of the company in an effort to exploit prior art and use already-invented wheels rather than inventing new ones.

It's been this way for decades, and, of necessity, they've gotten good at it.

Someone at some point built a system which kept track of all the access credentials, so these folks can code up a Perl script which goes and snags a bunch of data, correlates it the way they want, and so on. This, too, has been in use for more than a decade. Everyone knows the process, and uses it effectively.

It is seen as too costly to revamp the way work is done. Management likes what happens when localized empowerment couples with centralized access -- so you're stuck with people calling this centralized routine to get the database, instance, port, username, password, etc., and feed it into whatever routines they've written to query the various databases from their Perl scripts.

But someone has caught on to the idea that keeping the passwords in clear text is a bad idea. Since that's controlled managed centrally, it's an area where you can make some changes.

What approach would you take to try to lessen the impact of cleartext passwords in a Perl module? Remember that these folks still have to be able to access the same databases, which are not centrally controlled.

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

Update: Department of Redundancy Department
Update: Verbiage adjust

[BrowserUk]

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.

[marinersk]

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.