secure login form

[Harris Kosmidhs]

Hello,

while I'm developing sites for some time I never coded a login form with
security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

Then, if I'm permitted by the server admin I want to use https. Is it as
simple as puting the login form in the httpdocs of the https server an
when login is successful then I just set a session variable? Will I then
be able to read this from a page under http?

Thanks in advance.

[Erwin Moller]

Harris Kosmidhs schreef:

Hello,

Hi,

>
while I'm developing sites for some time I never coded a login form with
security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

What is it you want to protect against excactly?
If you want the avoid the man-in-the-middle eavesdropping on you: Then
you need https, as you described.

If you are afraid the username/password you store in your database is
hacked somehow, then it can make sense to store them with an md5 hash,
which is one-way encryption indeed.
So that means you, as admin of the database, cannot tell what the
password is since you only see the md5 hash.
You can check of course if a provided password 'translates' to the
stored md5.

Personally, I stopped storing my passwords with a md5 hash in database.
I figured that if somebody can enter my database at will, my site is
hopelessly cracked beyound repair anyway. ;-)

>
Then, if I'm permitted by the server admin I want to use https. Is it as
simple as puting the login form in the httpdocs of the https server an
when login is successful then I just set a session variable? Will I then
be able to read this from a page under http?

You have NO shared session between you http and https pages.
So if you need that, you must build that yourself somehow.
(You can propagate the sessionid from http to https via a form, and let
the receiving script use that sessionid for its https session. But be
carefull and always remember that your client can set ANY value for
PHPSESSID easily). Always try to hack your own site with all the
knowledge you have about its internals.

Besides that, you also might consider getting a security audit.

>
Thanks in advance.

Good luck.

Regards,
Erwin Moller

[Dikkie Dik]

Harris Kosmidhs wrote:

Hello,

while I'm developing sites for some time I never coded a login form with
security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

Yes. It certainly does not hurt. Better "salt" your hashes (by appending
a known, self chosen string to it). I can check for md5('password'), but
it is harder to check for md5('SiteNamepassword') if I do not know that
'SiteName' is the salt of your hash. Also note that hashes are not
necessarily different for different passwords. So the password field in
the database must not be unique if you use hashes. But it must not be
unique anyway.
But this is mainly database security. If your PHP site calculates the
hashes, the password is already sent over the big bad internet to your
server. That is where https comes in.

>
Then, if I'm permitted by the server admin I want to use https. Is it as
simple as puting the login form in the httpdocs of the https server an
when login is successful then I just set a session variable? Will I then
be able to read this from a page under http?

These are great questions to system administrators. You will need a
separate IP address for each https site, but you can run "normal" http
on the same IP address. So if you just have one site, one address will
do. In the web server, you 'll have to configure another directory that
becomes the root of the https site. Just see it as a separate site. You
can, however, define symlinks to parts the regular site. This can be
useful for sharing directories like CSS, images, etc. that contain
static content and are also needed in the https site.

One note of care: if you use cookie-based sessions (meaning that the
session ID is in a cookie), you can mark your cookies as secure. This
will prevent browsers from sending them to the non-secure part. Off
course, the PHP manual has some nice info on the matter as well. See,
for instance, session_destroy and session_regenerate_id. Read especially
the last one. A net search for "session fixation" and "session
hijacking" also gives some valuable insight.

Best regards

[Captain Paralytic]

On 5 Jun, 15:10, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:

If you are afraid the username/password you store in your database is
hacked somehow, then it can make sense to store them with an md5 hash,
which is one-way encryption indeed.
So that means you, as admin of the database, cannot tell what the
password is since you only see the md5 hash.

A salt is required here. There are md5 lookup dictionaries on the web
that will give you the "trivial" password that led to a particular md5
hash.

Trivial includes peoples names and lots of other commonly used
passwords. The salt can be stored with the md5 hash, it still stops
the reverse md5 process from being successful.

[Harris Kosmidhs]

Erwin Moller wrote:

Harris Kosmidhs schreef:

>Hello,

Hi,

>>
while I'm developing sites for some time I never coded a login form
with security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

What is it you want to protect against excactly?
If you want the avoid the man-in-the-middle eavesdropping on you: Then
you need https, as you described.

If you are afraid the username/password you store in your database is
hacked somehow, then it can make sense to store them with an md5 hash,
which is one-way encryption indeed.
So that means you, as admin of the database, cannot tell what the
password is since you only see the md5 hash.
You can check of course if a provided password 'translates' to the
stored md5.

Personally, I stopped storing my passwords with a md5 hash in database.
I figured that if somebody can enter my database at will, my site is
hopelessly cracked beyound repair anyway. ;-)

And what's your approach now? Clean passwords as text db fields?

>

>>
Then, if I'm permitted by the server admin I want to use https. Is it
as simple as puting the login form in the httpdocs of the https server
an when login is successful then I just set a session variable? Will I
then be able to read this from a page under http?

You have NO shared session between you http and https pages.
So if you need that, you must build that yourself somehow.
(You can propagate the sessionid from http to https via a form, and let
the receiving script use that sessionid for its https session. But be
carefull and always remember that your client can set ANY value for
PHPSESSID easily). Always try to hack your own site with all the
knowledge you have about its internals.

What should look like what I have to build? Let's say you press "log
in". It load the (https) login.php which finds out you are a user. Then?
A header('http://example.org/loginnext.php?id=$userid') ??
Is there a way not to pass id with GET but with POST without user
submitting the form himself?

thanks

[Erwin Moller]

Harris Kosmidhs schreef:

Erwin Moller wrote:

>Harris Kosmidhs schreef:

>>Hello,

Hi,

>>>
while I'm developing sites for some time I never coded a login form
with security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

What is it you want to protect against excactly?
If you want the avoid the man-in-the-middle eavesdropping on you: Then
you need https, as you described.

If you are afraid the username/password you store in your database is
hacked somehow, then it can make sense to store them with an md5 hash,
which is one-way encryption indeed.
So that means you, as admin of the database, cannot tell what the
password is since you only see the md5 hash.
You can check of course if a provided password 'translates' to the
stored md5.

Personally, I stopped storing my passwords with a md5 hash in database.
I figured that if somebody can enter my database at will, my site is
hopelessly cracked beyound repair anyway. ;-)

And what's your approach now? Clean passwords as text db fields?

Yes.

>

>>

>>>
Then, if I'm permitted by the server admin I want to use https. Is it
as simple as puting the login form in the httpdocs of the https
server an when login is successful then I just set a session
variable? Will I then be able to read this from a page under http?

You have NO shared session between you http and https pages.
So if you need that, you must build that yourself somehow.
(You can propagate the sessionid from http to https via a form, and
let the receiving script use that sessionid for its https session. But
be carefull and always remember that your client can set ANY value for
PHPSESSID easily). Always try to hack your own site with all the
knowledge you have about its internals.

What should look like what I have to build? Let's say you press "log
in". It load the (https) login.php which finds out you are a user. Then?
A header('http://example.org/loginnext.php?id=$userid') ??
Is there a way not to pass id with GET but with POST without user
submitting the form himself?

Well, I was assuming that both the http-domain AND the https domain were
on the same server.
If that is not the case, things will get more complicated, because
you'll have to build a system that uses a common session-storage for
different machines (using a database instead of serialized
session-array, which is default).

The important thing is (when using a common sessionstorageplace) to pass
around the sessionid.
eg, from http to https:
<form action="https://www.example.com/myhttps.php" method="post">
<input type="hidden" name="httpsessid" value="GJHGA577FKJ98FGKJ3">
<input type="submit">
</form>

From www.example.com/myhttps.php you can now pick up the passed
httpsessid from $_POST["httpsessid"] and use that one to pick up the
session under that name.

There are a lot of ins and outs, depending on your serverconfig, so be
sure you test everything you try.

I would advise you to first read through the relevant pages on php.net
so you have a firm understanding of how sessions work before building this.
Be sure how to name a session (PHPSESSID), how to overrule a name, when
sesisons are autostarted, etc etc.

Good luck.

Regards,
Erwin Moller

>
thanks

[C. (http://symcbean.blogspot.com/)]

On Jun 5, 2:15 pm, Harris Kosmidhs <[e-mail]>
wrote:

Hello,

while I'm developing sites for some time I never coded a login form with
security in mind.

I was wondering what guidelines there are.

For my point of view I'm thinking of using md5 passwords (it's an one
way function right?) in db. Is this a correct approach?

Then, if I'm permitted by the server admin I want to use https. Is it as
simple as puting the login form in the httpdocs of the https server an
when login is successful then I just set a session variable? Will I then
be able to read this from a page under http?

Thanks in advance.

sha1 is a stronger hash than md5, and actually runs faster in PHP -
but does require more storage - the intrinsic strength of the hash is
not nearly as important as **using a good salt**.

There's limited benefit in protecting the password very well, but the
session identifier (which could easily be sniffed from the http
exchanges). Also you should read up on session hijacking - regenerate
the session ID on a successful login.

C.

[larry]

Storing MD5s instead of the actual passwords in the DB is a good idea,
you get user input (maybe add something), MD5 it and then compare it
to the db record.

HTTPS can be complex if you have the pages in seperate locations
(depends on server config), prbably an auto generated key base on tine
would be a good method to bridge between the locations, or just put a
redirect on the unsecure side to a secure login. If SSL it can be
both on the same place you can also do a check to see if SSL is being
used and restrict users who are not using it. (google for it)

---------------------------------

I was working on a better logins myself, I figured I could do it this
way:

1. user goes to site's index.php with a preset key http://mysite.com/index.php?pw=pass
- if index.php validates the password, it sets ap a session variable
that it has 'passed'. Now, regardless of pass or fail it still
redirects to the login.

3. Login operates as normal but will not even try to validate without
the session being set. After x number of failed attempts (recorded by
another session variable) it redirects to another (lame) page. Might
be fun to make the fail count random...

---------------------------

An alternative I've seen is to make a token generator for the client
(using python or some other common language) and have it generate the
token using a count, time, etc, along with MD5 or whatever. Then when
you click on it's icon it generates the URL with the token for the
site and calls the browser. Then the browser can validate.

[C. (http://symcbean.blogspot.com/)]

On Jun 6, 9:04 pm, [e-mail] wrote:

Storing MD5s instead of the actual passwords in the DB is a good idea,
you get user input (maybe add something), MD5 it and then compare it
to the db record.

HTTPS can be complex if you have the pages in seperate locations
(depends on server config), prbably an auto generated key base on tine
would be a good method to bridge between the locations, or just put a
redirect on the unsecure side to a secure login. If SSL it can be
both on the same place you can also do a check to see if SSL is being
used and restrict users who are not using it. (google for it)

---------------------------------

I was working on a better logins myself, I figured I could do it this
way:

1. user goes to site's index.php with a preset keyhttp://mysite.com/index.php?pw=pass
- if index.php validates the password, it sets ap a session variable
that it has 'passed'. Now, regardless of pass or fail it still
redirects to the login.

3. Login operates as normal but will not even try to validate without
the session being set. After x number of failed attempts (recorded by
another session variable) it redirects to another (lame) page. Might
be fun to make the fail count random...

That might make sense if step 2 hadn't been omitted ;)

---------------------------

An alternative I've seen is to make a token generator for the client
(using python or some other common language) and have it generate the
token using a count, time, etc, along with MD5 or whatever. Then when
you click on it's icon it generates the URL with the token for the
site and calls the browser. Then the browser can validate.

There are 2 problems with this - 1) it requires the user to runs some
code outside of the browser, 2) using time as initialization vector/
salt/whatever for a hash is a very bad idea - its OK for reversible
encryption when you can decrypt and extract the time then work out the
difference from now.

There was a lengthy discussion recently on this NG regarding using
Javascript to create an MD5 hash using a server-side (session)
modifier which avoids these problems - have a Google.

C.