Basics of Sign Up and Sign In

[RICH_WEB]

Hi,

 

Sorry if this isn't the right place to post this.

 

I was wondering if anyone would be so kind as to clear up my lack of knowledge about the basics of how the usual sign in and sign up process works?

 

So, say you write a very simple form, where it displays the sign up with just username and password. The person enters their username and password and clicks submit. Then what happens?

 

Does the username and password get sent to the server where the password gets salted and hashed then sent to a database?

 

If so then what happens from when the user enters the username and password for this information to then be used to authenticate the user?

 

Does the script store the username and password in a variable with some instructions to store this information in a database after the password has been salted and hashed? Then when the person uses the sign in and clicks to submit the username and password this is sent to the server checked that the info is correct then the user is sent the appropriate webpage?

[justsomeguy]

More or less, yeah. When someone logs in it will take the password they typed in, hash it the same way as the one saved in the database, and then compare the hashes to see if it's the same password.

[john_jack]

for the signup :

usualy theres a basic html form that sends the data to a server side script Php for eg.the php file checks the validity of the data sent via the form if everything is ok you insert the data in a database for eg "a table called user" via SQL query .

 

check this http://www.w3schools.com/Php/php_forms.asp

 

for the sign in :

 

a basic html for login and password once submited transmits the data to a php file that checks if the user is registred in the database if its ok you redirect him to a page of your choice . you will have to use sessions http://www.w3schools.com/php/php_sessions.asp to keep track of the user and what he can access or not

[davej]

If so then what happens from when the user enters the username and password for this information to then be used to authenticate the user?

 

A key part of the login process is the assignment of a session cookie which identifies the user once the login is deemed successful.

[RICH_WEB]

At the sign in page is the password hashed and salted in the browser(client side - is this the right term)? Then passed up to the server and checked against the database? If so is there a more secure way so that password hashing and salting is done on the server? Can the password be hashed and salted at the client side then salted again server side to then be passed on to and checked against the database?

[Ingolme]

No, hashing is not ever done on the client.

[davej]

To me it seems like a bad design, but that is the way things work. The client posts the username and password to the server and the server does everything related to security. To actually protect the login process you really need to use HTTPS.

[RICH_WEB]

Is the password salted client side?

[davej]

Everything related to security is normally done on the server. I myself think that is a little short-sighted, but that is what is done.

[Ingolme]

It's done on the server because the client's device may not implement the proper hashing algorithms. Also, a person could bypass any attempted client-side hashing if it's done with Javascript. If implemented poorly, client-side hashing is hardly different than using plain text passwords, because the listener does not even need to know the original password, they just need to send the result of the hashed string.

[davej]

I think HTML5 should have offered something to fix this situation. What we have now is a complete reliance on HTTPS certification.

[Ingolme]

I think HTML5 should have offered something to fix this situation. What we have now is a complete reliance on HTTPS certification.

People can build their own browsers to bypass any HTML 5 security features.

[davej]

Well, it's true that hackers are always writing new tools, and yes they can write browser plug-ins or entire browsers, but I think there are things that could be built into the standards for browsers that could improve password and session security for non-HTTPS websites (which is the majority of websites). For example a "man-in-the-middle" attacker can overcome public-key cryptography if he is already inserted during the initial meeting, but once I have used a website it can remember my public key and I can remember its public key and any possible "man-in-the-middle" is rendered harmless.