Everything is in the title.
After a successfully post request to create a user, should I include the password in the response ?
Thanks.
Password goes the only one way, from user to server and never comes back. Actually after user is created, you should not posses password as plain text anymore. It should be hashed by BCrypt or other secure hashing function and stored in database.
Even though password would be hashed you should never send it to the client (browser)
Related
I have set 2FA up with spring security. The problem is, at the moment the 2FA code must be entered in the same form as the username/password. Is there a way to ask for the username and password first, and then, if they are valid, ask for the 2FA code?
I have done the same in angularJs.
The logic:
When the user has 2FA enabled, on form submit with only username and password, instead of returning a bad credentials response (401) or a success response, I return a Status code (403) indicating the server understood the request but refused to fulfill it.
When angular receives this 403 status it hides the username and password field and shows the OTP field. At this point the username and password are still present as angular objects but only hidden.
When the user enters the OTP and clicks submit, I again make a post call and this time pass the username, password and OTP.
This might be an old question but i still didn't find proper answer for this question, so please be patient.
I have a https login page,which is using a form post method and sending the credentials to the server...blah blah.
At the time of login, if you use IE and F12 for network monitoring, click start capturing. You can see some URL which has similar to login, servetloginauth(from gmail.com) and you can see the request body with your username and password.
Okay, one can argue, that only if the user didn't logout you can see that.
Now logout and don't close the browser and get browser dump(any browser, any version) off of Task Manager(i'm not sure how to do the same in Mac).
Use WinHex editor to open the dump file and do Search/Find: "password=" or the actual password(since u r testing your own login, you already knew your password).
You can see the password in clear text.
Now my question is, How can i mask the password:
1. Either in the Post request URL
2. Or when the browser is saving my credentials to the dump, i neeed it to be masked/encrypted or should not save the password at all.
My code for jsp:
<s:form id="login" name="loginForm1" action="login" namespace="/" method="post" enctype="multipart/form-data" >
<fieldset><!-- login fieldset -->
<div><!-- div inside login fieldset -->
<div....
<label for="password" class="loginLabel">Password</label>
<input type="password" name="password" id="password" class="longField nofull absPosition" size="16" autocomplete="off" alt="Password" placeholder="Password" title="Password|<
Current solution i have as below, but i need any alternatives without much effort.
The password can be read from the memory if it is being sent as
cleartext. Using the salted hash technique for password transmission
will resolve this issue. Hashing is a cryptographic technique in which
the actual value can never be recovered. In the salted hash technique,
the passwords are stored as hashes in the database. The server
generates a random string, salt, and sends it along with the Login
page to the client. A JavaScript code on the page computes a hash of
the entered password, concatenates the salt and computes a hash of the
entire string. This value is sent to the server in the POST request.
The server then retrieves the user's hashed password from the
database, concatenates the same salt and computes a hash. If the user
had entered the correct password, these two hashes should match.
Now, the POST request will contain the salted hash value of the
password and the cleartext password will not be present in the memory
SHA 256 is a strong hashing algorithm available today – readymade
implementations in JavaScript are available and quoted in the "Good
Reads" section.
Note: For pages containing sensitive information or pages wherein data
can be modified in the database, use JavaScript to flush the memory of
the browse
and the images are as below.
On an additional note, i can settle with something Citibank did for their customers on their website.
I logged in the website and in the dump i see my username is masked(as it appears in the website), i need something which does the same to the password field too. can someone explain me how to do it please.
What you are suggesting has a serious security flaw. If you calculate the hash on the browser and then send to the server (without the password) then the server can't trust that the browser actually calculated the hash. A hacker might merely have read the file of hash values and construct a program to send the hash value in. The security comes from the server (a trusted environment) having the password which can not be guessed from the hash, and then proving to itself that the password produces the hash.
If you send both the hash and the password, then you have not solved your problem about the password being available in clear text.
There would seem to be a way if you hash the password multiple times. You can hash the password once (or more times) on the browser, and use that for subsequent hashing calls on the server. It seems normal to hash multiple times (although it is unclear how much this really makes it more secure). The point is that the browser would be holding an intermediate value which would not tell you the password that the user typed. It would, however, still tell you the value that you need to send to the server to authenticate the user. That value is infact a proxy for the password, and is usable as a password in calls to the server. But ... it is not the password that the user typed in.
One final way looks that it might work: use an asymmetric encryption. The server provides a salt value and a public key. The password is encrypted using the public key, which can only be decrypted by the private key that is held on the server. Because the salt value changes every session, the encrypted value held in memory itself would not be usable across another session. The server decrypts the value, extracts the salt, giving it the password from which to go ahead and do password authentication.
You have to device for how the passwords are stored in the database. There are multiple ways to do this, but there is no way you can create anything that is IMPOSSIBLE to hack/read.
However, you can limit MITM attacks by hashing the password X number of times before sending it to the server.
When the hash is recived by the server, you do X number of new hash rounds. You should also figure out a how to manage your salt.
This should be sufficient for most applications. Also this is how most application does it these days.
gpEasy: http://gpeasy.com/ does this by hasing Sha-256, 50 times on client side. Then another 950 rounds on the server. In total 1000 rounds. This also includes a salt which is calculated by its "current hash"
def hash(self, pw, loops = 50):
pw = pw.strip()
for i in range(loops):
salt_len = re.sub(r'[a-f]', '', pw)
try:
salt_start = int(salt_len[0:0+1])
except ValueError:
salt_start = 0
try:
salt_len = int(salt_len[2:2+1])
except ValueError:
salt_len = 0
salt = pw[salt_start:salt_start+salt_len]
pw = hashlib.sha512(pw.encode('utf-8') + salt.encode('utf-8')).hexdigest()
return pw
This is a version of the mentioned algorithm for calculating hash with a salt from the first numbers in the hash.
I am working on an implementation of javamail in my current program. The testmails are sent successfully if I predefine the credentials directly in the code or if I write it via text/password Fields, but I want it more userfriendly. I'm using a MySQL DB for my program where I could store the smtp password but for security reasons I don't want it in cleartext and the only option I know would be a synchronous encryption and use the users login password as the security password.
Are there any other options to store the password safely or even a other option that the user doesn't need to enter his password all the time?
For sure, this will only be an option via checkbox for saving credentials, if the user doesn't want this he has to write it all the time.
Thanks for helping.
Store the password encrypted (hashed) in the database. Encrypt with the libs of Apache Common for example:
String password = "PASSWORD_TO_ENCRYPTED";
String salted = password + username; //salt the password value, using the username is only an example
String hash = DigestUtils.sha256Hex(salted.getBytes("UTF-8"));
If you want to check if a given password is correct, salt it and hash it same way.. and compare the hash strings with the value stored in the database.
I have created a web service that uses HTTP Basic. I am developing an Android application that will present the user a login screen with a textfield for username and another for password. When correct username and password is provided the user will see a new screen.
How can I validate on login that the username and password is correct? Since the dashboard screen that the is taken to after successful login does not by itself needs data from the webservice I can't check if it fails.
Do I have to check against a URL in my application (sending a HEAD request) and see if it fails? Are there any conventions here?
Check the response String and look here HTTP status codes
You can also use for example a mozilla add-on like Poster to check the server response.
Ok i guess you need to apply validations on username and password.
Validation are decided by the server end i.e. how username and password should be
for instance USERNAME.
1) Should not be less than 2 characters and max. length is decided.
2) If Email is to be used as Username then validation for email i.e. mus contains #,. etc.
for Password
1) Length of password should not be less than 6 or no to be greater than 20.
2) May or may not contain special characters.
Ask your server end that how they like to receive the username and password and check if user supplied inputs are valid or not , if valid only then make a HTTP call otherwise show user his respective error validation message.
you can send your username and passwords using http get/post method and can validate this at srver side
I need to implement a simple remember me option in a java servlet with cookies, without using any advanced framework.
First, at login, I create the cookie and send it in response to the browser (client). The value to be stored in the cookie is just a simple hash from username + password.
How should I manage the incoming request from the browser, sending the cookie?
My approach is to check between registered users if there is any user that has the hash from username + password equal to the value in the cookie?
Is this approach correct?
Also, I did not understand exactly what is the mechanism of the expiration date. Does the browser delete the cookie when it is expired, it not, how do I check if the cookie is expired?
As long as you're not using HTTPS the method you suggest is highly insecure. I would suggest to generate some sort of session token (e.g. use java.util.UUID.randomUUID()) and set this as cookie and store it somewhere on the server side so you later can identify the user associated with this session id in the cookie.
This gives you the opportunity to reset a certain session cookie if you think there's some fraud happening and there's no direct relation between the user name/password and the cookie id you use. But note: this method is still vulnerable to a man-in-the-middle attack.
Concerning the expiration: yes the cookie becomes invalid and might get deleted by the browser if it is expired. But you can set the cookie to something in the year 3000, so it lives forever.