4

I provide a service in which users can store data, files, etc in an encrypted form. The service that I have built has two applications for the user's password with which they login to my service: 1) authentication and 2) the password is used as the base for the secret encryption key for data they store with my service.

I am integrating with another service whose users need to be able to access my service via SSO, either OAuth2, SAML or some other standard. The obvious problem is that the user's password is eliminated and thus cannot be used as a secret key.

A few questions:

Can the user's password from the parent service be passed to my application allowing for it to be used as the secret key for encryption?

If a secret is randomly generated when the user registers for my service via SSO, can this be stored anywhere securely?

Currently my service employs AES-256 symmetrical encryption. Is there a better encryption scheme for my use case?

Any ideas for a string other than the user's password that could be used as a secret key?

user138172
  • 63
  • 3
  • The huge problem with using the password are people who forget it. At that point you lose their encrypted data! Bye bye! (i.e. if you want to offer a _"Forgot Password"_ feature, you can't use the password to encrypt the user's data.) – Alexis Wilke Feb 08 '19 at 17:54

2 Answers2

2

Can the user's password from the parent service be passed to my application allowing for it to be used as the secret key for encryption?

No. That is sort of the point of the protocol.

If a secret is randomly generated when the user registers for my service via SSO, can this be stored anywhere securely?

Secure from whom? I'm guessing that your system was designed so that even you couldn't decrypt someone's private files. If that is the case, then no, there is nowhere you can store it where you can't also get it, unless you pass it to the end user and ask them to store it.

Currently my service employs AES-256 symmetrical encryption. Is there a better encryption scheme for my use case?

Even AES128 is plenty strong. Without knowing more about your system, it's hard for me to say whether it would benefit from some aspect that uses a public/private key.

Any ideas for a string other than the user's password that could be used as a secret key?

If it were me I wouldn't want you to use my password (which is pretty short). I would want to be able to type an arbitrarily long passphrase into a large, multi-line textbox. I would probably paste in a couple pages from a book I like, which makes it easy for me to recover.

You could also randomly generate a value and save it as a cookie or file for the end user to keep.

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • Why would it need to be from pages of a book **I like**? – Alexis Wilke Feb 08 '19 at 17:52
  • The cookie idea is not so good: (1) some people have cookies turned off (they probably can't even create an account so we're probably good...); (2) the cookie may be deleted by the browser; (3) if you go to the website from another browser or device, it's not going to work too well either. – Alexis Wilke Feb 08 '19 at 17:55
  • @AlexisWilke - I suppose it doesn't matter if you liked the book, but presumably this works best with a book you actually own or at least have access to on demand. – Mike McManus Aug 26 '20 at 16:53
0

Depending on the authentication service you are using, you could ensure that a secret is returned from the SSO as part of the handshake, and utilise this. This then transfers the problem to the system doing the authentication.

Receiving the password via SSO is out of the question, the whole point of it is to abstract away the storing of credentials.

AES256 is almost certainly fine for what you are doing.

LTPCGO
  • 965
  • 1
  • 5
  • 22