• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Encryption of Passwords

 
Ranch Hand
Posts: 162
1
Android Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Everyone

Problem Statement : I would like to store "Encrypted" passwords inside "MySQL" database. I would like to know the best Practice and best method to do that .
Moreover, where should the encryption be done i.e should it be performed in Service Layer, Dao Layer or inside Database ( by using methods provided by MySql) or in both places.

I would also like to know which method does BANKS uses in storing passwords for our credit cards ??


Looking Forward to hear awesome replies !!!

Thanks and Warm Regards
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not familiar with credit cards that come with passwords (never heard of that, in fact), so I can't speculate on how that works.

The normal approach to storing passwords is not to encrypt it, but to hash it (or digest it), so that it can never be retrieved as cleartext (and thus can't be stolen). The SHA-2 hash algorithm is the current standard for that; if you use Java's JCE API it would be called SHA-512, which is the strongest SHA-2 variant.

This would normally be done in the app, not in the DB, although that is a possibility.
 
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also have a look at OWASP password storage guidelines. OWASP is an excellent site for all kinds of web security guidelines.

Which layer?
Password restrictions, forgot password handling, etc are all responbilities of the business logic. The UI too needs to know character and length restrictions. So I handle all these in the Service Layer.
In my opinion, they don't belong in the data layer; that layer should be only for dumb storage and retrieval operations.

Separate user details
One good practice I've not seen mentioned anywhere - not even on OWASP - is to keep the credentials separated from other user details (like email addresses). Perhaps in separate databases, or atleast in separate tables with different authorizations.
If you've read news reports of large website hackings, the spokespersons invariably claim something like "<x> million passwords/hashes were compromised, but no other user details were compromised".
I become skeptical everytime I read that, because just about every CRUD webapp out there starts off with a "User" class which has all details, and a UserDao class which stores it all along with the user salt and hash in the _same_ USERS table.
So how "no other details were compromised" is beyond me. Nevertheless, I hope it's true and I think it's a good practice if true.

Complementary operations
Depending on the scale of your website, in addition to core authentication, you may also have to think about complementary operations which are common to any web app. For example, periodic database backups may inadvertently leak credentials if backup hard disks /tapes are not physically secured, or are thrown or sold away without wiping/destroying them.

Negligent or rogue internal employees like sysadmins or developers may access the credential database and damage or steal it. So strict database and table level authorizations are required. All database access attempts should be logged, and this log itself should be secured to prevent anybody covering their tracks.

So, there are many aspects to it than just password storage.

Banks
As for banks, they are governed by PCI DSS rules, and possibly additional rules of the country specific banking regulator. In practice, they (try to) follow all the best practices documented in OWASP - not just related to password storage but also authentication and authorization in general. For example, multi factor authentication. Whatever they implement should finally be certified by the PCI DSS process.
That said, my bank (a reputed international one at that) restricts passwords to 16 characters and does not accept special characters! So be skeptical about using banking systems as a role model.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic