I have read about salted hash password technique to protect password from some attacks. https://www.owasp.org/index.php/Hashing_Java#Why_add_salt_.3F
But I have some confusing, should I send a salt value (for all use try to login) and then use Javascript calculates hash with that salt?
I think it's helpful to improve security. But I'm not sure, I'm not see anyone use this way.
Thanks in advance.
An attack case: your server is compromised, the attacker reads the database and gets the hash, the attacker crafts a HTTP request and send the hash directly to your server and log in to the user's account. The security is lowered even more in this case.
The salt is used to prevent same password from appearing the same to attacker, so that it can defend against the case where the attacker compromises your server and obtain the username and hash for offline password cracking.
Related
I'm running Nessus on one of my websites and it returns "Web Server Transmits Cleartext Credentials" vulnerability. It is a low level vulnerability, but I want to understand it.
My website encrypts the password text box and that is sent to a database procedure to compare to what encrypted password I have for that user in my database. So even if it was cleartext the encrypted password is being sent across. Does this mean that this vulnerability doesn't apply to my website or am I still allowing the password to be exposed?
Thank you
I believe there are multiple facets to your potential security issue. This would fail most audits if there is any sensitivity regarding the web service.
This vulnerability occurs because you are not using HTTPS, while handling passwords. (a password field in a form). So yes you are vulnerable to this technically. A Man In The Middle attack could see what is being transmitted and re-use that "encrypted" value. They could also modify the data to cause other actions to occur, depending upon design flaws. You have at least one concern that you have not mitigated here. HTTPS is the best solution to prevent MITM.
Beyond the first point - You seem to be indicating that you know the password value placed into the password field/box by a user is being encrypted before transmission to the server. If the value is being encrypted by using javascript inside the browser, then you are likely not properly securing the password. Client-side javascript is a poor method to implement security controls like this. (especially if there is no MITM-prevention) But if someone is simply pasting an "encrypted" value from somewhere outside the web browser into the browser form and sending it to the server, then the nature of the encryption is a key point. It should be using well known modern encyption protocols such as AES. But this is meaningless if anyone can capture the value via MITM attack and re-use it.
Strongly urge the adoption of TLS security via HTTPS configuration for the web service.
I have a client that initiates calls through a proxy that requires authentication.
The proxy sends a challenge to the client and the client responds with the credentials.
Is it possible to respond to the challenge without the password in cleartext?
The point is that I don't think storing the password in cleartext on the client is a good idea, especially in this case, since anyone that knows the password would be able to make calls using the account of another person.
I know that storing the hash of a password is okay on the authenticating side (the proxy in this example), but I never saw such thing on client side.
Thanks, Mickael
Generally, it won't be in clear text because the challenge will state MD5, e.g. (from RFC 3261):
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
If it doesn't say MD5, that's an issue with your proxy.
If you know the realm, you can store the first stage of the response with password as an MD5 hash, along with the username (use of nonce comes later). Otherwise you'd have to use a reversible form of encryption locally for it.
I am asking myself. What is the best way to send personal information from your iOS device to the server.
At this moment I encrypt the password in the app ( sha1 salt password pepper ) then I send post data using from iOS to the server.
What is the best way to protect the user and secure for any MITM attacks. Is my way secure enough?
UPDATE:
I added the SSL certificate. To make sure the user only has to login once I store a key generated when the user registered. I fetch them when the user logins for the first time. In oombination with the username and user id. Is this a good way? Only jailbroken users can read it and have risk.
Hashing the password on the client side will help prevent the password itself from being detected in eavesdropping, but it really doesn't provide any security on its own, as the credential then becomes the hashed version of the password, not the original password itself. An eavesdropper could just grab the hashed version, and then send the hash themselves.
By far the easiest solution is to simply use SSL/TLS. Since you mentioned 'post', that means you're probably using HTTP. Instead, you could just connect via HTTPS and post the data, exactly the same as you're doing already. Long as the certificate is checked for validity (I believe the iOS framework already does such by default), then the connection should be largely secured.
That should be good enough for most situations. There are some more complicated and involved techniques you can use to harden further, but SSL/TLS does a massive amount on its own.
We are currently implementing several web application that requires the user to create a user login that will be authenticated through LDAP calls. The LDAP server and user accounts will be shared by all the applications and the user's credentials will be the same across all applications.
My question is where does the hashing take place in a standard LDAP scenario, on the client side or does the LDAP server take care of it. It was my understanding that the LDAP server takes in a user password, at the time of creation, and hashes it and stores it. (By the by we plan on using salted SHA512 hashing and SSL connections between the client > webserver > LDAp server)
It was my understanding that the hashing operation takes place centrally on the LDAP server, relieving the client of the trouble and avoiding any breakage on the client end to affect other apps.
Modern, professional-quality servers use storage schemes for password attributes (usually userPassword and authPassword) that involve executing the hash on the server. Servers usually append or prepend a unique value (called a salt) to a password, then execute the hash function. The "salt" minimizes the effectiveness of dictionary attacks, that is, dictionaries are more difficult to create for salted, hashed passwords.
SSL (a secure connection) should be used, or a non-secure connection should be promoted using the StartTLS extended request. An encrypted connection should be used so that passwords can be transmitted in the clear with BIND requests. Passwords that are transmitted in the clear over a secure connection can be checked for history and quality by the servers' password policy enforcement mechanisms. For servers that enforce password history and quality checks, passwords should not be transmitted pre-encoded. Therefore, it is not so much the "trouble" to the LDAP client as it is the fact that the server can enforcement organization-wide and agreed-to password quality and history checks in a central location.
see also
LDAP: StartTLS request
LDAP: Programming Practices
I have a website that requires a user to authenticate themselves with a user name and password. I would like to use SSL, but I don't have an SSL certificate. But I do something else that I think is okay.
My site is primarily AJAX based and requires JavaScript, otherwise nothing will work.
When the user tries to login, I query the database using AJAX to look for a salt for that user name, if none is found a random salt is returned (to keep people from knowing if there is a user with that user name or not). Then, using a MD5 function for JavaScript, I hash and salt the password 4K times (like Linux does when it uses MD5 for it's password hashing) client side, then I pass that hash to the server in plain text. This hash will then be hashed a few more times and presented to be checked with what's in the database.
Is this secure? If not, how can I secure it without forking over the cash for an SSL cert for a mostly internal website?
No. It's not secure. A man-in-the-middle can snoop the hashed value and present it to you later, falsely authenticating himself.
To authenticate someone, you have to prove that they know a secret. Anything passed over an unencrypted channel is not a secret.
Use SSL. You can get certificates for free that are accepted by Firefox, and you can give IE users instructions for adding a new CA to their trusted roots. Certificates that are accepted by all browsers out of the box are cheap, I think $30 per year.
The best options are:
Use a certificate signed by StartCom (free). Supported natively by recent versions of Firefox and Safari. Users with IE can add the CA to their list of trusted roots.
Use a self-signed certificate and distribute it to your users to add in their browsers.
As others mention, your solution is not secure. It offers no improvement over sending the password in cleartext to the server. The major reasons:
Anything sent from the client in clear text and directly used to authenticate will be susceptible to man-in-the-middle and eavesdropping attacks. In your suggested solution, if you know the hashed password, you can log in. Sending the password as a hash makes no difference.
After authenticating, the data is still sent in plaintext, so it is easy to sniff.
MD5 is full of holes
You could make your own SSL certificate for free, it wouldn't be trusted by general users but you can trust it.
By using JavaScript and a transport layer that is not encrypt, you open the possibility of someone grabbing that hash you send to your server, not to mention give an exact blueprint of how you are hashing the password/username.
It really depends on how important security is for that application. If it is very important drop the Ajax, and pick up a SSL certificate and use the HTTPS layer.
Your solution is open to replay attacks. Try Digest Authentication (RFC 2617) directly between the browser and web server.