October 11th, 2013, 03:44 AM
Looking for thoughts on Password Concept
There may be a better place for this topic, but as this will be built in PHP and there are many people viewing this forum I thought I'd start it off here and see where it goes.
Currently all of my sites that I have developed requiring user login have dealt with passwords in a similar way which is to hash or encrypt the password and store it in a field in the "users" database table along with a unique username. In the early days it was just an unsalted MD5 (before I knew any better), then salted, then encrypted, then sha1 salted...as the discussions on the best methods for this went on, I felt something wasn't quite right with this method of user authentication.
Whichever method I use the fact is that I'm storing the password in some form in the database - something I don't think is quite right and decided to look for an alternative.
As my apps and my experience evolves I've now got access control and permission lists so my thought turned to something else.
When I look at file encryption, the file is encrypted with a secret key (the password). To decrypt the file I need the decryption method, the encrypted data and the password. The password isn't stored in the file anywhere...or anywhere else on the computer...only in my head. The computer takes the encrypted data, the encryption method and the key from what I type in...then I get the decrypted data
Applying the same logic to my web apps I'm considering using the password to encrypt the user's permission list - ie a list of modules they can access on successful login.
This way I don't have to store the password anywhere and I can use available industry standard encryption methods in PHP to encrypt the permissions list.
On login the username identifies the user record and their permission list. The password unlocks the permissions....if the password is correct the app gets a list of modules, if not the app either gets a false or a load of garbage it doesn't understand (either way login has failed).
One drawback I can see is that if a password is forgotten then the user is screwed....but I could keep a copy of the permission list somewhere else for re-encryption with a new password.....but this would expose the original message data (can aid in decryption or reverse engineering a usable password, I think) if ever leaked. So I looked around for an encryption method that could use two different keys to unlock it. This lead to some quite interesting pages on the internet about encryption which I didn't fully understand.
I was just wondering what other people think of this idea. Have I missed something fundamental that leaves this wide open? Are there any mechanisms for multiple possible key encryption in PHP?
Thanks for reading
October 11th, 2013, 04:36 AM
Even if you encrypt the data using a password you have effectively stored the password. why: when the user logs in you get his password and you use it to decrypt the secret data. You only have the password during the login so you have to store the un-encrypted data somewhere. If a hacker can get at that data and at the encrypted data the password is the only thing missing and he can start brute-forcing. granted, it's a lot of work, but so is figuring out how an sha1 was salted.
So you encrypt the permissionlist to stop hackers getting at it, and you store a copy in plaintext as a backup... uhm... :-)
October 11th, 2013, 04:48 AM
The unencrypted data would be a serialised string (eg json, xml, serialize). this would be unserialsed and turned into a PHP array, this array would be stored in the session (for example)..so the 'actual' data would only ever exist in memory while being encrypted/decrypted.
I could store a salted version of the message in another field encrypted with another password....but then this needs to be stored somewhere.....conundrum!
October 11th, 2013, 05:39 AM
Hands off of home-made security algorithms.
Do you do open heart surgeries on family members in your garage? Do you sometimes sneak into the cockpit of a fully occupied passenger plane and play a bit with the instruments? No? Then don't invent your own security protocol.
You're not a security expert (none of us is). There are no experts to peer-review and test this. And there are no oppurtunities for real-life tests. This means your chances of success are exactly zero.
If you want to, I can write down all the errors you already have in your theoretical layout. But the point is: Don't do it. You can't win, and when you fail, people will actually suffer from it (mostly your users who trust you to keep their data secure).
Today, there are exactly two ways to do secure user authentication on an average website: Password-based authentication using the brcypt hash algorithm. And public-key authentication using TLS client certificates. If your method isn't one of these two, you're doing it wrong.
I know that programmers are creative and love to come up with new ideas. But sometimes creativity is the last thing you want. When you're in a hospital, you don't want the doctors to be "creative" and try their own drugs on you all the time. You want them to make the most conservative choice possible. It's the same with application security.
October 11th, 2013, 06:05 AM
Sessions are plaintext files on disk that the webserver can read.
But my point was about your backup of the encrypted data; you said you'd keep a copy of the data somewhere in case the user forgot his password, so that backup is not encrypted (because you could also lose your password)
That's the point; you will always have to store something related to the password somewhere. The question is not "can I do this without storing anything" but "can I store it in such a way that at hacker can either not get at it, or can't do anything with it. (ie: salt the stuff)
October 11th, 2013, 06:07 AM
How is it home made? I'm using going standard encryption libraries (like the ones you suggest) to encrypt user data
Originally Posted by Jacques1
I'm not inventing my own security protocol
Originally Posted by Jacques1
Please do - that was the point of my post
Originally Posted by Jacques1
How is this not password based using your suggest library?
Originally Posted by Jacques1
[This is no average website I'm building]
And sometimes it's how we get breakthroughs, paradigm shifts and a better way of life
Originally Posted by Jacques1
October 11th, 2013, 07:20 AM
Very true. Sadly, not everyone can appreciate the effort and feel they have to put you down. Personally I think it's good that you are trying to learn, rather than accept what others are saying. The worst that can happen is that you find holes in your ideas and you are forced to fall back on the classic methods, in which case you at least now know why those methods are being used.
Just don't deploy any of your ideas until you are absolutely sure that they are as safe as the common solutions.
Comments on this post
October 11th, 2013, 07:46 AM
Originally Posted by Vinny42
I consider myself an expert in what I do. At present I'm the only developer where I am, so I've no one sitting next to me to bounce new ideas off, so I come to forums like this for other experts to comment on.
In this case I feel that I either haven't expressed my concept fully enough or that my post hasn't been read thoroughly.
I spent 4 years at university studying physics and maths, where I was introduced to C and HTML. For my dissertation I used C to model thin metallic films deposited by particle systems and used it for number crunching the real results. After uni I used HTML and my knowledge of C to dive into PHP development, which I have been doing for nearly 10 years now. In my current position I am responsible for ~ 250 sites and apps. Some of which I built my myself, some by others and previous developers, some use open source apps, some closed and commercial and some are hybrids of all.
The point is I'm not new to this and I'm pretty intelligent. I observe that all these apps use a password to identify a user for the sake of a password...It doesn't actually unlock anything other than a boolean true/false. To me this is the weakest link in the authentication process. I think the link can be made stronger by not keeping the password in any form on the server - Think about a real lock. I don't show the lock a key and the lock doesn't say that key looks like the one I already have....no. The key fits in the lock and together a mechanical process happens to change the state of something tangible....the bolt moves and the door can be opened...my thoughts are to model this process as part of the authentication process. The "I am this user" presents an appropriate locked safe, the password is the key to change the position of the bolt in the door.
The only downfall is the real life equivalent - loosing the key. The lock won't cut me a new one, so why should an app? Maybe I should request a new safe from the administrator.
So, what's in the safe? Its a list that says "contacts=>yes, products=>no,invoices=>yes" etc. Ie things that an administrator could grant...new safe, new list, new key
October 11th, 2013, 08:18 AM
But what is the point of encrypting the ACL if it's still only a password that unlocks it?
Or: what's the difference between verifying a password through a hash and then loading the ACL, vs using a password to decrypt a string which then turns out to be the ACL?
In both cases you have some routine to verify that the password is correct (check the hash vs check the validity of the ACL)
A hacker won't /can't attack by trying to trick the software into loading someone else's ACL, he'll just trey to get your password.
So the next question is: what happens when a hacker get's his hands on the hash or the encrypted ACL? Neither will work against a rainbow table so it's probably only the length of the ACL that makes it slightly harder to brute-force.
new safe, new list, new key, one p*ssed off administrator who whishes he could just reset the flipping password without having to completely reconfigure the account :-)
Which brings us to your solution of having a backup, non-encrypted copy of the ACL, that would void the whole idea of using ancrypted ACL's :-)
October 11th, 2013, 01:39 PM
October 11th, 2013, 02:07 PM
With the emphasis on "no matter where". If the application can acess the key, and the attacker can access the application, what's stopping him from getting the key from dedicted hardware?
but, in this particular case the key would be supplied by the user at login, used to decode the ACL and then forgotten about completely, which is probably actually safer than storing it somewhere. But, the same is true for regular password authentication.
October 11th, 2013, 02:48 PM
Since somebody got offended by my last post, I'll try to be very gentle this time.
Your safe example is actually very good, because it demonstrates the whole problem: The lock of your safe tells me exactly what the key looks like.
This is inevitable. The only way you can verify a password is by knowing something about it. You don't need to know the actual password. But you need some kind of derivative. And this derivative can be used by attackers as well.
All you've done is change the derivative. Instead of running the password through a hash algorithm and comparing the result with a given hash, you now run the password through an encryption algorithm and check if the result is valid PHP code. The encrypted ACL basically is your hash.
This means you didn't achieve your proclaimed goal (not storing any password-related data) at all. In the meantime, you completely missed the actual goal: slowing down the attacker.
Let's assume you actually used the user password as the encryption key (after padding it). Then an attacker would brute-force a password by decrypting an encrypted ACL with different strings until they get valid PHP code. How hard this is depends on the speed of the algorithm: The faster the algorithm, the more passwords the attacker can try per second. Unfortunately for you, all common encryption algorithms are very fast. According to this benchmark, for example, AES is roughly as fast as SHA-2. This means finding the right password for an encrypted ACL is as hard (or easy) as finding the right password for a given SHA-2 hash. Since you didn't mention the initialization vector, you don't even have a salt-equivalent.
In other words: If your algorithm works perfectly, you've just invented an overly complicated equivalent of
But since your algorithm has a backdoor (the second key) and is completely unverified, it's actually much less secure than good old SHA-2.
sha256($password) == $hash
Do you now understand why I said this is a battle you cannot win? None of us can. I think you're a great developer, but you're not a professional cryptographer.
Long story short: Do what you're excellent at (programming), leave the rest to others. Don't roll your own.
Don't get me wrong: It's fun to play with crytography, and thought experiments can be very fruitful. But don't even consider using some new authentication scheme on a live server -- unless your name happens to be Bruce Schneier.
I find it kinda sad that "classical" hashes are often belittled nowadays. Choose a good password (or even generate a random one with KeePass or something), hash it with bcrypt, and it will be the most secure part of the whole application. For even more security, there is TLS public-key authentication. This comes pretty close to your original goal of not storing any password-related data on the server. With pubic-key authentication, the private key never leaves the client. It's not even transmitted for verification.
I wrote a text about different authentication methods.
Last edited by Jacques1; October 11th, 2013 at 06:23 PM.
October 11th, 2013, 03:50 PM
And you succeeded. Thanks for the followup :-)