Secure logins...

[The Plankmeister]

Hi. I reaslise this is possibly considered off-topic, but I want to pick as
many expert brains as possible. Apologies in advance....

I have a form on which I have a username and password box. Then in the
validation function called by the form's onsubmit event, I'm taking the
username and password and generating an MD5 hash (using javascript) from
them, disabling the password box and writing the MD5 hash to a hidden field
on the form and then allowing the form to be submitted. This way, there is
no clear-text password sent across the net, only the username and the MD5
hash of the username/password.

However... I started thinking that it doesn't really matter... The MD5 hash
is sent as clear text anyway. Anyone snooping could just catch the clear
text username and MD5 and they're as good as in. Then I started thinking
about a 'coupon' system, where I would have the server generate a random MD5
hash which it would place in a hidden field in the form. Then, upon
attempting to login, the server would only accept login attempts from coupon
numbers that it's issued... I was thinking this would get around any
possible CSS hacks. But it wouldn't really... Or would it? Am I right in
thinking that if someone were to have already intercepted the clear text
username/MD5 hash sent previously, they would only have to visit the login
page to be issued with a new coupon, which they could then use in
conjunction with the username/MD5 and CSS to get access?

And I've heard that just checking http_referer is pointless because it's
easily forgeable.

So what is a secure method of dealing with non-cross-site scriptable logins?

[Martin C. Petersen]

Re: Secure logins...

> However... I started thinking that it doesn't really matter... The MD5
hash[color=blue]
> is sent as clear text anyway. Anyone snooping could just catch the clear
> text username and MD5 and they're as good as in. Then I started thinking
> about a 'coupon' system, where I would have the server generate a random[/color]
MD5[color=blue]
> hash which it would place in a hidden field in the form. Then, upon
> attempting to login, the server would only accept login attempts from[/color]
coupon[color=blue]
> numbers that it's issued... I was thinking this would get around any
> possible CSS hacks. But it wouldn't really... Or would it? Am I right in
> thinking that if someone were to have already intercepted the clear text
> username/MD5 hash sent previously, they would only have to visit the login
> page to be issued with a new coupon, which they could then use in
> conjunction with the username/MD5 and CSS to get access?[/color]
What you need to do, is generate a random 'challenge' every time a login-box
is to be shown. This challenge is then stored in the session and/or
database. When the user has entered username and password you create a
md5-hash incorporating username, password and challenge - this will give a
new md5 string every time..

You might wanna check this out:

http://phplib.sourceforge.net/

It has some challenge-based authentication features (haven't tried it myself
though).


Martin

[Stan Brown]

Re: Secure logins...

In article <3f632f67$0$972 43$edfadb0f@dre ad12.news.tele. dk> in
comp.infosystem s.www.authoring.html, The Plankmeister
<plankmeister_N OSPAM_@hotmail. com> wrote:[color=blue]
>I have a form on which I have a username and password box. Then in the
>validation function called by the form's onsubmit event, I'm taking the
>username and password and generating an MD5 hash (using javascript) from
>them, disabling the password box and writing the MD5 hash to a hidden field
>on the form and then allowing the form to be submitted. This way, there is
>no clear-text password sent across the net, only the username and the MD5
>hash of the username/password.[/color]

Also that way, a significant number of viewers will click the submit
button and think the form was submitted when it wasn't.

NEVER make form submission (or other navigation) dependent on
JavaScript.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA

http://OakRoadSystems.com/

HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[The Plankmeister]

Re: Secure logins...

[color=blue]
> NEVER make form submission (or other navigation) dependent on
> JavaScript.[/color]


The very first page on my site checks if the user has Javascript enabled. If
they don't then I just redirect them to a page that tells them they don't
have it enabled and that the site requires it. 99% of users leave their
javascript on, and I use it heavily with CSS to position elements
dynamically, so it's a definite requirement for my site.
Even so, I still see your point. I think I'll have the password box disabled
by default, and in body-onpageload enable it using javascript. That way,
there's no way they can login and risk sending clear-text password.

[Nick Kew]

Re: Secure logins...

In article <3f632f67$0$972 43$edfadb0f@dre ad12.news.tele. dk>, one of infinite monkeys
at the keyboard of "The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> wrote:[color=blue]
> Hi. I reaslise this is possibly considered off-topic, but I want to pick as
> many expert brains as possible. Apologies in advance....[/color]

Indeed. If you're messing with the protocol, then .misc is probably more
on-topic.

Sounds like you've tried to reinvent HTTP Digest Authentication.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Tina Holmboe]

Re: Secure logins...

"The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> exclaimed in <3f635b55$0$972 18$edfadb0f@dre ad12.news.tele. dk>:
[color=blue]
> The very first page on my site checks if the user has Javascript enabled. If
> they don't then I just redirect them to a page that tells them they don't
> have it enabled and that the site requires it. 99% of users leave their[/color]

Oddly enough, my favourite ads-concealed-as-statistics site, thecounter.com,
claim that 13% leave it off. You have peculiar visitors. When even that
time (dis) honoured establishment claim less than a 100%, you might want
to consider listening.


[color=blue]
> Even so, I still see your point. I think I'll have the password box disabled
> by default, and in body-onpageload enable it using javascript. That way,
> there's no way they can login and risk sending clear-text password.[/color]

Y'know, others would simply enable the secure channels in their webserver,
spending a grand total of 60 minutes or thereabouts solving this problem
for ALL users, without discrimination.

My hat - if I had one - goes off for you. Seldom have I seen so much work
put into solving ... nothing.[*]

Followup set to comp.lang.javas cript, as it has absolutely nothing what
so ever to do with HTML or PHP. Or sanity, IMnsHO.


[*]
Save, of course, Stephen Hawking for whom I have the greatest respect and
who spend most of his time thinking about nothingness >:)

--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[EightNineThree]

Re: Secure logins...


"The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> wrote in message
news:3f635b55$0 $97218$edfadb0f @dread12.news.t ele.dk...[color=blue]
>[color=green]
> > NEVER make form submission (or other navigation) dependent on
> > JavaScript.[/color]
>
>
> The very first page on my site checks if the user has Javascript enabled.[/color]
If[color=blue]
> they don't then I just redirect them to a page that tells them they don't
> have it enabled and that the site requires it.[/color]

Well now, that's user friendly.
"Dear visitor, if you don't conform to how we want things, then we don't
want your business"
[color=blue]
>99% of users leave their
> javascript on,[/color]

No they don't.
Try 88-89.
Maybe your site only gets a few visitors a month, but at my dayjob, the site
handles 300,000 UNIQUE.
I'm not turning away 30,000 plus potential customers.


--
Karl Core

Charles Sweeney says my sig is fine as it is.

[Stan Brown]

Re: Secure logins...

In article <3f635b55$0$972 18$edfadb0f@dre ad12.news.tele. dk> in
comp.infosystem s.www.authoring.html, The Plankmeister
<plankmeister_N OSPAM_@hotmail. com> wrote:[color=blue]
> 99% of users leave their
>javascript on,[/color]

Someone a couple of days ago claimed 98%. I asked then for some
citation, and I'm still waiting.

Where does your 99% come from, or is it just wishful thinking?

Note: Even if it really is 99%, you're rejecting literally millions
of potential viewers by your insistence on JavaScript. If you're
using it for navigation, that's amazingly stupid, since navigation
without JavaScript would work for 100.00% of visitors.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA

http://OakRoadSystems.com/

HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[The Plankmeister]

Re: Secure logins...

Well I certainly seem to have opened a rather large an unwieldy can of worms
with my stance on Javascript, eh?!
Allow me to leap to my own defence: The site in question is my own personal
homesite, which contains nothing more than a load of
rubbish about me: pictures, some links, a few blurbs about various things
I'm interested in. On my site I sell nothing. In a 'good' month I'll get ~50
hits. In a bad month I'll get none. According to my logs, which keep track
of who does and who does not have javascript enabled, only 262 users out of
4385 so far (a pitifully small amount considering the site's been up for
such a long time) have had it disabled. That's about 6% of users that have
it disabled. Or 94% of users that have it enabled. Ok... so my earlier
figure of 99% was wrong, but I wasn't far off.
I don't rely on javascript for navigation. I use javascript to 'stretch'
certain page elements (I've written it fully relying on CSS... not a table
in sight) so that they're all the same height, otherwise the site looks ugly
(and it needs all the anti-ugly treatment it can get). I've tested the site
without javascript and it all works fine, it just looks awful. One of the
drawbacks of using CSS over tables...
My site is basically just a continual experiment in different methods of
writing a homepage. It's been through about 10 revisions, with each
subsequent revision being much better than the predecessor, implementing
more 'standardised' methods. You may argue that having to enable javasript
is not at all standardised, and you'd be right.
However... It's my website. I get to call the shots. Until a change of
career direction a few years ago, I was a web designer when web design was
in it's infancy. I loathed having to write 'different' sites for each
different browser and each different version of those browsers. So now I use
a cross-browser javascript library to deal with a whole host of stuff.
But on the other hand, if I were to be selling things on my website, it
would all be written using tables and no javascript and all the 'old'
methods, and it would definitely be submitted to search engines, which it
isn't at present.

P.




"Stan Brown" <the_stan_brown @fastmail.fm> wrote in message
news:MPG.19cd89 425a42030e98b39 1@news.odyssey. net...[color=blue]
> In article <3f635b55$0$972 18$edfadb0f@dre ad12.news.tele. dk> in
> comp.infosystem s.www.authoring.html, The Plankmeister
> <plankmeister_N OSPAM_@hotmail. com> wrote:[color=green]
> > 99% of users leave their
> >javascript on,[/color]
>
> Someone a couple of days ago claimed 98%. I asked then for some
> citation, and I'm still waiting.
>
> Where does your 99% come from, or is it just wishful thinking?
>
> Note: Even if it really is 99%, you're rejecting literally millions
> of potential viewers by your insistence on JavaScript. If you're
> using it for navigation, that's amazingly stupid, since navigation
> without JavaScript would work for 100.00% of visitors.
>
> --
> Stan Brown, Oak Road Systems, Cortland County, New York, USA
> http://OakRoadSystems.com/
> HTML 4.01 spec: http://www.w3.org/TR/html401/
> validator: http://validator.w3.org/
> CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
> 2.1 changes: http://www.w3.org/TR/CSS21/changes.html
> validator: http://jigsaw.w3.org/css-validator/[/color]

[Kris]

Re: Secure logins...

In article <3f643b3d$0$159 $edfadb0f@dread 11.news.tele.dk >,
"The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> wrote:
[color=blue]
> But on the other hand, if I were to be selling things on my website, it
> would all be written using tables and no javascript and all the 'old'
> methods, and it would definitely be submitted to search engines, which it
> isn't at present.[/color]

A pity that of all your words, none reflect any intention of getting
better at the 'new' methods.

--
Kris
kristiaan@xs4al l.netherlands (nl)
"We called him Tortoise because he taught us" said the Mock Turtle.

[The Plankmeister]

Re: Secure logins...

> A pity that of all your words, none reflect any intention of getting[color=blue]
> better at the 'new' methods.[/color]

Except the fact that I mentioned that the site has gone through 10
revisions, each better than the previous?

[Tina Holmboe]

Re: Secure logins...

"The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> exclaimed in <3f643b3d$0$159 $edfadb0f@dread 11.news.tele.dk >:
[color=blue]
> (and it needs all the anti-ugly treatment it can get). I've tested the site
> without javascript and it all works fine, it just looks awful. One of the
> drawbacks of using CSS over tables...[/color]

Your site looks awful - in your eyes - with Javascript disabled, and that
is one of the drawbacks of using CSS ?

Followups back to ciwah - this might be an on topic joke.

--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Jim Dabell]

Re: Secure logins...

The Plankmeister wrote:

[snip][color=blue]
> However... I started thinking that it doesn't really matter... The MD5
> hash is sent as clear text anyway. Anyone snooping could just catch the
> clear text username and MD5 and they're as good as in.[/color]

Yes. It has a slight advantage, in that an observer doesn't get the
plaintext password (which may be used on other systems). It also has a
*major* disadvantage, which others have already pointed out, in that it's
reliant upon client-side scripting.

[color=blue]
> Then I started thinking about a 'coupon' system, where I would have the
> server generate a random MD5 hash which it would place in a hidden field
> in the form. Then, upon attempting to login, the server would only accept
> login attempts from coupon numbers that it's issued...[/color]

That still doesn't prevent replay attacks, since an attacker would just
request the form to get a valid "coupon" (they are called nonces BTW).
Presumably you would incorporate this in the client hashing procedure, but
you didn't mention this. You also need to ensure you don't re-use any.
More information:

<URL:http://www.intertwingl y.net/blog/1585.html>

[color=blue]
> I was thinking this would get around any possible CSS hacks.[/color]
[snip]

If you are referring to Cross-Site Scripting attacks, then the preferred
abbreviation is XSS, to distinguish it from Cascading Style Sheets. I don't
see the connection with XSS attacks, you seem to be talking about replay
attacks.

[color=blue]
> And I've heard that just checking http_referer is pointless because it's
> easily forgeable.[/color]

Yes. Nothing provided by the client is trustable.

[color=blue]
> So what is a secure method of dealing with non-cross-site scriptable
> logins?[/color]

Don't bodge together your own system. The wheel has already been invented
enough times. Depending on your requirements, you could use TLS, client
certificates, or digest authentication. If you are going to roll your own,
then at least read Applied Cryptography and check out what's already been
accomplished in the field.


--
Jim Dabell

[Jim Dabell]

Re: Secure logins...


[Please don't post upside down.]


The Plankmeister wrote:
[color=blue]
> Well I certainly seem to have opened a rather large an unwieldy can of
> worms with my stance on Javascript, eh?![/color]

Well with all due respect, if you did the decent thing and read the
newsgroups you posted this to for a while beforehand, you would have
anticipated this (and probably learned enough to do things in a better
way).


[snip][color=blue]
> (I've written it fully relying on CSS... not a table in sight)[/color]

Are you sure you mean that? You shouldn't *rely* on CSS, it's purely
optional.


[snip][color=blue]
> I've tested the site without javascript and it all works fine, it just
> looks awful.[/color]

So changing the site so that it definitely breaks when Javascript is not
available would be a step backwards.

[color=blue]
> One of the drawbacks of using CSS over tables...[/color]

CSS doesn't require Javascript [1]. If you are relying on Javascript to fix
up your CSS, then your CSS is wrong. Head on over to
<news:comp.info systems.www.aut horing.styleshe ets> for that.


[snip][color=blue]
> However... It's my website. I get to call the shots.[/color]
[snip]

Of course. But if you ignore the advice of the people on these groups, when
you post followup questions, they are likely to be fixable by following the
advice you got originally. So you'll either annoy people, get the same
advice doled out each time, or both.


[1] Except in the case of Netscape 4.x, which is a special case.

--
Jim Dabell

[The Plankmeister]

Re: Secure logins...

Ok... Advice/Critiques/Flames digested. I'm coming around to this whole idea
of "get it working and fully functional without javascript - then spruce it
up a little using javascript," so I've decided to go back to the drawing
board again. (That'll be the 4th time in this redesign, then!)

Time to brush up on some CSS, methinks.

Thanks for everyone's input. I've seen the light, and it is very inviting...

P.

(And apologies for 'top posting.' Never knew that was a bad thing)