As my webserver doesn't allow use of the PHP_AUTH_USER and PHP_AUTH_PW keywords because of CGI (Col. Shrapnel in 'PHP_AUTH_USER not set?') I'm examining some other ways to send a user's password to the server.
Sending the password as plaintext using POST is a no go: capturing packets and looking at the header reveals the password.
So I could hash the password first. But someone intercepting the packet and copying the hash and username could still login using this information, right?
Making the hash dynamic by using a timestamp could prevent copying the hash. Sending the password as (timestamp + hash(password+timestamp)) (Last.FM uses something like this). The server could then subtract the timestamp (check if it's not expired or something), and hash the known password with it and check if they are the same. But then the password has to be known by the server, so the question remains:
how to get this password safely to the server upon registering?
Then, there's https, requiring a SSL certificate, which is not available for me (not worth the money (yet?)).
Any thoughts?
p.s. In the end I want to authenticate an Android app against my webserver
Where I've needed that level of security for data sent to the server I've used a similar system, hashing the data with a fixed-length client-derived key, appending, prepending or interleaving that key and converting the resulting string to hex. In theory the string could be decoded if intercepted, but realistically you'd need at least some idea of the schema used to derive the key.
If security really is so important to you, I'd really go for something like HTTPS. If it's not available to you, maybe switch webhost or whatever is your limitation? If money is the problem, there were some suggestions in the question comments (free ones, self-signed, etc).
This hashing with timestamp and such is pretty much only going to end up as security through obscurity (related question).
I'm not a security expert though. All I know is that security is very very hard, and the ones who want to break in are usually smarter than me. So I try to keep things simple and use common well-tested solutions instead of trying to come up with my own "clever" thing.
Related
I am currently working on a better login-routine for one of my websites and I wanted to adress securely transmitting login-Data to the server. There are several articles and posts concerning this topic, but they frequently have quite different opinions on how it has to be done.
Starting off with SSL, pretty everyone is on the same page here: You should use SSL, and I do. Then there are those who say: "That is enough, with SSL you can send username & PW as plaintext". I disagree. Other say that it should still be hashed. And I read several posts where I had the feeling that people were concerned about different aspects of a login routine and proposed mechanisms to only handle their security aspect.
So what I want to know, if the routine I have so far elaborated would be adequate, too much or too little. I will try to explain why I chose to implement a certain feature and which security aspect I try to cover:
SSL:
The communication between server and client should always be https:// - nevertheless I read several articles warning that SSL is "no silver bullet", but it is a good start.
Hash PW clientside (SHA3, ARGON2i, BCRYPT):
Many comments did reject hasing PW. Using a hash, comparing it to a HASHed PW in the database would simply change the PW from the userinput to the HASH - an attacker would still have access by simply getting hands on the HASH. I agree. BUT (this is what I meant that people read about different aspects of security) the ones claiming that it is better than sending plaintext because in that case ONLY your system, but not other systems with the same PW would be compromised (unless, of course they use also hashed PWs). So I would implement HASHing of the password before sending it via SSL.
encrypting the HASH:
Let's assume SSL could not hide the data we send to the server and an attacker would read the HASHed PW. The only way that I could think of to adjust the security to this scenario, would be to encrypt (e.g. AES CBC) the client-side HASHed PW with a key that has been send beforehand by the server, and that has a short expiration period. The key would have to be generated randomly. Like that, the server can decrypt the data, and then compare the HASH with the one it its database.
To sum it up:
-> Clients wants to Login via SSL -> Server sends back a key -> Clientside hashing of the PW -> clientside encryption of teh HASH with the key and a random IV -> Server decrypts the data with the key (stored in $_SESSION, with an expiration timestamp) and compares the HASH with the HASH in his DB (if the expiration timestamp is still valid).
Would this be a good approach? Or is this too much? (Can there be too much security?) Or do you have any alternative solutions?
Or is this too much? (Can there be too much security?)
You're talking about it like security is a liquid that must fill-up a container without overflowing it. That's not how it works and you're asking the wrong questions, which means you're trying to solve the wrong problem. It has nothing to do with the amount of measures that you pile up, but whether and how they address a specific problem.
If the problem is protecting data in transit, then the solution is TLS (SSL) - that's what it is specifically designed for, and anything that you can come up with would, in the very best case scenario, be a poor alternative to it. You can't outsmart the decades of research and practice that has gone into TLS.
That was already answered by Jay Blanchard though ... I want to point out the mistakes you've made, because otherwise it looks like one man's word vs. another (and you may listen, but other readers might not):
SSL:
The communication between server and client should always be https:// - nevertheless I read several articles warning that SSL is "no silver bullet", but it is a good start.
It is both a silver bullet and not a silver bullet, depending on how you look at it.
When we talk about protecting data in transit, it is THE solution - a silver bullet in a way.
But that doesn't mean flaws won't be found in time, or that you just switch it On and say "I have TLS, I am secure!" - no, it still requires proper configuration, maintenance and adjustments over time. In that sense, it's not a silver bullet.
It also doesn't solve many other security issues, so when someone asks "How do I make my application secure?", of course you would say that it is not a silver bullet - many threats need to be separately addressed and there's no one-stop shop for them all.
Hash PW clientside (SHA3, ARGON2i, BCRYPT):
Many comments did reject hasing PW. Using a hash, comparing it to a HASHed PW in the database would simply change the PW from the userinput to the HASH - an attacker would still have access by simply getting hands on the HASH. I agree. BUT (this is what I meant that people read about different aspects of security) the ones claiming that it is better than sending plaintext because in that case ONLY your system, but not other systems with the same PW would be compromised (unless, of course they use also hashed PWs). So I would implement HASHing of the password before sending it via SSL.
It's the exact opposite - when you hash the password on the client side, that only makes accounts on your site easier to compromise after a data breach.
Lookup the hash in the database - got the password right there, that's the part you figured out. But that hash is still the result of a certain user-provided string ... Nothing stops an attacker from applying the same techniques to break the hash in order to compromise accounts on other servers.
So, this doesn't in any way solve the problem, but you'll probably think that in the worst case it doesn't do anything bad ... Well, indirectly it does - you have to make a considerable effort, to implement something with a lot of potential for mistakes.
In the best case scenario, you're just wasting your time, but a minor mistake can be a major vulnerability.
Also, SHA-3 is a cryptographic primitive - it has many appliances, but mostly as a building block. You can't just put one round of it on a password and be happy with the resulting hash.
For a comparison, bcrypt uses Blowfish internally (as a primitive of the same kind as SHA-3), but you cannot equate Blowfish to bcrypt.
encrypting the HASH:
Let's assume SSL could not hide the data we send to the server and an attacker would read the HASHed PW. The only way that I could think of to adjust the security to this scenario, would be to encrypt (e.g. AES CBC) the client-side HASHed PW with a key that has been send beforehand by the server, and that has a short expiration period. The key would have to be generated randomly. Like that, the server can decrypt the data, and then compare the HASH with the one it its database.
There are valid reasons to encrypt password hashes, but not for this purpose and certainly not on the client side.
You need a secure key-exchange protocol for this to even work. And guess how you do that? TLS.
There's literally nothing different between communicating an encryption key or a password over the wire. So, even if this was somehow a solution to protecting a password, how would you apply it again on the key itself? It makes no sense.
SSL is just fine, I have no idea why you disagree. Client-side hashing still leaves the PW visible on the client-side as well as the hash, so nothing gained there.
The question comes down to, "what are you protecting?" My guess is that you're not guarding anything needing more security than banks, and probably way less than that.
You're spending a lot of time trying to re-invent the wheel here, rather than relying on tried and true methods. Stick with what is proven.
-> Clients wants to Login via SSL -> Server sends back a key -> Clientside hashing of the PW -> clientside encryption of teh HASH with the key and a random IV -> Server decrypts the data with the key (stored in $_SESSION, with an expiration timestamp) and compares the HASH with the HASH in his DB (if the expiration timestamp is still valid).
Why encrypt a hash? That implies that the hash isn't secure enough. OK, fine, let's go with that. So let's assume an attacker is able to read the hash, and that's the reason you want to protect it with an additional layer. If an attacker is in a position to read the hash, they're also in a position to read the key sent by the server to the client, and the Javascript which contains the encryption algorithm (assuming you're talking about an HTML scenario here). Now the attacker has everything to replicate and reverse the encryption, and in fact they are probably also in a position to alter the Javascript sent from the server to the client in the first place.
To protect against that happening, you'd need some wrapper that protects all the communication between the client and the server, like, oh, uhm, say… SSL.
Since SSL already protects the communication from 3rd party interference… what do you think you're adding with that additional song and dance exactly? I'll tell you: nothing.
This might be an irrelevant question , but I'm wondering whether this can happen..
In HTTPS cookie data like phpssid transfers as an encrypted big random number.
What if someone sniffs that encrypted random number and send it to the server as it is? So the server decrypt that id and allows the hacker to log in as someone else. Is this possible?
Yes, exactly. Cookie data if discovered by a third party may be replayed to replicate functionality. Note that you say someone 'sniffs' the cookie over HTTPS, which, if everything is working as it should, would not happen. If you are asking if the encrypted values of SSL/TLS can be replayed to the same effect, no that cannot happen. The plaintext value is needed for this to work.
The encryption key used during a connection (such as HTTPS) will not be the same for a different connection. The actual key used for the connection is generated randomly on the client and encrypted using the server's public key (found in the certificate). There are multiple sites that describe this but here's one I found that explains it really well.
Note that sniffing the connection would not allow a third party to distinguish which part starts where in the data flow unless it knows the common key.
It is not entirely impossible to hack, considering that the NSA does this all day long, but it requires huge processing power for quite limited results.
What if someone sniffs that encrypted random number and send it to the server as it is?
It won't work. Modern TLS is designed to resist replay attacks at multiple levels:
Each client uses an ephemeral key.
The sequence number is used in the nonce for AEAD modes.
I am producing a script that others will put in their websites. It is designed for people with limited knowledge of PHP so that all they have to do is include() the script and set a few configuration variables. This means headers will probably have been sent already and so using sessions may not work. I recommend they call session_start in their own scripts, but I want a fallback option as well.
I already have a hidden input to deal with forms, but I also need links to have a query string appended to their URIs to identify the session. But if the hash is based only on the password+salt then there is a security risk: the logged-in user could click an external link and the owner of the external site could see the URI with the hash in their referrer logs. All they'd have to do is used that hash and they'd be logged in.
Therefore I want to salt the hash in a time-sensitive manner, limiting a session to 10 minutes. I can't figure out how to do this. Of course I can use time() to salt it, but how do I check how old the session is based only on the hash?
Expiring sessions after 10 minutes does not protect your users against session hijacking attacks. It only succeeds in annoying your users by forcing a login every 10 minutes. Your proposed scheme still has all kinds of vulnerabilities. Your salted hashed passwords can still leak to the outside world through many other channels; packet sniffing, intermediate proxies, users' emailing each other links to pages or even the saved html, just to name a few. I advise you not to homegrow you're own security framework without being an expert in the area. Even then, this is a solved problem. Just go with a known trusted solution. There are many subtleties in web security that are easy to mess up.
This sounds like a real bad idea. And complicated too. I would definitely not recommend it. You probably can use something like this:
if (session_id() == "") session_start();
The above will basically check if session has been started or not, and otherwise start session.
Since you planning to distribute to users, the whole approach seems a bit off to me. Am not sure what you are looking to achieve out of this, but you could try using a JS which calls your PHP file per page instead. This will make it easier for you. If you could elaborate on what kind of application you are developing, then I could probably help you out better. I have a lot of experience in mass consumer software apps similar to what you are doing.
This is not necessarily a bad idea, but it is dangerous if not done correctly. In fact, it is a fairly common implementation of multi-domain single sign-on using Hash-based Message Authentication Codes. Some ground rules:
Never ever include the password as part of the hash (even as the salt)
Require a timestamp generation as part of the hash that must be passed ALONG with the hash.
Each site to use this hash should have their own 32 or 64 byte guid to be used as a unique salt.
Pass specific data in the query string such as username, timestamp, anything else, and the HMAC. So it would look something like ?user=steve×tamp=66343532233&otherdata=otherdata&HMAC=AB3445-1234144-AFBBDEDD (you get the idea)
When site authentication is made cross-site, the HTTP_REFERER should be used (if possible) to get the key to generate the comparing HMAC.
Use a solid hashing algorithm (SHA1 is preferred) for generating the HMAC. Generate the the private site keys as randomly as possible. Do not use a standard derivation method, simply make sure that the end result is large enough/unique enough.
I'm trying to make a "normal" username/password login form secure, without needing HTTPS. My idea is this:
Server generates a keypair for some kind of assymetric encryption algorithm. It stores this keypair in a temporary table of sorts (or perhaps the local session data).
Server sends the form to the client and includes the public key.
User fills in the form.
Before it's sent to the server, Javascript encrypts the password using the given public key.
Form is sent.
Server decrypts the password with it's private key (which it gets from the temporary table, using the public key to find it).
What I need to know for this is:
Which encryption method is the best to use? RSA?
How can I decrypt the password in PHP?
And probably the most difficult one, how can I make Javascript encrypt the password?
In advance: I'm sorry for being negative, however;
Implementing your own security protocol is never a good idea, unless you're a highly trained security expert, or you actually don't really care about the security and only want to create an impression of security (marketing) and stop the script kiddies.
SSL is definitely not a fingerprint lock, as so say in your comments, JCryption and your proposal are equal to having a door where you can enter a two-digit code to open the door and you have infinite many retries. It's hard to break if you're not really interested and just passing by, but if you want to get in that house (and you probably do, else security wouldn't be needed), you will get in.
Another point is that people often forget to mention what they want to achieve. Security has the famous three components called CIA, namely confidentiality, integrity and availability. Is it for you important that the data you transport is confidential, or is integrity important (i.e. you're sure that the sent data comes from the one you expect and not the man in the middle)?
To make it concrete in this case, the only thing that you achieve here is that a passive attacker cannot see whats passing by on the line. As soon as your attacker gets active and changes the messages on their route, your whole security falls apart. So my advice would be to just stick with the solution the experts have come up with (TLS in this case, not ssl since that is the old version of it) and just make sure your server supports it.
edit:
Btw, SSL/TLS cannot work without certificates. The whole point in public key crypto is that there should be at least somewhere some trusted party.
On the other hand, if you don't care that your users will get an "invalid certificate" message, you can just create your own certificate which is really easy. In that case your certificate isn't trusted by the browsers, however, you can be sure that at least your communication is safe (okay, there are exceptions in this case, but still ...)
The argument that certificates should be for free is really from a perspective point of view. I think people who claim it is bogus/idiotic don't know what it takes to be a certification authority. These companies invest millions in order to keep the communication secure, and sure they make nice money out of selling certificates, but hey its their job and they also deserve to make money, just like any others.
edit2: after comments
I indeed say that you have a secure communication. However, you miss the point that with self signed certificates you dont know to whom you talk securely. Imagine a dark room which is completely isolated from eavesdropping a conversation. Now imagine the difference between such a room with and without light. If the room has light, you can actually see to whom you're talking securely and only choose to talk to people you like to trust. Now imagine doing the same in a completely dark room. You can only hope that the guy you talk to inside this dark room is just an ally and not your adversary. However, you cannot know that, just hope that it's ok. And although your conversation itself is secure, nobody can listen in, you still dont have "full" security.
If I, being a crook, do a man-in-the-middle attack, I can create a self signed certificate without the user noticing. So the advantage of using TLS with self signed certificates is that you have at least the implementation of the protocol corrent (and even implementing this is far from easy). Moreover you can avoid the ugly warnings by advising your users to manually trust the certificate once. However, this is only possible if you have a relatively small group of returning visitors, for a public website this is not really a solution.
This doesn't seem that secure from the perspective of the client. Two (related) problems:
How does the client trust the server? How can it verify that the key the sever's presenting is the one that belongs to it?
It's possible to do man-in-the-middle attacks. A malicious proxy could strip out and store the public key before the client sees it, substituting its own, then decrypt the password when the client authenticates, store it, and re-encrypt and send the response on so the client doesn't realise something's up.
What's wrong with ordinary SSL? There has to be a consensus that it's secure, otherwise vendors and organisations would drop support for it overnight. By contrast, most attempts to invent a funky new way to do security "on the cheap" usually miss something fundamental.
It looks like a lot of what you want to do is supplied by the jquery plugin JCryption. It even assumes PHP as the backend, so a good fit for you.
Livejournal does something similar to what you want where:
Server generates a challenge string, inserts this into form. [1]
Client generates response by MD5 hashing the password, then MD5 hashing the previous hash with the challenge prepended [2].
Server gets response, checks challenge validity, then does same as step 2, comparing the result to the response.
This is a very good idea, and it's already been done. See jCryption.
jCryption looks interesting, I've not seen it before.
But I have to ask what is wrong with SSL?
Encryption code is notoriously hard to do right, and you can bet that the SSL implementations found in browsers and http servers are much more rigorously tested and reviewed than the jCryption stuff.
That said, jCryption looks neat if you absolutely need to avoid SSL, and you're not dealing with super-sensitive information.
By storing the passwords in encrypted method on the server the server can retrieve the passwords and verify checksum sent by client. Send a session password and ask client to make a hash of session password and the user inputted password, do the same on the server and compare the two hashes.
This will not secure users from MITM attacks - local admins, NSA, telecom, router hijacks, but it will keep the password safe in open wlan.
How do I write/put together a secure login in PHP? The website developer guide said I shouldn't roll my own, so referring to samples available via Google is useless.
How do you pros do it? Lets say you're building a world-class app in rails, would the same libraries / techniques be usable here?
Thanks
In Rails, one would generally use a pre-existing library. Authentication is easy to do wrong, and the problem's been solved so many times that it's rarely worth the effort to solve it again. If you are interested in writing your own implementation, then I'll describe how modern authentication works.
The naive method of authenticating a user is to store their password in a database and compare it to the password the user submits. This is simple but unbelievably insecure. Anyone who can read your database can view anyone's password. Even if you put in database access controls, you (and your users) are vulnerable to anyone who hacks around them.
Proper form is to use a cryptographic hash function to process the password when it is chosen and then every time it is submitted. A good hash function is practically irreversible -- you can't take a hash and turn it back into a password. So when the user logs in, you take the submitted password, hash it, and compare it to the hash in the database. This way, you never store the password itself. On the downside, if the user forgets their password, you have to reset it rather than send it to them.
Even this, however, is vulnerable to certain attacks. If an attacker gets hold of your password hashes, and knows how you hash your passwords, then he can make a dictionary attack: he simply takes every word in the dictionary and hashes that word, keeping it with the original. This data structure is called a rainbow table. Then, if any of the dictionary word hashes match a password hash, the attacker can conclude that the password is the dictionary word that hashes to that password. In short, an attacker who can read your database can still log in to accounts with weak passwords.
The solution is that before a password is hashed, it is combined (usually concatenated or xor'd) with a value called the salt which is unique to each user. It may be randomly generated, or it may be an account creation timestamp or some such. Then, an attacker cannot use a rainbow table because every password is essentially hashed slightly differently; he would have to create a separate rainbow table for every single distinct salt (practically for each account), which would be prohibitively computationally expensive.
I will echo the advice of the other answerers: this is not simple stuff, and you don't need to do it because it's been done before, and if you do it yourself you stand a very good chance of making a mistake and inadvertently compromising your system's security. But if, for whatever reason, you really, really want to write one yourself, I hope that I have provided an (incomplete!) outline of how it's done.
The Zend Framework has an 'Auth' module which would be a good place to start. Or, if your site will be hosting an install of WordPress or PHPBB, there are ways of leveraging those technologies' authentication modules to sign in to other pages of a site.
One thing to look at when you are trying to authenticate is what is your real goal.
For example, on SO I use my google login, and that works, as they just need to know who I am, and they can trust that Google has an idea. So, if that model will work for you, then look at using OpenID, as there are various tools for that.
If you must do your own, then there will be various tests to ensure that it is secure, again, depending on how paranoid you want to be.
Never trust anything from the user, unless you have used some strict verification.
Use https to help protect the password of the user, you owe them that much.
I will end my response here as Thom did a fantastic response.
by Soulmerge:
I think the accepted answer in your other question states it pretty well. Hash the passwords with a salt. Other than that, there are some security ideas on the transport layer:
Use https when sending passwords. This makes sure nobody can catch them on the wire (man-in-the-middle attack or the client uses an evil proxy)
An alternative is to hash the password using javascript when the login form is submitted. This makes sure that the password is never transported in plaintext. You should hash the hashed value again with a salt on the server. (md5($_POST['postedPwHash'] . $salt))
a good method to somewhat secure the client-server transaction (if no ssl is available) is to use a one-time random key to create a unique hash from the credentials, then only send that unique hash to the server. the server then compares this hash to its own generated hash instead of comparing it to the real credentials. this would provide a good defense against the man-in-the-middle attack. the downside is that to do this the user must have JS enabled (at least i dont know of a good method to encrypt client-side data without it). this means that you will need a sufficient fallback when it isn't on. you can even create the form in JS to make sure its enabled.
this library is a simple library i wrote once that does the procedure i described, though it probably needs some improvements.
note that this is in addition to using "salting" methods and other server-side security measures. it is also quite vulnerable to dictionary attacks as the entire hashing process is by definition procedural, predictable and visible to the user (as JS always is).
My answer is "Don't do it"
This is a very complex area, full of potential security gotcha's. If you are not an expert in this field, then you are really just asking for trouble and problems down the road.
I would recommend looking at getting an existing solution to do. Sadly I don't know any that I would be happy to recommend, other than openid. I'm sure you will get some good suggestions here though...