I assume that when a user registers at a site, the password and username are stored inside of a database.

I've read that the password is often encrypted using a salt. So, is it safe to encrypt the passwords with a salt and to save it in the same schema with the username?

Secondly, how does authentication work? Companies like Google have giant databases of username/password pairs. How does validation work so quickly, and how is it implemented?

  • 3
    This is two or three questions, I think you would be more likely to get a good answer if you split the questions up into different posts.
    – Encaitar
    Mar 17 '14 at 17:48
  • 2
    Passwords should not be encrypted or they could be decrypted when they fall into the wrong hands. Instead, they should be irreversibly scrambled with a secure hash function. During authentication, the user provides username+password. The scrambled password (which contains a salt) for that username is looked up in the DB, then the provided password is scrambled with that same salt. If the two scrambled passwords match, it was correct and the user has been authenticated.
    – amon
    Mar 17 '14 at 17:48

This question has some faulty assumptions, I'll try and clear these up first:

Salts are not used as input to encryption but as input to one-way functions such as hashes.

Some sites may store databases of passwords, which is how they can be hacked and their users passwords stolen, but you should NOT do this. General practice is to store hashes of passwords (and salts, see above) and when a user tried to log in, hash their provided password and compare the hashes.

[Google does everything quickly. I don't know if they do map / reduce for authentication but they have a lot of smart people working on it, maybe this should be a separate question.]

So salted hashes are then stored somewhere on the server. In terms of security I don't think it makes any difference whether you store them in a file, a relational database or in a NOSQL database. For speed at 'web scale' then you probably want to have a look at NOSQL databases and caching the data rather than using IO to disk.

  • But the hashes of the passwords, are stored inside of a database, correct? I've read that some sites store passwords in a plain text (kinda dumb), but what are the advantages of storing them in a text document over a database? Mar 17 '14 at 17:58

There are many ways, but the basic one is called challenge-response.

This is where the user's password is never sent to the server, but is encrypted instead (using a hash algorithm). The hash is sent to the server, usually over an encrypted channel and saved for later.

When the user wants to login, he sends a login request, the server then encrypts a message of some sort (the challenge) and also generates the correct response (ie encrypts the challenge using the stored hash). The challenge is sent to the client who calculates what the response should be (by taking the user's password and re-generating the hash from the password). The client sends this encrypted response to the server who compares it to the pre-calcuated correct answer. If they match, the client must have the correct password in order to generate the correct response, and you let him have access.

The good part is that the password never gets sent to the server, except during the initial account creation stage, and even then its sent as a hash.


Passwords are encrypted in a repeatable one-way fashion. They are then stored in a file, database, or whatever as a [user]-> [encrypted password] pair.

When the user logs in, they enter a username and password. The website or application may retrieve the stored encrypted password that matches that username before the user even enters their password, (via ajax or other asynchronous methods as soon as they switch fields from the username field to the password field). This saves time, but the application still has to encrypt the password string entered by the user so that it can be compared with the encrypted version that is stored.

  • StackExchange answers are ranked according to the votes that other users cast upon them. Therefore directional comments such as "as mentioned above" are not appropriate.
    – Encaitar
    Mar 17 '14 at 18:52

Generally speaking, huge corporations don't store the users in a database. They have an identity management system with the following structure (for sure it may vary from company to company but I think this is going to give you an idea):

  1. Securized Person Directory (openLDAP, Active Directory, Oracle Identity Manager, ...)

    They store here everything related to persons, name, mail, username, password (encrypted), etc... (there are many schemes to use). It's used for autentication only. Not accesible from the outside.

  2. Authorization system (Kerberos for example)

    Once you've logged in correctly, you need a system that give you access to the resource you're allowed to, this is done generating a session-ticket (valid only for a period of time). This ticket tells your application if you have access to which parts of it (The common way to organize this is with groups -> roles -> application permissions).

  3. Single sign-on system.

    Once you've logged in and you've got your ticket that grants you access to several resources within an organization, you can store it locally in your machine (for example with a Cookie) so that you don't have to give your username/password again and again when try to access other resource you've access to with the ticket (if your ticket expiry time have not expired yet).

Obviously this can be as complicated as you want, and you can develop this solutions ad-hoc for your company/project but this is the general idea behind.

When you develop a webapp for example, the best approach is to develop an authentication provider layer which can manage this kind of login/authorization systems as well as the simpler one username/password in a database.

Not the answer you're looking for? Browse other questions tagged or ask your own question.