Jump to content

Basics of Sign Up and Sign In


RICH_WEB
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...