-2

In one of my applications, I am to store user credentials and tokens. As the credentials are used directly on third-party services, I cannot hash them and thus need to store them as-is.

As I am not an expert on encryption, I googled and found that AES 256-bit key size-is a good idea to encrypt such data.

I would like to know the opinion of the SO community on the same, before I make a final decision.

Thanks!

Edit: Thanks to all for discussion, I am moving ahead using AES256 as the encryption mechanism for now, which seems like a good choice.

sangupta
  • 2,336
  • 3
  • 22
  • 36
  • Why do you bother encrypting the user credentials? If they are used in unencrypted form on third-party system, the encryption is unlikely to improve the system's security. – Codo Jul 13 '12 at 05:46
  • 1
    I agree but the credentials are sent over HTTPS and thus are somewhat secure. Either I ask the users to enter the credentials every-time (in session) when we make a call, or just store them. We don't want our system to be the compromising module in terms of module and thus the need to store them. Also, we have some sensitive-data (such as authentication tokens) that need to be securely stored. – sangupta Jul 13 '12 at 06:05
  • this question has been answered several times before on stackoverflow – Jacco Jul 13 '12 at 11:27
  • @Jacco - I have read many a threads but they all seem to be over two years old (like http://stackoverflow.com/questions/992019/java-256-bit-aes-password-based-encryption from 2009). Just wanted to know if something better has come up, for sensitive data like passwords. – sangupta Jul 13 '12 at 15:05
  • 1
    @sangupta, in security and crypthography, 'several years old' is the best you can get. Anything newear has not had enough scrutiny from the community. – Jacco Jul 13 '12 at 15:10
  • 1
    @Jacco, so true, and yet that scrutiny hadn't happened yet in 2009, hence the wisdom of checking again with the gurus for updates. – tbroberg Jul 13 '12 at 20:46
  • Mr. Downvoter - would you please care to explain? – sangupta Jul 14 '12 at 05:35
  • @sangupta first of all, this is not directly a programming question, you are asking which protocol to use for a security design. Furthermore, your question has been asked oodles of times. Unfortunately the algorithm is the last thing you need to worry about, you need a secure system, not just a secure algorithm. Key management, encryption mode, roles in the organization, backups, system setup etc. etc. . This question indicates you are probably not the right person to (make a scheme to) store other people's passwords (but at least you asked). – Maarten Bodewes Jul 15 '12 at 21:22
  • @owlstead Sir, may I know how this is not a programming questions - just because I didn't post or ask for any code snippet? I don't think StackOverflow is just for that. Second, I already have mentioned taking a look at the previous questions posted in StackOverflow but they are over 2-3 years old. With technology space changing at a rapid pace, why do you think is a bad idea to double check again with gurus. Suppose one asked about switch statements in Java using strings - the answer would have been different than pre JDK-7 era and now. Will you still say that it had been asked many a times? – sangupta Jul 16 '12 at 04:26
  • @owlstead Fourth, I think algorithm is much more important than the things you have mentioned. Recent, yahoo/linkedin leaks were more because of poor algorithm and not because of system/backup/process failure. Lastly, Sir, yes I am not the right person, for I posted a to-the point question. Just because I didn't mention about the security process of organization, backups, systems setup - does it make me less informed. May be I had already read and designed around that and may be that's the reason I didn't mention it. – sangupta Jul 16 '12 at 04:29

1 Answers1

0

if you ask user for credential every time, then why do you need to store them in db? just keep it in memory and pass to external system. you can even ask user once and keep their password in memory for the whole session. if, for some reason you have to store them in db, them of course encrypt it. as far as i know, current standard is AES256. but still somewhere you have to keep unencrypted key. to sum up: if you want to authenticate users and then use their password only for the time of session then you don't have to store it in database. keep salted hash for authentication purpose and keep user provided password in session for external systems

btw. is your swap encrypted?

piotrek
  • 12,111
  • 8
  • 63
  • 144
  • As I mentioned, asking the users everytime for credentials is something we want to avoid. The swap is encrypted over HTTPS. – sangupta Jul 14 '12 at 05:32
  • 1. so when a client connects to your application how do you know it is client A and not a client B? how do you know it without asking for credentials? 2. HTTPS is not used to encrypt swap. swap is an image of your RAM stored on a hard disk by your OS – piotrek Jul 14 '12 at 09:42
  • We use LDAP for user authentication - these credentials we need to store are for a third-party service. Thus, every user stores them at setup whereon we use them to pull/push data based on user-workflows. Sorry about the SWAP piece. The password will only be decoded for the part it is sent, and then the memory cleared. Other sensitive data in RAM will be encrypted using a randomly generated UUID (at each server startup). – sangupta Jul 16 '12 at 04:41