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
Related
I'm creating a website which encodes user's data (e.g. username, e-mail, phone number...) so that their data is safe.
To prevent data from getting to the public I'm encoding it using SHA1 before storing it in the database. I'm handling the requests using PHP.
When a form is submitted and data is sent, can the data be leaked or intercepted? by the NSA or an attacker for example.
If so, I'm thinking about encoding the data using JavaScript right before the form is submitted. Would that work?
I know I shouldn't be answering this as it is off topic but there are things that must be cleared here:
"Encoding" data
In your first paragraph, you said I am encoding the entered data, I don't know what you mean exactly by that.
If you mean encryption, I'm not sure how are you encrypting e-mails/username if you use them for authentication.
But generally speaking, encrypting data is a good thing as long as you are using a good cipher with a strong securely stored key, check Where to store a server-side encryption key?.
You also said using sha1 before storing it in the database. This is also unclear, are you hashing all data with sha1? if so. how do you "unhash" the data when you need it.
I suppose you are hashing passwords, but sha1 and md5 (two common algorithms) are not suitable for passwords (or as #Peter said: unsuitable for anything security related).
To hash passwords, you need to use the right algorithms for that such as bcrypt, scrypt or argon.
In PHP, the best way to hash a password is by using the native built-in functions. password_hash() for hashing and password_verify() for verifying the hash.
These functions are available in PHP 5.5 or newer, if you use an older version - consider updating - you can use this compatibility library by ircmaxell.
Data "leakage"
In the 2nd paragraph, you talked about data submitted in a form being "leaked", I suppose you mean intercepted a.k.a. Man-In-The-Middle attack -MITM for short-.
To protect data from MITM attacks, you need to use HTTPS instead of the insecure HTTP.
HTTPS encrypts the data sent between your server and the client (browser/user) which will prevent anyone from intercepting the data.
Usually to get HTTPS you have to pay, but now there is a free Certificate Authority -CA for short- called Let's Encrypt that provides free certificates.
Encrypting data using JavaScript
You talked about encrypting data using JavaScript before submitting the form.
That wouldn't work simply because, when the client connects to your normal HTTP website, the HTML/JavaScript is in plain-text and can be changed, the attacker can simply intercept your JavaScript code (the one that will encrypt the data) and change it to whatever he wants.
The only solution you should consider is getting an SSL certificate for your website.
NSA thing
I assume that you are talking about the surveillance done by the agency, there are two things here:
MITM attack Which I already covered above, use HTTPS.
Accessing data on your server. If the NSA is somehow interested in your data, and your server is in a place where they have jurisdiction over, they can simply access the unencrypted data in your server.
Wrong terms you use
I see that you are miss-using the terms, encoding is not what you think.
Encoding is just transforming the data into a specific format (say JSON for example).
Encryption is when you take data and transform it to an unreadable format using an algorithm and a secret key, encryption protects the data from unauthorized access, encrypted data can be decrypted to its original state.
Hashing is generating a value (called a hash) from given data using a one-way function.
Which means, given a hash you can't theoretically get the original value back.
This is just a general answer to your question and not an ultimate security guideline (I'm not a security expert!)
References
How to use bcrypt in PHP
Man-in-the-middle attack
Why is SHA1 considered less secure than often necessary?
HTTPS
Hash function
bcrypt
A simple answer to your question "Is data submitted in a form secure?" is Yes and No. It depends on how you submit your data. If you are using a cleartext protocol such as HTTP, then it is insecure. Because the data is transmitted in a cleartext and an attacker can sniff and read the data. However, if you are submitting the data over HTTPS, then yes, your data is securely submitted.
Now comes the data storage part. It is recommended to hash the password using a strong hashing algorithm and salt before storing it in database. You need not hash/encode data such as email id or username. This can be stored as plaintext.
So, in short, if you are submitting the data over SSL and hashing the password before storing, you are encrypting the data during the transmission and securely storing it in the DB. This is industry standard and many companies including the top security companies follow this.
Im dealing with legacy code here.
There's a HTML form with username/password inputs.
The form is then sent to the server (using SSL), and the password is compared to the database value.
Question: is there a way to "hide"(encrypt) the password while it is sent to the server?
Even if I'm storing the hashed-password and unique user-salt in the database,
the password is at risk while being sent by the user.
How do the professionals do it?
**EDIT:
Im planning on storing the password as a hash, with a unique salt.
If anyone gets a hold of the password (if SSL is compromised) does that mean that a hacker can gain access without a problem?
In a regular username/password login, the password is always sent to the server. Ideally, the server then hashes the password input and compares to the hash stored in the database - using a unique salt for every password. Like #Sneftel said, when you use SSL the passwords aren't being sent in plaintext.
Think about it; if only the password hash was sent to the server, and the server compares that to the hash in the database - how would that be any different from just storing the passwords in plaintext in the database? It would be enough for any attacker to get the hash in order to get entry into the system.
The security issue here would be that the password themselves are stored in plaintext in your database - that's not a good idea. There are a few tips here: http://alias.io/2010/01/store-passwords-safely-with-php-and-mysql/
You may use some javascript program at client side to encrypt the password. But that requires the user to execute that script, which can be a problem:
Some users cannot execute that script, because they access your page with a program that does not support javascript. An example could be a program that is intended to load the page and get some specific value out of it.
Some users don't want to execute that script.
So, hiding the password while being sent to the server is not that easy.
Anyway, you mentioned that you send the data using an SSL-encrypted connection. That is the usual (and usually secure) approach for that situation. The disadvantage is that, if your SSL implementation has a flaw (eg. the Heartbleed bug), your passwords are usually broken, unless you do not use the server key for encrypting the connection data (this is called Perfect Forward Secrecy).
Regarding your database, you should never store plain-text passwords in it, unless you are required to do so without the possibility of changing that requirement. You always should store the salted password hashes.
I have two functions: get_post_data() gets the POST data from a form. It then sends the username and password to process_login($username, $password). I want to send the password in plain-text.
Am I safe to do this, or do I have to hash/encrypt the password before I send it as a function argument?
Hashing should be done when storing the password to a permanent location, or obviously when you need to check it against the stored hash.
Otherwise, if you're transferring it from one server to another or an external resource I would think it would be better practice to hash it and or at minimum use an encrypted connection. Preferably both.
Yes you are safe, hashing should be done server side to prevent inconsistencies in client side hash implementations.
Once you have the variable in your php code, passing it around your own functions is safe, a user wont have access to this.
If you are worried about transmitting the password from client to server over plain-text, you should look into using https.
There's nothing wrong with having
$password = 'some piece of malicious code';
process_login($password);
because that malicious code would only ever be transferred around as DATA, and never actually executed.
Now, if you were doing something silly (ok, this would be downright stupid):
eval($password);
then yes, you would be vulnerable to getting your system completely subverted.
I know this question sounds like it might already be answered but stay with me. I have a website that needs users to sign up and log in. In this process, lets take sign up the user would provide a username and password, the system will check the information and then POST to itself for the PHP script to salt and hash the password before storing it in the database.
Now i thought this was safe, salt and hashing a password is always best practice but recently i thought about how this is happening, the data has to be sent to the server before it can be hashed up and because i don't use SSL the username and password are sent unencrypted, so would i be right in assuming that this information would be sent in plain text?
If so, this isn't good at all. So the only two ways i can see about getting through this is either:
Using SSL and securing the connection between the user and the server and encrypting the data being sent.
Hashing the information before it leaves the user, this could be done using Javascript
I want to implement the second but I'm not sure of how to do this. What would be the best practise for this?
I was thinking before the information is sent a AJAX script will take control of the data and check to see if first the information is what we're looking for and then salt and hash the information.
Are there any security implications on this implementation I have described?
Thanks for your time.
Using SSL and securing the connection between the user and the server and encrypting the data being sent.
Yes, do this.
Hashing the information before it leaves the user, this could be done using Javascript
This will not secure the data. Instead, it would effectively change the secret data to be sent to the server to the hashed version of the password. That would still be sent as plain text and attackers could sniff it and know exactly what to send.
You might be interested in the Secure Remote Password protocol.
I read lots of info about login security, and most with Ajax.
Mainly I was thinking to pass via javascript the password and username in plain text, and in php hash it.
This way:
JS plain text > php hash > database
What about hash twice during Ajax ? Do you think it's good?
Like this:
JS hash > php hash > database
So I don't care about hackers during Ajax request and of course another hash on the server will make it more secure and it's one of the best hashing method I found. Using JS hashing I will never recive the real password on the server, but, I don't need the real password, just an hash to compare the passwords hashed.
Better with JS hashing or I can go with just php hash?
As long as you use HTTPS for your data exchange and the data is not to sensitive, php hashing should be fine.
If you only use HTTP, you will have the "normal" hacking problems, so you might want to try JS hashing.
It depends on what your main concern is - a JS hash would only help if you expect that someone could be listening in on the communication between the client and the server. However if someone disables Javascript while registering and then enables it when logging in or simply goes to another computer, you won't know if the password in the db is hashed once, or twice.