Storing Passwords


 
Thread Tools Search this Thread
Top Forums Web Development Storing Passwords
# 1  
Old 12-16-2014
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  
Old 12-16-2014
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  
Old 12-16-2014
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  
Old 12-16-2014
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  
Old 12-16-2014
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 Ask a Question

Previous Thread | Next Thread

9 More Discussions You Might Find Interesting

1. HP-UX

Passwords and shadows

version 11.22 1 - In this version there is the shadow file by default?. If so why when I search the file I get "No / etc / shadow file found"? 2 - What does the "*" in etc / password? at the beginning of each password? (1 Reply)
Discussion started by: shinju15
1 Replies

2. UNIX for Advanced & Expert Users

When did UNIX start using encrypted passwords, and not displaying passwords when you type them in?

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... (5 Replies)
Discussion started by: Anne Neville
5 Replies

3. Shell Programming and Scripting

passwords

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... (1 Reply)
Discussion started by: earlysame55
1 Replies

4. OS X (Apple)

Storing ssh passwords/keys in keychain

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. (0 Replies)
Discussion started by: Haggardly
0 Replies

5. UNIX for Advanced & Expert Users

About unix passwords.

How the unix is maintaining the password ? How it does the encryption and how the passwords are stored in the system and where it is stored ? How it is better when compared to other OS ? (1 Reply)
Discussion started by: nagalenoj
1 Replies

6. AIX

passwords encryption

I want to store a password of a user in a encrypted format and the use that encrypted password in my shell scripting. can any one of you let me know how to do it. Thanks in advance (0 Replies)
Discussion started by: kalpana.anuga
0 Replies

7. UNIX for Dummies Questions & Answers

sqlplus and passwords

Hope I'm in the right place to ask this. ... and I'm a total noob by the way. When changing an account password through telnet, everything seems fine. I can telnet back in afterward, but if I try to use sqlplus to get in it tells me password invalid. If I try to get in through sqlplus with the... (1 Reply)
Discussion started by: tazman4
1 Replies

8. Shell Programming and Scripting

Hide Passwords

Is there a way not to display the password in the sys out when your korn shell script logs into sqlplus? (3 Replies)
Discussion started by: lesstjm
3 Replies

9. UNIX for Dummies Questions & Answers

Passwords

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 (3 Replies)
Discussion started by: turner.rd
3 Replies
Login or Register to Ask a Question