Re: secure login form

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
.

Relevant Pages

  • Re: secure login form
    ... For my point of view I'm thinking of using md5 passwords in db. ... If you want the avoid the man-in-the-middle eavesdropping on you: Then you need https, ... 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. ... (You can propagate the sessionid from http to https via a form, and let the receiving script use that sessionid for its https session. ...
    (comp.lang.php)
  • Re: secure login form
    ... For my point of view I'm thinking of using md5 passwords in db. ... If you want the avoid the man-in-the-middle eavesdropping on you: Then you need https, ... 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. ... (You can propagate the sessionid from http to https via a form, and let the receiving script use that sessionid for its https session. ...
    (comp.lang.php)
  • Re: secure login form
    ... while I'm developing sites for some time I never coded a login form with security in mind. ... For my point of view I'm thinking of using md5 passwords in db. ... That is where https comes in. ... if you use cookie-based sessions, you can mark your cookies as secure. ...
    (comp.lang.php)
  • Re: Time-to-crack MD5 passwords
    ... ]>]> customer of, regarding the length of passwords. ... ]> The md5 passwords do not use just md5. ... ]> use an arbitrary length string-- you are not limited to 8 characters. ...
    (comp.security.misc)
  • Re: SP2 and OWA
    ... risk, not that exposing passwords was a risk. ... interested in knowing how HTTP is more of a risk than HTTPS and I ...
    (microsoft.public.exchange.admin)