Very simple question. For registering and logging in through a RESTful API, should the passwords be encrypted before sending through Basic Authentication; or is Basic Authentication so secure that this would be unnecessary? This is sent through secure HTTPS.
Thanks for your insight!
imho, if everything is sent via https then everything is already encrypted anyway
In case you are using HTTPS it should be enough, but you can never be cautious enough so I would at least hash the password with MD5 + a Salt value.
You could use a hidden field to store the Salt value and then generate the hash trough something like <script>var fullhash=MD5(MD5(*value of the password*)+MD5(*value of the saltfield*));</script>
you can make any variations of MD5'ing the password and salt value and combining those, md5ing and so on.
Related
I'm really confused with hashing password when sending via ajax and sanitizing and validating the login in php.
Should I hash passwords before sending it via ajax?If I do what about sanitizing and validating hashed-password and storing another hash of ajax submitted hashed-password in database?
I know hashing a javascript hashed-password doesn't make any sense here.
Anyone can tell what is the best practice for sending passwords via ajax and sanitizing/validating in php.
The common approach is to send the passwords as plain text to the server (making an AJAX call, in your case) and then in server make the hashing, before you hit the database either for creating a new user of checking if the inserted password is the correct one.
If you aren't using HTTPS on the wire, you might want to perform the hash on the client just to make it a bit harder for a hacker to retrieve the cleartext password. It's still best to use HTTPS of course.
There's also a cryptographic protocol called Secure Remote Password, which is intended to make it harder to dictionary attack the user's password. It takes a bit of work to implement, though.
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
here's what I'm up against.
I have an app for iPhone that I am building that communicates with password protected pages on my site. The app can get through the password protection fine and can get the response from the page just fine. The problem is that when I try to login to the site from my app it gets rejected. I believe this is because I am hashing the password with Bcrypt in the app before sending it to the site and then checking it with password_verify(), which of course takes the plain text of the password and then the hashed version, but I am giving it two hashed versions of the same thing which it is not accepting.
My question is this: is it possible to compare the two encrypted passwords using password_verify or some other function, or not? And if not, is it secure enough to (dare I say it) send the password in plain text from the app?
Thanks to everyone in advance!
is it possible to compare the two encrypted passwords using password_verify or some other function, or not?
No. password_verify requires the plaintext password and the previously hashed form of the password with the embedded salt as its inputs and there's no way around that. The algorithm is such that you need the salt again to produce the same hash, so your only other option would be to transfer the hash/salt to the client to reproduce the algorithm there. But that's pointless, since you want to do the password confirmation at the server, not on the untrustworthy client.
And if not, is it secure enough to (dare I say it) send the password in plain text from the app?
Sure, as long as the communication channel is secure, meaning you have an SSL connection.
This seems like a really easy one but I really can't figure it out. I want to use Auth::attempt($credentials) in Laravel 4 but with a password that has already been hashed (since it's an API). It works when I send the unhashed password, but I don't understand how to tell Auth to “not hash” the given password.
Quick “demo”
What works:
Auth::attempt([Request::getUser(), Request::getPassword()]);
curl --user username:notHashedPassword localhost:8000/api/
What doesn't work:
Auth::attempt([Request::getUser(), Request::getPassword()]);
curl --user username:$2y$08$xo7HpxFyeF2UKHOYs/e localhost:8000/api/
Are there any arguments I could pass to Auth::attempt() that would tell it to use it as it is instead of trying to rehash it (as I think it does)?
You can login the user manually
$user = User::find($id);
if ($user->password == Request::getPassword()) {
Auth::login($user->id);
}
You really shouldn't be hashing the password before you are sending them. How are you going to be able to hash the password properly prior to sending it without the salt? If you have access to the salt before sending the password then why are you using an API?
If you are worried about security of passing an un-hashed password, then you should be using SSL to ensure a secure transfer of data.
Don't consider an API any different then using a web page -- and you don't salt passwords before you submit a form on a website, instead if you need that level of security you rely on https / SSL.
The hashing method used by Laravel generates a different hash each time (even for the same string). You can read more about this in Hashing for Laravel. As you can read, it doesn't hash both strings and compare them, instead it uses the unhashed string to compare with the hash.
If you really do want to do this you'll need to implement your own Auth Provider and a different hashing algorithm that allows you to compare hashes.
If you're concerned about security you should consider HTTPS so that secure details (including passwords) are never sent in plain text.
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.
Basically, I have an ajax form that carries login information, is there any way I can encrypt the password before it sends in ajax then decrypt it in php?
Or any other ways I should look at it?
Many thanks :)
There is no reason to do any encryption in JavaScript or PHP as the appropriate solution is to use SSL (HTTPS). Nowadays you can even get certificates which are trusted in all browsers for free so there's no reason for not using SSL.
If you cannot use SSL for some reason, you could get a JavaScript implementation of RSA so you can encrypt it locally but only your server is able to decrypt it again.
You could use RC4, since I know theres an implementation of it in PHP and Javascript. However, with any sort of encryption, you'd have to leave the key client side (so it can encrypt it), which means that anyone who has access to your page can get the key and decrypt it (thus defeating the point).
You might be better off either hashing it client-side (and then matching the hashes in PHP, if you don't need to know the password), or using Public-Private key encryption (like RSA), so that clients can encrypt, but not decrypt it.
For hashing, look at hash() and sha1 for Javascript.
And for RSA, check out this blog post http://www.sematopia.com/2008/10/rsa-encrypting-in-javascript-and-decrypting-in-php/
Use an SSL certificate and send the login over HTTPS from your AJAX form.
You can't in a secure manner. you should use https
You can do md5(password) in both JS and PHP, and then compare the encrypted passwords.
As username is not encrypted, you can use it to take the password from DB in PHP, and then encrypt it.
Best way to do that is:
generate a uniqid, save it in $_SESSION['crypt_key'], and send it as a hidden input on the ajax form;
encrypt in JS using md5(crypt_key + password) before sending it;
encrypt in PHP using md5($_SESSION['crypt_key'] . $password) and compare them. This way, every request will transfer an unpredictable crypted password.