Storing server generated passwords

Question

There are some applications that generate passwords for you. Consider a case where you sign in via Facebook, the application (let's call it NEWAPP) verifies your sign in on the server using FB tokens and FB verify APIs and then creates a user account for you. NEWAPP would then send over these credentials over an HTTPS(TLS) connection so that you could update NEWAPP OAuth tokens when required.

Question: Given that the server generates credentials & sends these over to the user every time they log in via FB, how is it supposed to store these credentials securely on the server side?

Constraints:

1. User may log in on a different device using the same FB account. The same credentials (username & password) must be handed over to the user.

2. User may log in through multiple devices at the same time using the same FB account.

3. The user themselves have no clue of the username & password for the NEWAPP service; these are sent over by the NEWAPP servers when the user logs in via FB.

Answer 1

The inherent risk in passwords are that users are bad at choosing good passwords, and tend to reuse passwords. In a scenario like this, it sounds like your system generated password is never sent to the user. You do not control their password on the facebook side. You just care about authenticating with the Facebook system. Your risks are significantly lower, unless you share your system generated password with the user, at which point all bets are off.

Following good security practices, you should still hash the passwords (never store them in clear text, unless there are valid technical reasons for you not to do so, or provided you have some other compensating controls in place to protect those passwords), and change them regularly. You should have a mechanism to generate fresh tokens with Facebook, so maybe schedule a process to do it automatically every 30 days or so...

Answer 2

An interesting question, here is how I would approach this issue (please note, all these steps are theoretical).

NEWAPP, as you describe it, is not a form of a website, but an APP, therefore I will assume you have code execution on the client host and have access to hardware id of the device.

The complexity, and usability will depend on the security involved, and such a design might seem as not overly user friendly. The basic idea is to use hardware id (string unique to each device) as a seed to generating a public+private keypair, and store it on the client device. The verification of identity of the user is performed by signing messages between client and server with a correct key.

There are 3 basic scenarios to usage of such a design:

1. User creates an account, and his device generates the key pair and sends off the public key to the server, together with the initial hardware id. The server generates a username by hashing the public key with hardware id as salt. This username is sent to the client and stored locally.
2. User adds a new device to the authorized list, and verifies his identity and ownership of the account via a side-channel, be it email, sms, request from in-app. For example, the user enters an email address associated with the account, and receives an email with a unique string generated by the server. The user copies this string into NEWAPP, which identifies him, and a process similar to creating a new account is initiated (the new public key adds a new key, without removing the old one).
3. A user logs in from an authorized device, the server and client use PKI to transmit and sign several random messages to verify the identity of the client, and the user is authenticated.

This way, the client would only be able to login once his device is authenticated, and no password would be needed. You could even allow for improved security, and let clients use a passphrase for their key pair.

This design is vulnerable to stealing of hardware id or keys by malware, but that is a whole different story.