GeeCON Prague 2014*
The moose likes Security and the fly likes Password Encryption Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Security
Bookmark "Password Encryption" Watch "Password Encryption" New topic
Author

Password Encryption

Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
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
Ranch Hand

Joined: Oct 21, 2008
Posts: 43
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
Sheriff

Joined: Oct 13, 2005
Posts: 39084
    
  23
Sounds too complicated a question for beginner's. Moving to our security forum.
Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
Ok I have found two techniques listed below.
Using BASE64(sun.misc.BASE64Encoder)

Using MessageDigest(java.security.MessageDigest)

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
Marshal

Joined: Mar 22, 2005
Posts: 42047
    
  64
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 ]

Ping & DNS - my free Android networking tools app
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

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
Sheriff

Joined: Oct 13, 2005
Posts: 39084
    
  23
There is another thread with a similar subject here. It might be helpful to you.
Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
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
Marshal

Joined: Mar 22, 2005
Posts: 42047
    
  64
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
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

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
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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.


Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

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

http://www.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
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
A "seed" is more commonly called a salt in this context.


Nice to meet you.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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.
 
GeeCON Prague 2014
 
subject: Password Encryption