0

See here: https://code.google.com/p/crypto-js

Which one of these encryption methods is best for storing encrypted values in a database? I need some method of encryption that lets the process convert the string back and forth in the same manner every time.

For example: "sadfjpihdsf3njdasf" would convert to "hello world" and "hello world" always converts to "sadfjpihdsf3njdasf". The encryption methods I have tried yet seem to give me a different encrypted string each time.

The purpose of this is mainly to reduce the visibility of passwords stored in a secure database, so the level of security involved is rather basic.

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Joshua Dannemann
  • 2,003
  • 1
  • 14
  • 34
  • 3
    You should never store encrypted passwords in a database. Passwords should be salted and heavily hashed, making them irreversible. – Joe Enos Feb 03 '15 at 21:50
  • So what's the alternative? Store the passwords in an un-encrypted fashion so that any DBA can simply browse through them? – Joshua Dannemann Feb 03 '15 at 21:56
  • Encryption algorithm are written in such a way that they can not be decrypted so that it is secure bcrypt is a good algorithm,And an example javascript implementation is https://code.google.com/p/javascript-bcrypt/ –  Feb 03 '15 at 21:58
  • Thanks Goutam. I did find an algorithm that works for what I need it to do. BTW, none of this stuff is traveling over a public network. All I'm doing as a point a good design is making sure that it's a little more of a pain in the ass for anybody internal to scrape passwords off the authentication system. – Joshua Dannemann Feb 03 '15 at 22:01
  • 1
    @JoshuaDannemann Why not use the accepted formats of salt+Hash (like SHA256?) – George Stocker Feb 03 '15 at 22:02
  • @George I did actually just go that route – Joshua Dannemann Feb 04 '15 at 18:08

2 Answers2

2

All the symmetric ciphers in CryptoJS can be used in the way you described. The reason you see a different value every time is because a new random IV is generated every time. You can generate the IV yourself for every unique value you have as seen here.

Generally, passwords are not encrypted, but iteratively hashed with a salt. So, when the user authenticates the next time, the application can hash the typed in password and check if the values match. The salt and the number of iterations would be stored in additional columns or along side the hash.

CryptoJS provides a good hashing method for this case if you want to do this on the client side or anywhere where JavaScript is runnable, because CryptoJS basically has no dependencies: PBKDF2

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
  • Thanks very useful information there. BTW, I am not using CrypoJS client-side. I am using it in conjunction with a Google Apps script – Joshua Dannemann Feb 04 '15 at 18:10
1

You would want to encrypt information when you are moving it through an insecure channel (WiFi, or data cables that could be sniffed) or if you want to store documents that only a selected group of people should access.

For those applications you should check the cyphers that library provides (and investigate each one to consider their pro/cons).

But for a login implementation there's no a valid reason to be able to decrypt the user password. Nobody should be able to retrieve a password. The standard procedure is to "hash" the password.

Like 'let me eat your password, digest it, and storage what's left'. When the user want to authenticate with your application you do the same procedure with the password he/she provided and compare 'what's left' with what you have in your database.

Read this carefully https://crackstation.net/hashing-security.htm

Sdlion
  • 525
  • 8
  • 18
  • Thanks, that's what I did. I used various encryption techniques for transmission and the most secure for storage. It took a lot of testing to get it just right, but in the end passed a security review with flying colors. – Joshua Dannemann Apr 21 '15 at 03:18