Storing Passwords


Login or Register to Reply

 
Thread Tools Search this Thread
# 1  
Storing Passwords

Yes, it's that minefield again. I'm building an AJAX database interface which uses maria/mysql logins instead of keeping a bunch of its own private logins, to try and keep it simple.

The thorny bit is, of course, the passwords. Doing this requires it to remember passwords between sessions, not merely hashes but reversibly-encrypted passwords. I think I've built something like "ssh-agent" for databases, which keeps a key without leaving it wide-open to the world, but I want your feedback on it.

When the PHP session begins, the server generates a pair of 16-digit strings. One is kept in the server-side PHP session and never given to the user, the other is kept in a client-side cookie and never stored on the server. The concatenation of both strings is used to ENCODE() the password before storing it. It also records and validates your session ID and IP address, so someone can't steal the cookie and pretend to be you. Only the conjunction of a valid cookie with a valid login decrypts a valid password.

It sounds strong enough to me but encryption is not my forte. Are there any giant holes in this scheme?

Last edited by Corona688; 12-16-2014 at 05:04 PM..
# 2  
My only comment is:

Key management is an absolute pain in the butt.

Regarding keys -- When not in use (ie standing somewhere) the half-keys should be encrypted - both on the user side and the system side. Otherwise they are sitting ducks. Largely for internal attacks. Because internal people are less likely to set off security alarms or be seen in scans.

Whenever someone cracks your code for the key encryption algorithm, then they win. Period.

IMO, in this situation you have to affix value as an ROI to an operation. The ROI is the return on investment - your time, money, and effort.

There is always somebody who will claim such and such can be cracked. This is fog.
Unless forward perfect secrecy is mandated take a value-based approach.

And if theoretical cracking may be true: are you providing code where FIPS 140-3 is mandated? FIPS 140-3 - Wikipedia, the free encyclopedia

If not mandated, then what you try to do is make it hard to crack what you have done to encrypt things. Is it worth the costs of getting to perfect? - if it exists.

If you use a decent block cipher, you are good. If somebody can reverse engineer code, or get your source easily, then most things you can do are pointless. Shell coders love source. That is the ROI I'm talking about. Spend resource in several areas for much bigger return.

This is a values call, not something completely subject to theorematic analysis. It ain't black and white.

And. key-keeping and encryption is only 1/20th of security. User hygiene (keep malware off user desktops), least privilege, password quality and ageing, and all sorts of physical security methods are required, i.e., VPN, firewall, DMZ, carefully controlled access to tapes and data centers, locked doors and file cabinets, etc.

Bottomline:
Make it hard enough on the bad guys so they go somewhere else.
If the equivalent of a stuxnet is attacking your system, you are dead. No matter what you do.
# 3  
Quote:
Originally Posted by jim mcnamara
Regarding keys -- When not in use (ie standing somewhere) the half-keys should be encrypted - both on the user side and the system side. Otherwise they are sitting ducks.
How does one avoid the rube goldberg problem, though? That being, extra encryption/decryption steps where the server knows its own key gains nothing but extra heat and wasted time.
Quote:
Whenever someone cracks your code for the key encryption algorithm, then they win. Period.
How so? Knowing the algorithm won't get them the keys.
Quote:
Unless forward perfect secrecy is mandated take a value-based approach.
I'm not storing financial information, it's more of an admin tool.
Quote:
If somebody can reverse engineer code, or get your source easily, then most things you can do are pointless.
Again, how? Knowing the algorithm does not hand them the keys -- it tells them what they need to steal, but does not give them access.
# 4  
Source code gives them where the keys are stored, if they can get to code.

The point is not any of the above. Where do you store the key to decrypt the half-key?
This is a logical fallacy. It is called circular reasoning. I need a key to decrypt a key. I still have to store that secondary key somewhere, or the system will have to regenerate it. Regenerate means I can see it in the source. Storage means it is a sitting duck, unencrypted.

I agree that simply having the algorithm and knowing the block cipher is not a complete solution, but the logic behind this needs some work. Having the source also means shell code or another crack is now a possibility.

There is far more to security than passwords. We have a large number of fairly insecure old unpatchable windows servers. They have many known exploits. They are pretty safe.

Why? Because getting to them externally is really hard, you have to hack several external software and physical barriers to get at them. But they could be trashed by an internal employee easily. So we have to have trust somewhere. ROI.
# 5  
Quote:
Originally Posted by jim mcnamara
The point is not any of the above. Where do you store the key to decrypt the half-key?

This is a logical fallacy. It is called circular reasoning. I need a key to decrypt a key. I still have to store that secondary key somewhere, or the system will have to regenerate it. Regenerate means I can see it in the source. Storage means it is a sitting duck, unencrypted.
If you agree it's a fallacy, then what were you suggesting with:
Quote:
...the half-keys should be encrypted - both on the user side and the system side.
Unless your point was simply that you shouldn't keep them around indefinitely in retrievable form -- and I don't. I don't encrypt them though, just delete them at regular intervals, as the session times out.
Login or Register to Reply

|
Thread Tools Search this Thread
Search this Thread:
Advanced Search

More UNIX and Linux Forum Topics You Might Find Helpful
When did UNIX start using encrypted passwords, and not displaying passwords when you type them in?
Anne Neville
I've been using various versions of UNIX and Linux since 1993, and I've never run across one that showed your password as you type it in when you log in, or one that stored passwords in plain text rather than encrypted. I'm writing a script for work for a security audit, and two of the...... UNIX for Advanced & Expert Users
5
UNIX for Advanced & Expert Users
passwords
earlysame55
Dear all, I need to automate/script a user password change process. I'm helpless cannot use expect since it's not installed and cannot install it either. Do i have an alternative. I can store the password in a file and that would be the password that would be set to all the users. If not i don't...... Shell Programming and Scripting
1
Shell Programming and Scripting
Storing ssh passwords/keys in keychain
Haggardly
Can anyone tell me how to set up ssh and keychain so when I connect to the remote system it uses keychain for the password or public key? The remote system is FreeBSD 8.0. Do I need to setup anything else on that end? Cheers.... OS X (Apple)
0
OS X (Apple)
Passwords
turner.rd
I am running unix 11.xxx....How do you change a user password. The previous vs was passwd at the command prompt. This no longer works. Thanks for the help... UNIX for Dummies Questions & Answers
3
UNIX for Dummies Questions & Answers

Featured Tech Videos