I'm working on an application for iOS which will have the user fill out their password. The password will then be posted to a PHP page on my site using either POST or GET. (It must be plaintext because it is used in a script.)
Besides HTTPS, is there any way to secure the password? Encrypt it in Obj-C and then decrypt it in PHP?
NOTE: The username is not sent... only the password is posted to the server.
EDIT:
To clarify, David Stratton is correct... I'm trying to prevent malicious sniffers in public locations from simply reading clear text passwords as they are posted to the server.
Challenge response outline
Lets assume you have one-way hash function abc (in practice use md5 or sha1 a cryptographically strong hashing algorithm for PHP see: password_hash).
The password you store in your database is abc(password + salt) (store the salt separately)
The server generates a random challenge challenge and sends it to the client (with the salt) and calculates the expected response: abc(challenge + abc(password + salt))
The client then calculates: abc(user_password + salt) and applies the challenge to get abc(challenge + abc(user_password + salt)), that is sent to the server and the server can easily verify validity.
This is secure because:
The password is never sent in plaintext, or stored in plaintext
The hash value that is sent changes every time (mitigates replay attack)
There are some issues:
How do you know what salt to send? Well, I've never really found a solution for this, but using a deterministic algorithm to turn a username into a salt solves this problem. If the algorithm isn't deterministic an attacker could potentially figure out which username exists and which do not. This does require you to have a username though. Alternatively you could just have a static salt, but I don't know enough about cryptography to assess the quality of that implementation.
Reconsider not using HTTPS. HTTPS a good defense against a number of attacks.
There usually isn't a reason to transmit a password. By transmitting passwords, you are sending valuable data and their is extra risk associated with it.
Usually you hash the password and submit the hash. On the server side, you compare the hashes, if they match, great.
Obviously with this approach, the hash is important, and you have to secure against a replay attack. You could have your server generate a crypto-secure one-time use salt, pass that to the client, salt and hash the password, and compare the hashes serverside.
You also need to guard against a reverse hash attack on password. IE, I have a hash, and I can compare it to a bunch of pre-generated hashes to find the original password.
You could encrypt at the device and decrypt at the server, but if the data going across the wire is sensitive enough to warrant that much work, then IMHO, I believe you're better off just using https. It's tried, true, and established.
It's not perfect, mind you, and there have been successful attacks against older versions of it, but it is a heck of a lot better than "rolling your own" method of security.
Say your key gets compromized, for example: If you're using https with a cert from a trusted authority, then you just buy a new cert. HTe deveice, if it trusts the authority, will accept the new certificate. If you go your own route on it, then you have to update the keys not only on your web server, but at the client as well. No way would I want that sort of headache.
I'm not saying that the challenge is insurmountable. I am saying it may not be worth the effort when tools already exist.
Related
I am working on a website to learn more about web programming and also to launch same as a start-up. The first problem that i came across was how to implement a secure login system. Currently i have take steps like escaping the password and then hashing it, using a salt. But i was wondering is the following mechanism secure,
I will make the user enter username and will keep checking if the user has entered his username (when textbox loses focus or a button for submitting username, also to prevent listing of usernames ill block the user by setting cookie on system if multiple incorrect attempts are made, or maybe ill use captcha for each ), once entered username, ill send back random stored salt to user.
Using that salt and password entered, user will hash the password and send it in form
I'll verify the password by comparing hashes
I think it will be beneficial since server side i don't have to do any processing, and hence i don't have to worry about DoS attack, as i read somewhere that using some slow hashing like BCrypt will expose site to DoS attacks.
Also user's password is never communicated over the network, making it secure from person sniffing the network.
Please do point me to some reference or anything that may help me to implement securely. Consider me noob because i have still started learning, and would like to know what you think of it, what possible flaws are there ? and what must be secure strategy.
UPDATE-
Many answers i am getting, all usually assume that i am thinking this as an alternative to SSL; no it's not the case. By protection against sniffing i meant protection just in case some attacker might make the user use a SSL proxy.
just for reference - https://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request
Client side hashing can have its advantages, but you cannot do without server side hashing. In your scenario, the calculated hash acts as the new password. An attacker with read access to the database (SQL-injection) will see this hash and can use it directly as password to login.
Using a slow hash with a cost factor is mandatory, usually it is done server-side, because client-side languages are slower and can do less rounds. Of course somebody can use it to make a DoS attack, but this can be done with every other page as well. The size of the password doesn't matter (as one can read ocassionally), because after the first round only the hash will be hashed.
If you plan to do a client-side hashing, don't forget to calculate a (fast) hash on the server as well. And you have to ensure, that the hashing was done correctly client-side. Much more important is, that you use SSL to send the credentials.
The question Secure authentication: partial client-side key stretching… could be of interest to you.
EDIT:
I will try to sum up the important points for client-side hashing.
A slow hashing algorithm with a salt and a cost factor (BCrypt/PBKDF2/SCrypt) is mandataory, this is the only thing that makes it hard to retrieve the original password from a hash, if the password is weak. It is possible to do this client-side.
Server-side hashing is mandatory too, to prevent an attacker from using stored hashes directly as passwords, if he knows them. The hash can be fast without a salt (SHA-256), because the input (BCrypt hash) has enough entropy. Such a strong "password" with 60 characters cannot be successfully brute-forced.
If the attacker cannot crack the fast SHA-256 hash because the input is too strong, he can try to brute-force with the original passwords (from a dictionary). But to do this he would first have to calculate the slow BCrypt hash and afterwards the fast SHA-256 hash.
Client-side languages like JavaScript are usually interpreted and much slower than compiled code, so you can do less rounds in the same time as you could do on the server (this weakens security). If you have the possibility to run native code on the client, there is no disadvantage to do the slow hash client side.
no, you should not send any 'salt' to the user.
It can be sniffed.
What you're basically doing is a send something like a (csrf-)token that can be used once. Nothing wrong with that, but you seem to be re-inventing the wheel.
Seriously, I think your solution is good only for hackers. If I sniff communication I will get gradually username, salt and password hash. You have to send all those values over the network (username to get salt, password hash to auth attempt). Now I can use sniffed password hash directly in malicious login request or start cracking password locally (users usually have same password for more services). All checks and limits on auth attempts are out of game because I don't need send request to guess password. Depends on hash algorithm it will more or less time consumption. I think network sniffing is the main purpose why you calculate with not sending plain password over the network.
You can secure your network communication with TLS but then all things with sending salt and hashing password on client are unneccessary. You can just send password in plain text to server. But yes, hashing password on client, why not if you want. You can use ie. sha1 also on server if you think that bcrypt is performance issue and possibly DOS cause.
Good example of protocol that is used for transmitting infomation through unsecure network is OAuth 1.0a and even in it you need some cryptography or TLS for transfering consumer secret.
Let me know if I am something understood incorrectly.
I guess only drawback i can see is using this on low-end mobile devices.
I have read in many articles that we should combine an unique salt to each passwords before hashing and store the salt in database for verification but How about using the password itself as an salt ?
Doing this will benefit as the salt will be unique for each as well as it will be hidden as it will be stored no where.
An simple example I can give for above is:
$hashToStore=sha1(strrev($password).$password);
Above I am just reversing the password and using it as an salt (I will be doing something more complex then just reversing it in development.)
Is This an better way for storing passwords or will be a bad practice.
PS:I am completely aware of php latest inbuilt functions such as crypt() and use it in real world, but yet wanted an review for above.
A common mistake is to use the same salt in each hash. Either the salt is hard-coded into the program, or is generated randomly once. This is ineffective because if two users have the same password, they'll still have the same hash. An attacker can still use a reverse lookup table attack to run a dictionary attack on every hash at the same time. They just have to apply the salt to each password guess before they hash it. If the salt is hard-coded into a popular product, lookup tables and rainbow tables can be built for that salt, to make it easier to crack hashes generated by the product.
A new random salt must be generated each time a user creates an account or changes their password.
[…] It's easy to get carried away and try to combine different hash functions, hoping that the result will be more secure. In practice, though, there is very little benefit to doing it. All it does is create interoperability problems, and can sometimes even make the hashes less secure. Never try to invent your own crypto, always use a standard that has been designed by experts. Some will argue that using multiple hash functions makes the process of computing the hash slower, so cracking is slower, but there's a better way to make the cracking process slower as we'll see later.
Here are some examples of poor wacky hash functions I've seen suggested in forums on the internet.
md5(sha1(password))
md5(md5(salt) + md5(password))
sha1(sha1(password))
sha1(str_rot13(password + salt))
md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))
Do not use any of these.
Salt should be generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). CSPRNGs are very different than ordinary pseudo-random number generators, like the "C" language's rand() function. As the name suggests, CSPRNGs are designed to be cryptographically secure, meaning they provide a high level of randomness and are completely unpredictable. We don't want our salts to be predictable, so we must use a CSPRNG. The following table lists some CSPRNGs that exist for some popular programming platforms. (PHP: mcrypt_create_iv, openssl_random_pseudo_bytes)
The salt needs to be unique per-user per-password. Every time a user creates an account or changes their password, the password should be hashed using a new random salt. Never reuse a salt. The salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your salt is at least as long as the hash function's output. The salt should be stored in the user account table alongside the hash.
To Store a Password
Generate a long random salt using a CSPRNG.
Prepend the salt to the password and hash it with a standard cryptographic hash function such as SHA256.
Save both the salt and the hash in the user's database record.
To Validate a Password
Retrieve the user's salt and hash from the database.
Prepend the salt to the given password and hash it using the same hash function.
Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.
At the bottom of this page, there are implementations of salted password hashing in PHP, C#, Java, and Ruby.
In a Web Application, always hash on the server
If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?
Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.
The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.
This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:
Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.
Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.
You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.
source: https://crackstation.net/hashing-security.htm
So, to answer your question, bad idea, very bad idea.
Please, don't ever do this. The whole point of salting is that every persons password hash will be unique which removed the issues of rainbow tables and giving away who has the same password.
Why does that matter? Look at the LinkedIn hack where they had "password hints". People has hints like "rhymes with assword" which gave away what their password, and also their hash was. It also gave away EVERYONE ELSE who was using the same password.
I'm designing a REST API and I have some problems in terms of security for authenticating the user.
For authentication I don't want the password to be send across the network in plain text.
To bypass this problem I could send a SHA-256 hash of the password (with the username as salt), so the password is never sent in plain text. In my database I will be storing the following hashes: SHA256(password + salt) and I'll compare if both of the hashes match.
The problem with this option is that I'll have a hash computed with a fast hash algorithm and the salt is not random.
In security the best practice is to use a slow signature algorithm, with a random salt (like bcrypt).
The slow algorithm is not a problem, i could use bcrypt on the client side, but for the salt i don't know what to do:
Bcrypt need a salt with a defined size so i can't put the username
If i'm using a random salt, how the client will know the value of this salt before computing the password's hash?
So i can see 3 options, but none are sastisfying:
I send the password in plain text (I'm using SSL) and i store bcrypt in the db => still vulnerable to man in the middle
I use SHA256 and send the hash where the salt is the username (still using SSL) => the hash in the db are less secure
I use bcrypt and I have a two step process: i ask for the saltfor a given user and then send the hash of this user (still using ssl) => by trying to log in with an other username i can obtain his salt, not awesome
Is anybody has a better solution or some advices?
I think you might be conflating/confusing a few issues here:
If you're storing the hash(password + username) on the server, and authentication involves sending hash(password + username), you haven't really achieved anything better than just storing the password on the server. The goal of only storing hashes long-term is that if you have a data breach (i.e., an attacker gains access to the database) they still can't produce the correct value to authenticate. But if you're doing a simple comparison, this is still an issue.
The correct use of hashing+salting is: (1) Server stores tuples of (Salt, hash(Password + Salt); (2) User sends (claimed Password); (3) Server computes hash(claimed Password + Salt); (4) if hash(claimed Password + Salt) == hash(Password + Salt), then they're authentic. In this way, even if an attacker gets access to the database, they can't produce a claimed password that such that hash(claimed Password + Salt) is valid.
Sending a plaintext password via SSL is not "in the clear". Per #NullUserException's comment, unless the attacker has broken SSL. Only the server will be able to obtain the value of the password (assuming the server's public key is valid, which is a whole 'nother story).
Hope this helps!
There a couple of advantages to the approach of hashing on the client side. One of them is the server never gets the real passwords, so if the server is compromised in any way, it still won't get the real password. The other one is, it can lighten the load on the server side if you're planning to use slow hashing.
However, hashing passwords is designed to protect you in case the database is breached and hashes are stolen. This means if someone gets a hold of the hashed passwords, they could still impersonate users by sending the hash. The implication is, even if you hash on the client side, you still need to re-hash on the server.
The other potential downside is that this could alienate part of your userbase that doesn't have JavaScript enabled.
To address your points:
Bcrypt need a salt with a defined size so i can't put the username
Don't use the username as a salt. Salts should be unique, and a username (and derivations thereof) is certainly not unique. By unique I don't mean just unique to the server, but unique everywhere. Use a cryptographic nonce instead.
If i'm using a random salt, how the client will know the value of this salt before computing the password's hash?
Just have the server send the salt (nonce) beforehand. You could do this on the client as well, but the Javascript doesn't have a CSPRNG as far as I know, and you'd still need to send the nonce back to the server.
I send the password in plain text (I'm using SSL) and i store bcrypt in the db => still vulnerable to man in the middle
SSL was designed to prevent man in the middle attacks. Unless it's broken somehow, that's not going to be a problem.
I use SHA256 and send the hash where the salt is the username (still using SSL) => the hash in the db are less secure
Don't use username as a salt. And like I said before, you have to hash on the server side regardless of whether or not you did it on the client side.
I use bcrypt and I have a two step process: i ask for the salt for a given user and then send the hash of this user (still using ssl) => by trying to log in with an other username i can obtain his salt, not awesome
Not awesome indeed.
Make the salt constant, let's say make it a hash of the username. So hash_val = HASH(HASH('username') + 'password') is stored server-side.
For authentication your server sends a single-use random value, ie: nonce = HASH(RAND())
Your client computes the following based on the input credentials client_hash = HASH( nonce + HASH(HASH('username') + 'password')) and sends it back to the server.
The server perfoms the same operation, compares the resulting hashes, and discards the nonce.
In this way the hash sent over the wire is used only once and you're protected from 'replay' and MITM attacks.
Also, look into something like PBKDF for storing passwords rather than just hashes, it makes both bruteforcing and rainbow tables completely impractical. Here's the PHP implementation I'm using since it's not in PHP yet.
If possible create API Key and secret key (API username/password, obviously unique for each user) to use API. You should give an option in your site interface to activate/de-active the API access as well as option to re-generate the API Key and secret key. Here, on this interface users will see the API/Secret key of the API.
I am creating a program that communicates with a PHP script on a web server and to do so I need to be able to pass parameters from the program to the PHP script.
Now here is my question. At some point the user name and password needs to be passed to the script. Now this is not done in a way that is apparent to users (such as in an address bar) but I know with a little sniffing around someone that really wanted to could figure it out. So while my script is safe from injection, obviously variable tampering is an issue here.
This is an idea I have come up with so please help me wrap my head around it and see if this would work the way I THINK it will.
My thought was to encrypt the user password (or another unique key) variables on the client side before sending so you get a url like (obviously just made up) mypage.php?un=Oa348uty8&ps=op986hGTfreu Then when it gets to the PHP script decrypt it and encrypt it again with a different salt.
So when it leaves the application it would be encrypted but not the correct way, and then when it hits the PHP script server side decrypt it and re-encrypt it with the correct salt so it would correctly match the stored encrypted password.
This way, they user would not know what the encrypted version of their password is supposed to look like so without that they would not be able to tamper with the URL and try to insert fake values.
To put it in a nutshell, you are thinking of this:
On server side you have:
a database, with login/password matches.
a script that take 2 parameters (password and username) and check in the database if the couple exists
Your problem:
When your local application call the php script on server side, the 2 parameters are given in plain text. And you want to avoid tampering ( if your script are safe against injection i only see tampering used to bruteforce the auth <= keep in mind that i will keep this assumption in the whole post)
Your solution:
On client side, encrypt the 2 parameters
On server side, add a salt in your script to salt
Then decrypt the 2 parameters and encrypt with a salt
What I think:
This will not solve the tampering issue, someone can still forge requests.
The first encryption is useless because someone can retreive the key used by your client.
The second encryption is not safe enought because you use the same salt for all you users.
What I suggest:
Accept that tampering can't be avoided if you don't use a secure protocol like HTTPS (can either use SSL or TLS).
If you want an acceptable security without HTTPS the following is what i would implement:
A token system that you will check in order to see if the user can perform the login operation
A username that would not be encrypted
The password sha1 hashed stored in database
On client side, you call the script and provide the username as non encrypted and your password as a sha1 hash, rehashed with a random salt (sha1(sha1(pass)+salt) (the salt is stored in the user session on server side)
The script would then compared the provided hash with db password hash rehashed with session salt
The improvement is that the attacker must try to brute force two sha1 passwords consecutivaly and must provide a valid token to perform the login action. Plus if you use as salt a string using hex char of a variable even length, it will make the job harder for the attacker to recognised that the value bruteforced by the second hash is a sha1 hash, and even if he know it's an sha1 he will have to test multiple case to try to find the right portion of the value that correspond to the hash.
Because of variable salt, a same password won't be the same if hashed:
Imagine the attacker sniffed a hash and know which password was used then sniff another hash that was made with the same password as the other, the attacker won't be able to know that the 2 password where the same( a little overkill but still usefull).
It is safer to store the password as hashed value, because if the attacker manage to dump your user table, he won't be able to use the passwords right away, he would have to bruteforce each of then.
Finally sha1 hash are safer than md5 (i tell you that because you used the md5 tag in your post)
The downside of this method is that passwords can't be reversed, so you won't be able to given them back to your users if they lost it. You will have to make them set a new one.
An hardcore way (still without using HTTPS), would be to encrypt your password and username with a strong cypher (like AES or 3DES) and use a secure key echange algorythm (like the Diffie Hellman one) to exchange a random shared key.
This method won't block tampering, but will screw the attacker, because he won't be able to decrypt the value (assuming he only is sniffing the network). The key is random and never hardcoded in any of your application, so even if someone reverse your client, he won't be able to retreive a key.
I would still recommend to store your password value has hash.
An extreme way would be to merge the 2 methods but would be completly overkill.
Hope this will give you ideas
The problem with your approach isn't whether you are using encrpyted passwords and usernames in the URL or not. If the user authenticates by sending the encrpyted strings to you, then I as an attacker can still sniff out those hashes, pass them to your application and authenticate. This is unless then, that you do some public key/private key exchange before hand, but that is just reimplementing HTTPS, so you might as well just use HTTPS.
What you should do is to send the request using POST over HTTPS.
POST: So that the authentication details will not be in the URL and show up in logs and referrer URLs.
HTTPS so that the content of the whole request is fully encrypted and can only be decrypted by the client application and the server side.
encryption with Javascript from client to server only prevent from non SSL posting fails.
I think you must use sessions instead of this type encryption .
Update:
You could add your own secret key in both scripts.
I'm making a game and I can only request pages. eg.(login.php?username=myuser&password=mypass)
The game can recieve the results from a php too.
At the moment the password is encrypted. What's the best way of achieving a safe method of logging in?
thanks
Use SSL. That will encrypt the password over the wire.
Don't send the raw password, either. Hash it and send the hash.
That's still not going to give you great security because the hashed password will still be in the browser history and could be used for a replay attack. You can mitigate this by using a challenge-response mechanism. Get the server to include a large random sequence of bytes (a nonce) along with the login page, then the client can XOR the password hash with this nonce and send the result. The server can apply the same XOR to obtain the original hash.
SSL will prevent eavesdropping, sending the hash will make things a little harder for a casual attacker, and the nonce will prevent replay. That's probably not a complete list of things to look out for, but it's a start.