I wrote an app that queries a Jira API which requires authentication that I provide through Basic Authentication (base64 in the header). The password was stored in the code which has to stop now because I want to hand over the code.
When the users changes their passwords due to the password schedule, the app should prompt the user for the new Jira password, save it securely, and pass it to the Jira API via Basic Authentication.
What's the best way to do this?
Normally, we would hash it but that's not possible because hashing is one-way direction and we need to pass in the real password to Jira instead of a hash.
In case of storing a string which needs to be protected in case of breaches or as a general software data security concern, encryptions should be done. For example, in your case, when the password is taken by the user then it shall be encrypted by the software before storing. While retrieving, the password is decrypted and converted to the hash(or base64) which Jira accepts for the login handshake.
Apart from the simply encrypting and decrypting, a better approach will be to use salts while encrypting and using multiple encryptions in the loop to avoid brute force attempts.
Pseudocode:
unsafe_password = getPasswordFromUser()
salt = getRandomString();
safePassword = encrypt(unsafe_password, salt, key)
// Store the password
putEntryInDB(user, safePassword, salt)
// Retrieve password
[passwordSalt, encryptedPassword] = getSaltAndEncryptedPasswordFromDB()
unsafePassword = decrypt(encryptedPassword, passwordSalt, key)
// Now login into Jira with the actual user's password (unsafePassword)
P.S. You'll be needing to store a key in the code or in some software's configuration.
Source: Attempt 4&5 https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
Related
I want to encrypt my password after created user and persist it inside the DB. I write password to "password field" and press "Save button". Then I use this library
For encryption
BasicPasswordEncryptor passwordEncryptor = new BasicPasswordEncryptor();
String encryptedPasword = passwordEncryptor.encryptPassword(myPasword);
user = new User();
user.setUsername(username);
user.setUserRole(role);
user.setFistname(firstname);
user.setLastname(lastname);
user.setGroupId(group);
user.setBssLogin(login);
user.setBssPassword(encryptedPasword);
dao.addCrmUser(user);
After that, I have a new encrypted password inside my DB.
On the server side, I get the user and try to decrypt the password
String login = user.getLogin();
String password = user.getPassword();
String dencryptPassword = encryptor.**NOT_METHOD_FOR_IT**(password);
I need the original password, which is set inside another system.
How can I do this with my current library ?
I fount this and another libraries in Github that use some key but I do not know what is better and/or faster.
You do not decrypt the password from the database to verify it.
You encrypt the password received from the user when trying to login, and compare that encrypted value with the value in the database. Good password encryption is really a hash function, which is not reversible, for security.
The BasicPasswordEncryptor() in jasypt does despite it's name, not encrypt the password, but hashes the password using a one-way-hash (A big tell, is that the method don't require an encryption key).
You can't get the password back after this process, and the password is verified using the checkPassword(String plainPassword, String encryptedPassword) methode.
If you really need to be able to decrypt the password, you need to use another way to do real encryption when encrypting it. This raises the need for handling of encryption keys, which might introduce just as many problems than it sorts (where to store them etc.)
currently I work with Shiro to create an authenticated and authorized connection between server and client.
For now I don't have a special realm and only use the shiro.ini to save all my test users.
My question now is if there is a possibility to save the salt for each user in the shiro.ini or do I have to create a seperate database as a realm?
So is there the chance to save it somehow like this within the .ini?
[users]
*username* = *hashed Password*, *salt*, *roles
I actually do not really understand how or where I can save a random salt for each user.
My current understanding is that the 'hashed Password' in the ini is the final comparison value, for the incoming token containing a password that firstly has to be hashed with the user specific salt.
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.
Users log in to my BlackBerry app with a username and password provided at registration. My app connects to a Java Web Service that does all the logic.
How do I go about storing the password and username in a safe manner on my server? Everybody says salting and hashing, but I have no idea how to do this since I've never worked with it. How can I do this in Java?
How do I manage sending the password securely from the app to the server?
To store the credentials, one possibility is to use PBKDF2. A Java implementation (that I have not used) is available here. Run the password with the salt value through that and store the resulting hash data. The salt value is typically a newly generated random value (one for each password). This helps prevent dictionary attacks via rainbow tables (pre-computed tables of hashed passwords). Using java.security.SecureRandom is a possibility for generating those.
The client application should probably connect to the server using SSL/TLS. That will provide the encryption to protect the credentials when passed from client to your server application.
Edit Based on our conversation in the comments, it sounds as if the goal is not to use SSL. Assuming that is true and no other end-to-end communications encryption is planned, then it seems to imply that the security of the communications is not a high priority. If that is true, then maybe the described scheme for authenticating is sufficient for the application. Nonetheless, it seems worth pointing out the potential issues so you can consider them.
The proposed scheme (I think) is to send from the client to the server this value: Hash(Hash(password,origsalt),randomsalt). What this really means is that the password is effectively Hash(password,origsalt). If the attacker can get that information, then they can login as that user because they take that value and hash it with the new salt value to authenticate. In other words, if the database of hashed passwords is compromised, then the attacker can easily gain access. That somewhat defeats the purpose of salting and hashing the passwords in the first place.
Without SSL (or some other end-to-end encryption), there is the possibility of a man-in-the-middle attack. They can either listen in or even impersonate one end of the conversation.
Seems like your question has a few parts...
The most secure way to store the password in the database is to use a hash with a Salt + Pepper seed as described here. If you want to find a good way of implementing that specific technique in Java, try opening a new question.
I can see why it would make sense to encrypt a username/password hash prior to sending to the server, since SSL proxies can be a man-in-the-middle for that operation.
As a solution try creating a token in JSON or XML format that has the following properties:
Username.ToUpper() // Dont want this to be case sensitive
ExpiryDate (Say now plus 5 minutes)
Nonce (a random number that is saved on the backend to prevent replay attacks)
SHA 256 signature
Use the locally entered username and password to create a SHA256 signature, as it will be a constant. Use this signature to sign the JSON or XML you send to the server with each request.
In other words you're using a symmetric key based on the username and password, without sending it across the wire. Of course you may want to salt and pepper the generation of that symmetric key for more security.
That's all I got for a high level design, since I'm not intimately familiar with Java. Do share your links/code when you do find the answers.
So here's what I ended up doing:
package Utils;
import org.apache.commons.codec.digest.DigestUtils;
import org.apache.commons.lang.RandomStringUtils;
/**
*
* #author octavius
*/
public class SalterHasher {
private String salt;
private String pepper = "******************";
private String hash;
private String password;
public SalterHasher(String password, String username)
{
this.password = password;
salt = RandomStringUtils.random(40, username);
hash = DigestUtils.md5Hex(password + salt + pepper);
}
public String getHash(){
return hash;
}
/**
* #return the salt
*/
public String getSalt() {
return salt;
}
public String makeHash(String salt){
return DigestUtils.md5Hex(password + salt + pepper);
}
}
A very simple class that generates a salt and the hash for me and has a pepper included for added security, the makeHash() function I use for verification when the user logs in. In view of what I previously mentioned in the comments above I didn't end up using the verification process I proposed and chose to simply add the pepper to my server side code since hashing I believe would prove to be heavy on the BlackBerry device. Thanks again to those who helped me. Good discussions were had :)