State of the art authentification

buzz

Hey there!

First of all, my english isn't that good cause i'm german. So sorry for wrong spelling or wrong grammar :-)

I just want to now from anybody of the specialists what contents a "state of the art" authentification has to have. Simple question you see :-) .

I'm coding a site where users have to pay for special kind of information and therefore i need a authentification method which is secure and does have not so many holes. It must not be as secure as sites like ebay (are they really secure :-) ) or government pages. But it has to be secure enough to let most of the normal guys out and doesn't allow these script kiddys to bust my page.
At this point i use a normal user/passwort page to create a session with an array. In this array the username and the user id is stored. Every page which needs the user to be authentificated checks for existens of these session array, gets the user id and does a check if the user is allowed to view the page.

So what more to i have to do?

Is it possible to sneak the session to get the user id? Why is it better to store the user details (personal details) in a different database (read this in another thread)? What are the things i must pay attention on like addslashes when getting the username/password strings (because of knowing that somebody has entered a username/password with some funny sql strings in to kill my database)? Is it better to build a javascript onto the login page to assemble/transfer a crypted password string like a md5 hash of the username/password and for example a hidden unique id placed in a hidden field on the page? What is about security when somebody has cookies disabled and i have to transfer the session id coded in the url? Is that another security hole?

Anybody out there can tell me what is a "must do" and what is a "can do" and what i have to look for like addslashes?

I would love to have some comments.

Weedpacket

Some guidelines on the subject have been published by OWASP. A link can be found here and a PHP-specific version here.

Is it possible to sneak the session to get the user id?

If you mean session fixation, that is mentioned in PHP's manual on the [man]session[/man] page (external link, there).

buzz

Thanx Weedpacket for your reply.

session fixation
I already read about session fixation. Therefore my login page shows up twice. At first time it only deletes the current session id, creates a new on and redirects back to the login page with a newly created session id. So any previous create session id, maybe from any suspicious guys, is gone. I think that this will fix this problem. Am i right?

Do you have an answer conserning

why should i save user details and user login parameters in different dbs?
is there more to do than addslashes to check incoming maybe faulty username/passwords to be sure no funny sql strings a part of the username?

I wrote a class for this kinda stuff. All the params, i get by a http_get like ?showUserDetails (a param which enables or disables showing user details as the name says) are "registered" by my class. They are defined as (in this case) POS0 what means that only positiv integer values an 0 are allowed in this var. When anything else is in this var it is set to a default value. Second every var has an array attached where all valid values are stored. So, for example, i have a var which is named cmd which tells the script what to do. If any other "cmd" is coming from the user, which is not stored in the "this values are valid" - array the var cmd is set back to the default value which, in this case, is "none". So i think i can rely on my vars.

What about a javascript on the login page which crypts the password and sends this crypted password instead a plain password. Is it a "must have"?

Hope you have an answer for this questions too?!

rehfeld

im no expert on this, but ill try to help as best as i can

- why should i save user details and user login parameters in different dbs?

as far as i know its just to minimize the the chance of an sql injection being able to mess with the login info. you will prob use other other tables and dbs fairly often for other things, and each time you run a query with user input in it, there is a risk involved. having it in a sep db helps/ prevents? them from getting info out of it if they successfully were to exploit other queries in your application because they wouldnt be able to access data in the other database. well, at least it would be harder for them.

is there more to do than addslashes to check incoming maybe faulty username/passwords to be sure no funny sql strings a part of the username?

definately. for starters use mysql_real_escape_string()

still, i think its also a good idea to validate the data before using it. for example, if password or username etc... can only be letters and numbers or whatever, check and make sure before running the query. also, you may wanna check the length of input too. if a password can only be 20 chars long, dont even try it if its longer.

- What about a javascript on the login page which crypts the password and sends this crypted password instead a plain password. Is it a "must have"?

i would choose ssl over it, but its not a bad idea. you could do both if you want. i implemeneted a login system where the server would generate a random seed that was sent to client for each login attempt. that seed was used to make a hash of the password before sending it back to the server.

you may also want to implement something to help thwart bute force attacks. like for example, each time someone attempts to login, update a database with a timestamp of the last login attempt. only allow 1 login attempt every 5 seconds or so. or just use a 5 strikes your out system where if a given username has incorrectly attempted login more than 5 times, the account is locked temporarily.

buzz

Thanx for your answer!!

as far as i know its just to minimize the the chance of an sql injection being able to mess with the login info. you will prob use other other tables and dbs fairly often for other things, and each time you run a query with user input in it, there is a risk involved. having it in a sep db helps/ prevents? them from getting info out of it if they successfully were to exploit other queries in your application because they wouldnt be able to access data in the other database. well, at least it would be harder for them.

Makes sense to me.

But think about that. I get the username, coming from the login form, and take only the part from the beginning to the first space or, if theres no space, to the end. So is it, in my case, really possible to get a sql command hidden in the username? If the username is "delete * from ....", my internal username is "delete" and cant cause any damage. Or am i totaly wrong?`

At this point just the question about my english. As i said in the start of my question, i'm german. Is it ok to read my english or is it totally crazy?

definately. for starters use mysql_real_escape_string()

Another one that makes sense looking at the manual! You've got 2 out of 2! :-) Thank you!

I do already check the username and password. Max length for both 16 characters and, as meantioned above, i take only the part to the first space character or the end.

i would choose ssl over it

Sure but i read that it is so expensive, isn't it?

i implemeneted a login system where the server would generate a random seed that was sent to client for each login attempt. that seed was used to make a hash of the password before sending it back to the server.

This is exactly what i mean. But who does the hash on the client side? I think only javascript or something simular can do that. So what if i'm the user which disables javascript? I can't login. Or is there another way to do that on client side?

Hopefully i don't bother you with all my question!

bute force attacks

I don't thought of that before. Very good idea. I'll do that, thanx!

I hope i'll get another answer from you to my question.

Thank you until now!

rehfeld

your english is very good, i didnt even notice it wasnt your primary language until you mentioned it.

But think about that. I get the username, coming from the login form, and take only the part from the beginning to the first space or, if theres no space, to the end. So is it, in my case, really possible to get a sql command hidden in the username? If the username is "delete * from ....", my internal username is "delete" and cant cause any damage. Or am i totaly wrong?`

sounds solid, but that doesnt mean both of us have considered all possibilties. knowing this, is why i would prob not even exeute the query at all if i found characters that werent allowed.

i would recomend reading up on sql injection to see as many examples of exploits as possible. it may open your eyes to things you did not consider before. heres a few
http://www.php.net/manual/en/security.database.sql-injection.php

Sure but i read that it is so expensive, isn't it?

not really. i think you can get certificates starting at $30 a year. if you want something from verisign for example, its going to be major $$$ though. but alot of it is just brand awareness. most customers feel secure when they see a verisign logo.

some of the cheaper certificates may cause a promp in the users browser if the browser isnt familiar with the issue i beleive. the more expensive ones will not have that problem, but it doesnt have any affect on security as far as i know. but thats a seperate topic that you could read up on.

This is exactly what i mean. But who does the hash on the client side? I think only javascript or something simular can do that. So what if i'm the user which disables javascript? I can't login. Or is there another way to do that on client side?

it used javascript. yeah, a small percentage of users would not be able to log in if js was dissabled. you can always use <noscript> tags to tell them they need to enable it. ssl doesnt have this problem though.

one other thing you need to consider, is shared hosting security if your not on your own server. the dangers are very real, and can be quite serious. most shared hosting leaves you wide open.