Web Development

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?

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.

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. How so? Knowing the algorithm won't get them the keys. I'm not storing financial information, it's more of an admin tool. 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.

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.

If you agree it's a fallacy, then what were you suggesting with: 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.