473,320 Members | 2,052 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Secure logins...

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?
Jul 20 '05 #1
14 2060
> 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?

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
Jul 20 '05 #2
In article <3f***********************@dread12.news.tele.dk> in
comp.infosystems.www.authoring.html, The Plankmeister
<pl******************@hotmail.com> wrote:
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.


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/
Jul 20 '05 #3
NEVER make form submission (or other navigation) dependent on
JavaScript.

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.
Jul 20 '05 #4
In article <3f***********************@dread12.news.tele.dk> , one of infinite monkeys
at the keyboard of "The Plankmeister" <pl******************@hotmail.com> wrote:
Hi. I reaslise this is possibly considered off-topic, but I want to pick as
many expert brains as possible. Apologies in advance....


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
Jul 20 '05 #5
"The Plankmeister" <pl******************@hotmail.com> exclaimed in <3f***********************@dread12.news.tele.dk> :
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
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.
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.


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.javascript, 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
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #6

"The Plankmeister" <pl******************@hotmail.com> wrote in message
news:3f***********************@dread12.news.tele.d k...
NEVER make form submission (or other navigation) dependent on
JavaScript.

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.
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"
99% of users leave their
javascript on,


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.
Jul 20 '05 #7
In article <3f***********************@dread12.news.tele.dk> in
comp.infosystems.www.authoring.html, The Plankmeister
<pl******************@hotmail.com> wrote:
99% of users leave their
javascript on,


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/
Jul 20 '05 #8
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" <th************@fastmail.fm> wrote in message
news:MP************************@news.odyssey.net.. .
In article <3f***********************@dread12.news.tele.dk> in
comp.infosystems.www.authoring.html, The Plankmeister
<pl******************@hotmail.com> wrote:
99% of users leave their
javascript on,


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/

Jul 20 '05 #9
In article <3f*********************@dread11.news.tele.dk>,
"The Plankmeister" <pl******************@hotmail.com> wrote:
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.


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

--
Kris
kr*******@xs4all.netherlands (nl)
"We called him Tortoise because he taught us" said the Mock Turtle.
Jul 20 '05 #10
> A pity that of all your words, none reflect any intention of getting
better at the 'new' methods.


Except the fact that I mentioned that the site has gone through 10
revisions, each better than the previous?
Jul 20 '05 #11
"The Plankmeister" <pl******************@hotmail.com> exclaimed in <3f*********************@dread11.news.tele.dk>:
(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...


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
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #12
The Plankmeister wrote:

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

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...
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.intertwingly.net/blog/1585.html>

I was thinking this would get around any possible CSS hacks. [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.

And I've heard that just checking http_referer is pointless because it's
easily forgeable.
Yes. Nothing provided by the client is trustable.

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


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

Jul 20 '05 #13

[Please don't post upside down.]
The Plankmeister wrote:
Well I certainly seem to have opened a rather large an unwieldy can of
worms with my stance on Javascript, eh?!
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] (I've written it fully relying on CSS... not a table in sight)
Are you sure you mean that? You shouldn't *rely* on CSS, it's purely
optional.
[snip] I've tested the site without javascript and it all works fine, it just
looks awful.
So changing the site so that it definitely breaks when Javascript is not
available would be a step backwards.

One of the drawbacks of using CSS over tables...
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.infosystems.www.authoring.stylesheets > for that.
[snip] However... It's my website. I get to call the shots.

[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

Jul 20 '05 #14
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)
Jul 20 '05 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: The Plankmeister | last post by:
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....
5
by: Max | last post by:
I have a collection of system admin scripts (on Win 2k) that I would like to automate the execution of. However, some of them require the use of logins with admin rights, and would therefore prefer...
8
by: peter | last post by:
I have taken over the website duties at work. I am still learning PHP and MySQL. I want to have a form where the user enters some finacial info and it is stored in a database. It, obviously,...
0
by: Wiktor Zychla | last post by:
Hello, after several investigations around ASP.NET, I would like to ask about the best practices for building a secure database application. suppose I wish to use Forms authentication in...
13
by: Hope Paka | last post by:
I am storing user login information (not password) in the session. I also use, cookieless session. I realized that, if someone copy-pastes the URL after he/she logged in to the system to another...
1
by: sharp2037 | last post by:
Hi Everyone, I am working on an ASP.net application and I have a homepage to which everyone visits of course and on that front page I have a user ID and password box and a login button. What...
4
by: Jamey Shuemaker | last post by:
A2k2 with user-level security and all preventive measures, vis a vis, Security FAQ enabled or enacted. I've got three DBs, which due to size constraints can't, or rather, probably shouldn't be...
14
by: knal | last post by:
Hi there, I'm looking for a secure login script for a sort-of-community site... (PHP, MySQL, sessions, or maybe something else ... ) I know there are a lot of scripts out there, but none of them...
0
by: Tony | last post by:
How much is secure to use session for user login, database queryng or similar oprations. Can somebody read or change session data? Can somebody hack user logins if it is based on session? Can...
1
by: Annonymous Coward | last post by:
I am writing an application which I will deploy to my clients. It is important for security, support, IP reasons etc, that the users are not able to access my databse schema (i.e. view/modify/run...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.