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?

[Sean Jorden]

Re: Secure logins...

"The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> wrote in
news:3f632f67$0 $97243$edfadb0f @dread12.news.t ele.dk:

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

https?

and configure your server (or script) to force a redirect to the https
login page if they ever hit it in http

[EightNineThree]

Re: Secure logins...


"Sean Jorden" <s_j_o_r_d.e.n@ no.spam.n_o_r_a .d.a.com> wrote in message
news:Xns93F55D4 5AECADsjorden@1 98.161.157.145. ..[color=blue]
> "The Plankmeister" <plankmeister_N OSPAM_@hotmail. com> wrote in
> news:3f632f67$0 $97243$edfadb0f @dread12.news.t ele.dk:
>
>[color=green]
> >
> > So what is a secure method of dealing with non-cross-site scriptable
> > logins?
> >
> >
> >[/color]
>
> https?
>
> and configure your server (or script) to force a redirect to the https
> login page if they ever hit it in http
>
>[/color]

IIRC, that involves having a certificate on that server, right?


--
Karl Core

Charles Sweeney says my sig is fine as it is.

[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

[Sean Jorden]

Re: Secure logins...

"EightNineThree " <eightninethree @REMOVEeightnin ethree.com> wrote in
news:bjvcqr$bkd $1@ngspool-d02.news.aol.co m:

[color=blue][color=green]
>>[color=darkred]
>> >
>> > So what is a secure method of dealing with non-cross-site scriptable
>> > logins?
>> >
>> >
>> >[/color]
>>
>> https?
>>
>> and configure your server (or script) to force a redirect to the https
>> login page if they ever hit it in http
>>
>>[/color]
>
> IIRC, that involves having a certificate on that server, right?
>
>[/color]

Yes, and they are a hassle and $$$ to obtain, although you can issue your
own (browser will get a popup warning).

[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/

[Alan J. Flavell]

Re: Secure logins...


OT for this group, but:

On Sat, Sep 13, Sean Jorden inscribed on the eternal scroll:
[color=blue]
> "EightNineThree " <eightninethree @REMOVEeightnin ethree.com> wrote in
> news:bjvcqr$bkd $1@ngspool-d02.news.aol.co m:
>[color=green]
> > IIRC, that involves having a certificate on that server, right?[/color]
>
> Yes, and they are a hassle and $$$ to obtain,[/color]

true enough if you get them signed by a commercial CA...
[color=blue]
> although you can issue your own (browser will get a popup warning).[/color]

If it's a regular use situation, then you can have the users import
the certificate (or your self-made signing authority certificate if
you want to sign for multiple servers). That way they don't get
alerted again unless/until someone tries to impersonate the server.

It's good to do that, because if you let them get trained into seeing
popup alerts and casually dismissing them, you're defeating one
valuable layer of security.

[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.

[Alan J. Flavell]

Re: Secure logins...

On Sat, Sep 13, The Plankmeister inscribed on the eternal scroll:
[color=blue]
> The very first page on my site checks if the user has Javascript enabled.[/color]

It'll be interesting to see what happens when they change their mind
later.
[color=blue]
> 99% of users leave their javascript on,[/color]

I think you're mistaken. 100% of your users leave their js on.

The rest are happily using someone else's web site.

[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.