One Man's Opinion
The Philosophy
The following approach is top level and omits many concepts. It is intended only to suggest a more secure approach that sites can use if those sites actually want to protect their user's data.
If everything is only in the clear while a user is logged in, then only those users' data can be hacked The bulk of users, not currently logged in, are protected with good encryption. Also note that each user is encrypted with a unique public/private set of keys.
Any website that supports user accounts must take extraordinary steps to protect that user's data.
One reason, often given to reject this approach, is the need to make the user experience swift and convenient. Another reason to reject this approach is to reduce the per-user cost of doing business.
I am certain there are many other reasons to run an insecure business, but none of them are good reasons. If I were to run such a business, I would insist on the following:
1. The user's login credentials must never be exposed in the clear.
3. No user data should exist in any database unless it is encrypted.
3. The user's wallet must be encrypted and stored separate from the user's other data.
4. No encryption of user data can be briefly allowed only if that the session interaction needs to be livelier.
1. Login Credentials
When a user logs in, even when using two-part security, that user's login credentials must be immediately one-way hashed, and the hash used instead of the login credential parts themselves. Also, if possible, the credentials should be cleared from memory after the hash has been created.
For example, an internal machine (or machines) receives a SHA512 or better hash and returns a public key if successful or an ERROR if it fails. It can also return other information, such as the user's index number.
That machine is populated with a SHA512 or better hashes when an account is created. The web interface collects the login name, a pin, and a password. The pin is computed to yield a number 0 through 9, where that number determines the order of the combination of name, pin and password are hashed. For example, a pin of 555 might modulo 9 yield 6 specifying for example the order of: "pin, password, name."
That hash is passed by the web interface into the internal machine which looks it up and returns a public key if successfully found. If the hash is not found, the internal machine returns an empty string or some other indication of failure.
2. Credentials Must Be Encrypted
Whenever the users data is changed (or a new user is added), that user data is transferred into that same (or a different) machine, which randomly selects a new public/private key pair; associates that new private key with the saved login hash; and returns the encrypted user data for storage in the encrypted-user database.
The key for the encrypted-user database should be an index number, but should never be the login hash, which can be used to fetch a public key to decrypt the encrypted-user data
3. The User's Wallet
The user's wallet (which holds credit card and perhaps bank credentials) must only exist in an encrypted-wallet database. That encryupted data can exist briefly in decrypted form for a purchase or to add or subtract a card or other financial information. This data must only exist in the clear for the briefest interval and only as long as absolutely necessary.
There is an internal machine that receives the wallet data, and the user's ID number. It randomly selects a new public/private key pair, encrypts the wallet with that private key, and returns the encrypted data and the user' ID number on success.
If the web interface needs to use information from the encrypted-wallet, it passes that encrypted data and the user's ID index, and an SQL query to fetch that information. The internal wallet machine (or machines) uses the user's ID to select the appropriate public key, decrypts the wallet into a small one-item database, and runs the SQL query against that one-item database. Upon success, it returns the result of that query. A timeout is enforced. The one-item database is only allowed to exist for a small window of time.
If the web interface needs to update the wallet, it passes the encrypted data and the user's ID, and an SQL UPDATE command. The internal wallet machine (or machines) uses the user's ID to select the appropriate public key, decrypts the wallet into a small one-item database, and runs the SQL UPDATE against that one-item database. On success, the wallet machine randomly selects a new public-private key pair associated with a user ID, re-encrypts the wallet, removes the one-item database, and returns the newly encrypted wallet and the user's ID. The web interface than updates the encrypted-wallet database with this information.
4. No Encryption While User logged in
Instead the user data (except the wallet) is in the clear only for as long as the user remains logged in for swiffer interaction. For this reason only, a site should recommended that users log out, rather than relying on cookies to stay logged in (which can be copied and used by others) unless those cookies are also encrypted.
