• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Password Encryption in JSP

 
Ranch Foreman
Posts: 317
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How will i encrypt password in jsp? I don't want my password as plaintext instead i want it in MD5.
 
Ranch Hand
Posts: 66
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it depend on what you want to do with credentials. If you want to offer some login you just want hashes and check them if they equal. If you want to use them to login to something yourself - well, that's another story.
 
Saloon Keeper
Posts: 5913
152
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question sounds strange - what does JSP have to do with passwords? The password, once created, should be salted and hashed (NOT with MD5, which is insecure, but with SHA-2), and then stored in the DB. From then on the password never again leaves the DB.
 
Saloon Keeper
Posts: 21311
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's not how it works. In fact, it's dangerous.

A password field on a JSP is normally entered via a textbox PASSWORD control, which is just like a regular HTML INPUT except that when the user types, the characters are replaced on the display with marker glyphs to keep people from reading the password over your shoulder.

When login is done, the login form should be sent via HTTPS. Which encrypts everything, not just the password. And this is in fact 2-way encryption, not just a hash like MD5 is.

On the server, you can convert the decrypted password text to MD5 and use it in a query like "SELECT COUNT(*) FROM USER_PASSWORD WHERE USER = ? AND PASSWORD = ?" and if you get back a non-zero count, the password matches and the user can proceed with login. The fact that the password is in plain text on the server is no real problem, since the server is - we hope - more secure than the client. And the type of SQL query I illustrated means that the database doesn't pull back lots of passwords to the server in case the server gets hacked. Even encrypted/hashed passwords are worth money to Bad People.

However, I should note that writing your own login code is a great way to get hacked in a hurry and so you really should use the JEE standard container security system to manage the login and authorization-checking processes.
 
Kristina Hansen
Ranch Hand
Posts: 66
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Side note (I would like to put this into some sort of spoiler tag, but sadly this forum doesn't support such):
When not using TLS (wich since Let's Encrypt is no reason for) one could use a JS lib wich can handle small RSA keys (last time I checked it worked up to 1024bit). So, when the page is called the server generates a keypair, sends the public to the client and stores the private in the session. When the form is send JS hooks the call and encrypts the password with RSA before actual sending to the server. On the server, the private key is restored from session and the encrypted data are decrypted.
Then, the password gets hashed and stored.
On login, the hashing could be done already on the client so only the hash is transported (same as above a random salt could be added).
But as said: There's no realy reason not to use TLS today, so such homebrew crypto shouldn't be needed.
 
Tim Moores
Saloon Keeper
Posts: 5913
152
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Kristina Hansen wrote:such homebrew crypto shouldn't be needed



I'll go further than that: such homebrew crypto isn't needed and shouldn't be used
 
Tim Holloway
Saloon Keeper
Posts: 21311
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, there are several reasons not to get that creative.

I've had a long and evil career and during that time, I've seen a lot of DIY security systems. A lot of them were in financial systems. Some were military. And probably 95% of them could be broken into in under 15 minutes by unskilled personnel.

And that included the mandatory corporate-wide systems designed but the company's resident genius.

Security is hard. It fails if even one link has the slightest weakness. Even people who are trained specifically in security and working as full-time professionals have seen their hard work broken, and you can extrapolate back from that what I think of systems done by people who were given handling login as just one more (and less-important) part of their git-er-dun-yesterday! project.

The JEE security standard has (so far) never, to my knowledge been cracked. Which is more than I can say for some of the TLS transport protocols.  It was designed by security experts. It volunteers nothing, and it blocks most exploits at the server level, so they can't nibble at bugs in the application - the attacker never gets to the application.

Sending an MD5 hash from client to server is a horrible option because if the hash is going in via http (without TLS), then the hash can be grabbed by anyone sniffing the network path. And, as I said, people will pay even for encrypted passwords. Not only is it possible to reverse-engineer a usable password from a hash (and since it's a hash, multiple passwords may match it), but if the attacker has a back door, they can jam in the hashed password as part of a request of their own and not even ever have to know what the actual password is.
 
Marshal
Posts: 14501
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:

Kristina Hansen wrote:such homebrew crypto shouldn't be needed


I'll go further than that: such homebrew crypto isn't needed and shouldn't be used


Quoting for emphasis. Don't brew your own.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for the reply.  I just added the following code for MD5 encryption and its working.
 
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No it's not. There's so much wrong with that code. I can probably crack your passwords in 15 minutes.

You chose to ignore all the advice given to you in this topic. Instead of writing your own security, you must rely on existing systems. The Servlet specification also includes the storage of user credentials.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What else should i add then?
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do i need to do any changes in the code?
 
Kristina Hansen
Ranch Hand
Posts: 66
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gayathri Gayu wrote:Do i need to do any changes in the code?


At least use SHA-2 instead of MD5.
Also: Add random salt.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is that Random Salt?
 
Kristina Hansen
Ranch Hand
Posts: 66
4
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instead of Should i use ???
 
Kristina Hansen
Ranch Hand
Posts: 66
4
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should get rid of that code and use your web application framework. Presumably you're running your back-end in a servlet container. If you're using an MVC framework like Spring, use their Security API. If not, then use built-in form authentication handlers from the Servlet API.

What are you using on the back-end? JAX-RS, Spring, Java EE, something else?
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No no no. Don't perform any hashing by yourself. Even if for some reason you choose not to use the middleware provided by your application container or web application framework, then use a proper key derivation algorithm like PBKDF2 or bcrypt, NOT hash+salt.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am using jsp and html for views and java code for sending and receiving emails. I have created a dynamic web application in eclipse IDE.
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the requests from your JSP views must end up in some Java class, right? What classes are those, and what framework is routing the requests?

Does your application have a web.xml? If so, show it to us.
 
Kristina Hansen
Ranch Hand
Posts: 66
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:No no no. Don't perform any hashing by yourself. Even if for some reason you choose not to use the middleware provided by your application container or web application framework, then use a proper key derivation algorithm like PBKDF2 or bcrypt, NOT hash+salt.


I guess in this case it should be sufficient to hash the input yourself.
Also: Hash vs Encryption depend on usecase. There's no point in encryption when the credentials just stored and used to compare.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My web.xml has this much code only.


Just for sending successful registration mail I am having java class.
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Kristina Hansen wrote:I guess in this case it should be sufficient to hash the input yourself.


Why? What makes it sufficient?

Also: Hash vs Encryption depend on usecase. There's no point in encryption when the credentials just stored and used to compare.


I don't see how encryption plays any role here. The user wants to access some resource or service using a password.
 
Master Rancher
Posts: 2249
20
Android Java ME Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe no specific framework is being used, it's just a Servlet class, and she just wants to store the password in db in encrypted form.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What should i do now?
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gayathri Gayu wrote:My web.xml has this much code only.


Then is all your code inside the JSP? Please show it to us.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Entire code is in jsp. The above code is for login.
 
Gayathri Gayu
Ranch Foreman
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Should i need any specific frame work. I haven't been using those till now.  Even i don't know how to choose the framework.
 
Stephan van Hulst
Saloon Keeper
Posts: 10873
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are big issues with that code:

  • No separation between presentation layer and business layer.
  • No separation between business layer and persistence layer.
  • Hashing passwords yourself, instead of using a key derivation function.
  • Vulnerable to SQL injection attacks.
  • Not properly disposing resources.

  • What you'll want to do instead is at the very least move your business logic to a Servlet, or even better, a JAX-RS or Spring controller. Make a separate Bean for your database access code.

    If you don't want to use Spring, then set security constraints in your web.xml. Here is the related tutorial: https://javaee.github.io/tutorial/security-webtier001.html

    It seems like you're missing some background in Servlet technology though, so you might first want to go through this: https://javaee.github.io/tutorial/servlets.html
     
    Gayathri Gayu
    Ranch Foreman
    Posts: 317
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Should i use something like this.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 10873
    234
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sure, that looks like a decent enough starting point.
     
    Junilu Lacar
    Marshal
    Posts: 14501
    240
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:There are big issues with that code:

  • No separation between presentation layer and business layer.
  • No separation between business layer and persistence layer.
  • Hashing passwords yourself, instead of using a key derivation function.
  • Vulnerable to SQL injection attacks.
  • Not properly disposing resources.

  • In addition to those objective reasons, here's a more subjective and visceral reason: it's horrific.
     
    Gayathri Gayu
    Ranch Foreman
    Posts: 317
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I tried the example but got the following error.

    SEVERE: Servlet.service() for servlet [RegisterServlet] in context with path [/RegistrationMvc] threw exception
    java.lang.NullPointerException

     
    Swastik Dey
    Master Rancher
    Posts: 2249
    20
    Android Java ME Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Post the code of the corresponding java file.
     
    Gayathri Gayu
    Ranch Foreman
    Posts: 317
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Code
     
    Swastik Dey
    Master Rancher
    Posts: 2249
    20
    Android Java ME Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Its throwing exception in RegisterServlet class not in DAO class.  Post the code of that file.
     
    Gayathri Gayu
    Ranch Foreman
    Posts: 317
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sevlet code

     
    Stephan van Hulst
    Saloon Keeper
    Posts: 10873
    234
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'm assuming you're using the example on this page: https://krazytech.com/programs/java-registration-page-using-servlet-mysql-mvc

    Please post the RegisterServlet code you're using. Also post the entire exception stack trace.
     
    Gayathri Gayu
    Ranch Foreman
    Posts: 317
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The same code i am trying with little modifications. Like I remove the full name and confirm password fields.
     
    Something must be done about this. Let's start by reading this tiny ad:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!