Password Encryption

[Vikas Kapoor]

I am developing a login module in my web application.I have read somewhere that it's not good to store the password in plain text. Can somebody tell me the workaround? I have read about Base64 and MD5 encoding in Java API. What is the best way to work with password?

[Brian Lang]

Although I haven't used Java / JSP to store a hashed password, I have worked with plenty of web applications that require login data. You're right, you should never store a plaintext password, and on top of that you should avoid storing a hashed password in an insecure place (e.g. an easily accessible file in the directory structure).

Although some might consider it being paranoid, I won't use anything less than SHA1 for a hash value, and I use a hash salt by default regardless. SHA1 is typically universally available, and a hash value produced by an SHA1 function in any language will be identical.

Take a look at java.security.MessageDigest

[Campbell Ritchie]

Sounds too complicated a question for beginner's. Moving to our security forum.

[Vikas Kapoor]

Ok I have found two techniques listed below.
Using BASE64(sun.misc.BASE64Encoder)

String password = "password";
BASE64Encoder encoder = new BASE64Encoder();
encryptedPassword = encoder.encode(password.getBytes());

Using MessageDigest(java.security.MessageDigest)

MessageDigest md = MessageDigest.getInstance("SHA-1");
md.reset();
md.update(password.getBytes());
System.out.println(new String(md.digest()));

After encryption I will be storing it into database. And when next time user login again at that time I will again encrypt it and match it with the one stored in database(already in encrypted form).
Am I on the right track? Can the password encrypted using above techniques be decrypted?

[Ulf Dittmer]

Base64 is not an encryption - it's an encoding; as such, it is trivial to reverse. So don't use that.

new String(md.digest()))

Don't do that. A digest is binary data, and shouldn't be converted to text. If you need a version that can be used where only text will do (e.g. in a varchar field in the database), run it through Base64. That will produce an ASCII string. (This is actually the main function of Base64 - to generate an ASCII version of binary data).
[ December 14, 2008: Message edited by: Ulf Dittmer ]

[Pat Farrell]

Really, "Base64 is not an encryption - it's an encoding; as such, it is trivial to reverse. So don't use that." Listen to this. Don't do that.

It is better to not use only the user's input password to the hash. Better security is easy, just invent two nonsense phrases and prepend one before and append one after the users's input.

So if you use X7F and el3 then use

md.update("X7F".getBytes());
md.update(password.getBytes());
md.update("el3".getBytes());

And is much better to suggest to your user to enter a pass phrase, a long one, rather than a weak single word.

Also, its a good idea to filter against known bad passwords. See
Known common passwords

[Campbell Ritchie]

There is another thread with a similar subject here. It might be helpful to you.

[Vikas Kapoor]

Thanks Ulf,Pat and Campbell!

After encryption I will be storing it into database. And when next time user login again at that time I will again encrypt it and match it with the one stored in database(already in encrypted form).

This method to authenticate the user is fine?
Something I don't understand is that why can't we store the password in plain text?

[Ulf Dittmer]

This method to authenticate the user is fine?

Yes, that sounds good.

why can't we store the password in plain text?

You can, but you shouldn't. Passwords are always of interest to attackers, whether they're from the outside or from the inside. Not keeping them in clear text greatly reduces their attraction (if it doesn't remove it completely).

[Pat Farrell]

Originally posted by Ulf Dittmer:
You can, but you shouldn't. Passwords are always of interest to attackers

Yes, the fundamental rule of security is to make the cost of the attack higher than the value of the target. If you store a bunch of passwords in the clear, that is a very valuable target. So it justifies much more protection from attack.

Its much easier, simpler, faster, cheaper, etc. to simply lower the value of the target. No cleartext passwords greatly lowers the value of your system, database, website, etc.

[Vikas Kapoor]

After one and half year I ran into one technical problem.

Before : User Password -> SHA-1 -> Base64 - database (varchar)

Now, I come to know SHA-1 is weak and better option like SHA-2 should be used. But when I apply Base64 encoding after processing password using SHA-2, it reaches its limit of Maximum encoded line length (that is 76) Ref : Base 64. It adds line feed(10) and carriage return (13) into that encoded string.

I have two options,

1) Find a Java encoder which has higher Maximum encoded line length. Any input?
2) Rather than storing varchar, I store blob and just get rid of encoder altogether. I can compare blob data to authenticate the user.

Please give some suggestions.

[James Sabre]

Vikas Kapoor wrote:After one and half year I ran into one technical problem.

Before : User Password -> SHA-1 -> Base64 - database (varchar)

Now, I come to know SHA-1 is weak and better option like SHA-2 should be used. But when I apply Base64 encoding after processing password using SHA-2, it reaches its limit of Maximum encoded line length (that is 76) Ref : Base 64. It adds line feed(10) and carriage return (13) into that encoded string.

I have two options,

1) Find a Java encoder which has higher Maximum encoded line length. Any input?
2) Rather than storing varchar, I store blob and just get rid of encoder altogether. I can compare blob data to authenticate the user.

Please give some suggestions.

It is not mandated that Base64 break it's out put at 76 bytes. I can think of several approaches -

1) The line length of most Base64 encoders can be configured. Check the documentation for the Base64 encoder you are using. If not then find one that can be configured.
2) Use a regular expression to remove the offending characters. In these forums this suggestion is likely to go down like a lead balloon.
3) I cannot see why people want to store the digest as a human readable field. I always use binary/var binary/blob to store the raw digest bytes then this problem does not occur.
4) Use a prepared statement when inserting the base64 encoded value in the database. This way the line endings will not matter.

You don't mention it but do you actually use a seeded digest? If not you should. There is little point to use sha2 if you are not using a seeded digest.

[Vikas Kapoor]

I do not know what is 'seeded digest'?

If not you should. There is little point to use sha2 if you are not using a seeded digest.

I do not follow this too.

[Henry Wong]

Vikas Kapoor wrote:I do not know what is 'seeded digest'?

If not you should. There is little point to use sha2 if you are not using a seeded digest.

I do not follow this too.

A seed is just a random number. Basically, a first time the hash is generated, a random number is generated (it can be any size, but let's say for example 16 bits). This random number is hashed with the password to get a sha1. Furthermore, this seed needs to be stored with the sha1 hash -- so instead of just storing the sha1 (which is 160 bits), you'll need to store the seed too (an additional 16 bits in this example).

During the challenge, the saved seed and the user entered password will need to be hashed together to compare to the sha1 portion that is saved.


Why is this important? If two users have the same password, they will have the same sha1 -- so it will be possible for users to guess another users password, if by coincidence the passwords are the same. With the random seed, it is likely that the seed will be different, and hence, the sha1 hash will be different, even if the two passwords are the same.

Henry

[Henry Wong]

While we are on the subject, this topic from a few days ago may be relevant...

https://coderanch.com/t/491139/Security/Double-Hashing-hashing-SHA-MD

Basically, the last few posts of the topic talks about the passwords themselves, and how it is the weak link. Going from sha1 to sha2 may be a good idea. Adding seeding may be a good idea. But keep in mind that the password is the weak link, and all this work is just fortifying areas which are already stronger than the password itself.

Henry

[greg stark]

A "seed" is more commonly called a salt in this context.

[Henry Wong]

greg stark wrote:A "seed" is more commonly called a salt in this context.

You're absolutely right. I was thinking salt. I guess I actually don't know what a "seeded digest" is.

Sorry for the confusion,
Henry

[James Sabre]

Henry Wong wrote:

greg stark wrote:A "seed" is more commonly called a salt in this context.

You're absolutely right. I was thinking salt. I guess I actually don't know what a "seeded digest" is.

Sorry for the confusion,
Henry

Sorry Henry, it's actually my fault. I initiated the confusion by using 'seed' rather than 'salt' in my earlier post! Three demerits.