IIS ASP - protecting password

This is Interesting: Free IT Magazines  
Home > Archive > IIS ASP > June 2006 > protecting password





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author protecting password
solomon_13000

2006-06-14, 1:23 pm

I am using ms access database and asp 3.0 as my front end. In my
database there is a table called account and a field called password.
How do I protect the password stored in the database.

Evertjan.

2006-06-14, 1:23 pm

solomon_13000 wrote on 14 jun 2006 in
microsoft.public.inetserver.asp.general:

> I am using ms access database and asp 3.0 as my front end. In my
> database there is a table called account and a field called password.
> How do I protect the password stored in the database.


By not showing it on your website?

Protect against whom, btw?

I suspect every record in your table has a field called "password".

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
solomon_13000

2006-06-14, 1:23 pm

Protect from hackers who could probably intercept the password as it
travels from a secure to unsecure to secure network.

solomon_13000 wrote:
> I am using ms access database and asp 3.0 as my front end. In my
> database there is a table called account and a field called password.
> How do I protect the password stored in the database.


Rob Meade

2006-06-14, 1:23 pm

"solomon_13000" wrote ...

> Protect from hackers who could probably intercept the password as it
> travels from a secure to unsecure to secure network.


client-side hash of the password before sending it....
SSL whilst in transit
store a hashed password instead of plain text...

Just a few thoughts..

Regards

Rob


Justin Piper

2006-06-14, 1:23 pm

On Wed, 14 Jun 2006 08:11:55 -0500, solomon_13000
<solomon_13000@yahoo.com> wrote:

> How do I protect the password stored in the database.


The best way would be to store a hash of the password, rather than the
password itself. Microsoft has a redistributable API[1] that you can use
to generate the hash. Below I have included a function that demonstrates
the use of this API in VBScript.

' Function: Hash
' Generate a hash of a string value using the SHA1 algorithm.
'
' Arguments:
' value - The text to process
'
' Returns:
' A string containing the hexadecimal representation of the
' hash value.
Function Hash(value)
Dim data: Set data = CreateObject("CAPICOM.HashedData")
data.Algorithm = 0 ' CAPICOM_HASH_ALGORITHM_SHA1
data.Hash value
Hash = data.Value
End Function

When the visitor creates his account, you would use a function such as
this to generate a hash of the password he provided, and store that in the
database. Later, when the user logs in to your site, you would again
generate a hash of the password he provides and compare it to the one you
stored previously.

Keep in mind that, regardless of the length of the password, the hash will
be 40 characters long. Your database schema will need to reflect this.

[1] Platform SDK Redistributable: CAPICOM
http://www.microsoft.com/downloads/...&DisplayLang=en

--
Justin Piper
Bizco Technologies
http://www.bizco.com/
Bob Lehmann

2006-06-15, 1:27 am

Why are you passing a visible password from a secure to an unsecured
network?

Bob Lehmann

"solomon_13000" <solomon_13000@yahoo.com> wrote in message
news:1150293462.082775.142010@c74g2000cwc.googlegroups.com...
> Protect from hackers who could probably intercept the password as it
> travels from a secure to unsecure to secure network.
>
> solomon_13000 wrote:
>



solomon_13000

2006-06-15, 1:27 am

Because its an internet based application.

solomon_13000 wrote:
> I am using ms access database and asp 3.0 as my front end. In my
> database there is a table called account and a field called password.
> How do I protect the password stored in the database.


Evertjan.

2006-06-15, 7:25 am

solomon_13000 wrote on 15 jun 2006 in
microsoft.public.inetserver.asp.general:

> solomon_13000 wrote:

[please do not toppost on usenet]
[vbcol=seagreen]
> Because its an internet based application.


You seem to be answering yourself an unasked question?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
solomon_13000

2006-06-15, 7:25 am

I was asked:

Why are you passing a visible password from a secure to an unsecured
network?

My answer: Because its an internet based application

secure: hosting company server (I dont own the company)
unsecured: internet (free space)
end user: anyone including me

So if I have a login page, I supply my password and username, press the
submit button, the information will travel from the end user to the
hosting company server via an unsecured network, validated and the
results will be returned (true/false). Now anyone could possibly
intercept the password and username and do alot of damange if its not
secured.

solomon_13000 wrote:
> I am using ms access database and asp 3.0 as my front end. In my
> database there is a table called account and a field called password.
> How do I protect the password stored in the database.


Evertjan.

2006-06-15, 1:24 pm

solomon_13000 wrote on 15 jun 2006 in
microsoft.public.inetserver.asp.general:
>
> solomon_13000 wrote:
[vbcol=seagreen]
> I was asked:
>
> Why are you passing a visible password from a secure to an unsecured
> network?
>
> My answer: Because its an internet based application
>
> secure: hosting company server (I dont own the company)


a network?

> unsecured: internet (free space)
> end user: anyone including me
>
> So if I have a login page, I supply my password and username, press the
> submit button, the information will travel from the end user to the
> hosting company server via an unsecured network, validated and the
> results will be returned (true/false). Now anyone could possibly
> intercept the password and username and do alot of damange if its not
> secured.


Secure HyperText Transfer Protocol.
<http://en.wikipedia.org/wiki/Secure...ansfer_protocol>

Or use one-time passwords.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Anthony Jones

2006-06-18, 1:19 pm


"Justin Piper" <jpiper@bizco.com> wrote in message
news:op.ta453fiycs3d1w@luxembourg.psg.bizcotech.com...
> On Wed, 14 Jun 2006 08:11:55 -0500, solomon_13000
> <solomon_13000@yahoo.com> wrote:
>
>
> The best way would be to store a hash of the password, rather than the
> password itself. Microsoft has a redistributable API[1] that you can use
> to generate the hash. Below I have included a function that demonstrates
> the use of this API in VBScript.
>
> ' Function: Hash
> ' Generate a hash of a string value using the SHA1 algorithm.
> '
> ' Arguments:
> ' value - The text to process
> '
> ' Returns:
> ' A string containing the hexadecimal representation of the
> ' hash value.
> Function Hash(value)
> Dim data: Set data = CreateObject("CAPICOM.HashedData")
> data.Algorithm = 0 ' CAPICOM_HASH_ALGORITHM_SHA1
> data.Hash value
> Hash = data.Value
> End Function
>
> When the visitor creates his account, you would use a function such as
> this to generate a hash of the password he provided, and store that in the
> database. Later, when the user logs in to your site, you would again
> generate a hash of the password he provides and compare it to the one you
> stored previously.
>
> Keep in mind that, regardless of the length of the password, the hash will
> be 40 characters long. Your database schema will need to reflect this.
>
> [1] Platform SDK Redistributable: CAPICOM
>

http://www.microsoft.com/downloads/...&DisplayLang=en
>
> --
> Justin Piper
> Bizco Technologies
> http://www.bizco.com/


There are a couple of problems with this approach.

First it requires a component to be installed on the client which the client
may not want to do.

Secondly just hashing the password on it's own doesn't really help, the
attacker only needs to re-use the hash to gain access.

To overcome the first limitation I've found the JS on the site to be
effective:-

http://pajhome.org.uk/crypt/md5/

Server side I still use binary APIs.

To overcome the second limitiation a challange/response approach needs to be
developed.

For example the code in the login page could contain a Nonce value (a value
which is unique and is only ever used this one time). The password and the
Nonce (I usually add the user name as well) are combined into a single
string from which the hash is derived.
The Nonce, Hash and username are sent to the server. The server looks up
the users password combines it with the Nonce and user name and should
generate a matching Hash.

Of course this requires the database contain the user password as plain
text. If this is a problem then a hash could be held and have the client
hash the password before using it in combination with the Nonce and hashing
a second time.

For a stronger solution the Nonce should have a short life time where it
expires whether it has been used or not. This can be implemented using
XMLHTTPRequest to fetch a nonce just prior to posting the login form.

Anthony.


Justin Piper

2006-06-19, 1:22 pm

On Sun, 18 Jun 2006 10:12:45 -0500, Anthony Jones <Ant@yadayadayada.com>
wrote:

>
> "Justin Piper" <jpiper@bizco.com> wrote in message
> news:op.ta453fiycs3d1w@luxembourg.psg.bizcotech.com...
>
> There are a couple of problems with this approach.
>
> First it requires a component to be installed on the client which the
> client
> may not want to do.


Actually, I ment that this be used server-side, to protect the password in
the database from prying eyes. You're right that it would not be useful
client side, but SSL would be more appropriate for that, anyway.

--
Justin Piper
Bizco Technologies
http://www.bizco.com/
Anthony Jones

2006-06-19, 1:22 pm


"Justin Piper" <jpiper@bizco.com> wrote in message
news:op.tbeg6mqscs3d1w@luxembourg.psg.bizcotech.com...
> On Sun, 18 Jun 2006 10:12:45 -0500, Anthony Jones <Ant@yadayadayada.com>
> wrote:
>
use[vbcol=seagreen]
demonstrates[vbcol=seagreen]
>
> Actually, I ment that this be used server-side, to protect the password in
> the database from prying eyes. You're right that it would not be useful
> client side, but SSL would be more appropriate for that, anyway.
>


Thanks Justin I misunderstood you.

SSL would seem to be a better way but then you need to get a trusted
certificate (for which there may be a cost) and I've not found a way to
seemlessly transition from https to a http.

Without a trusted certificate the users are likely to get warnings that may
put them off.

A response.redirect from https to http also typically puts up a worrying
warning to the user. I've tried meta refresh but it will ignore the http
URL in the content attribute.

Any ideas, just curious?


> --
> Justin Piper
> Bizco Technologies
> http://www.bizco.com/



Justin Piper

2006-06-19, 7:22 pm

On Mon, 19 Jun 2006 12:18:14 -0500, Anthony Jones <Ant@yadayadayada.com>
wrote:
> SSL would seem to be a better way but then you need to get a trusted
> certificate (for which there may be a cost) and I've not found a way to
> seemlessly transition from https to a http.
>
> Without a trusted certificate the users are likely to get warnings that
> may
> put them off.


True, and for good reason. A certificate that has not been signed by a
trusted authority would still be usable for encrypting the transmission,
but would be vulnerable to man-in-the-middle attacks.

> A response.redirect from https to http also typically puts up a worrying
> warning to the user. I've tried meta refresh but it will ignore the http
> URL in the content attribute.


I'm not aware of any way around that, and it seems to be SOP on the web,
anyway. I don't expect people to get very far without running into that
warning message. You could always just stick with SSL once you use it, but
then your visitors on dialup will hate you for rendering all the images
uncachable.

--
Justin Piper
Bizco Technologies
http://www.bizco.com/
Anthony Jones

2006-06-19, 7:22 pm


"Justin Piper" <jpiper@bizco.com> wrote in message
news:op.tbeq5vg3cs3d1w@luxembourg.psg.bizcotech.com...
> On Mon, 19 Jun 2006 12:18:14 -0500, Anthony Jones <Ant@yadayadayada.com>
> wrote:
>
> True, and for good reason. A certificate that has not been signed by a
> trusted authority would still be usable for encrypting the transmission,
> but would be vulnerable to man-in-the-middle attacks.
>
http[vbcol=seagreen]
>
> I'm not aware of any way around that, and it seems to be SOP on the web,
> anyway. I don't expect people to get very far without running into that
> warning message. You could always just stick with SSL once you use it, but
> then your visitors on dialup will hate you for rendering all the images
> uncachable.


Not to mention the extra load on your server. Therefore I don't really
consider SSL a good solution for login bearing in mind a fairly strong
challange/response login can be created without it. SSL really becomes
useful when you need to send something to a server that it hasn't seen
before and/or shouldn't store e.g., Credit card details or the initial
username/password creation.

>
> --
> Justin Piper
> Bizco Technologies
> http://www.bizco.com/



Dave Anderson

2006-06-20, 1:23 pm

Anthony Jones wrote:
> Not to mention the extra load on your server. Therefore I don't
> really consider SSL a good solution for login bearing in mind a
> fairly strong challange/response login can be created without it.


You honestly think you can build a strong login without it? And without
taxing your server more than SSL does, at that? I am dying to hear more.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.


Anthony Jones

2006-06-20, 1:23 pm


"Dave Anderson" <NYRUMTPELVWH@spammotel.com> wrote in message
news:129fs493oku9pa6@corp.supernews.com...
> Anthony Jones wrote:
>
> You honestly think you can build a strong login without it?


If Challange/Response MD5 or SHA1 is not strong enough for you then no
otherwise yes. After all if you really need it be very strong it's likely
you'd want all the content protected by SSL.

>And without taxing your server more than SSL does, at that?


My point was I've not at this time been able to create smooth transition for
the a SSL protected Logon page to general unprotected content. Hence either
I scare the user with nasty 'You might be posting data in a unsecure way'
sort of message or I run the whole site in SSL which would definitely demand
more of the server than is necessary.

However, I'd be interested in techniques that allowed SSL to be used for
login only but did not involved scary message being given to the user. Any
ideas?

>I am dying to hear more.
>
>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message.

Use
> of this email address implies consent to these terms.
>
>



Justin Piper

2006-06-20, 1:23 pm

On Mon, 19 Jun 2006 12:18:14 -0500, Anthony Jones <Ant@yadayadayada.com>
wrote:
> SSL would seem to be a better way but then you need to get a trusted
> certificate (for which there may be a cost) and I've not found a way to
> seemlessly transition from https to a http.
>
> Without a trusted certificate the users are likely to get warnings that
> may
> put them off.
>
> A response.redirect from https to http also typically puts up a worrying
> warning to the user. I've tried meta refresh but it will ignore the http
> URL in the content attribute.


What version of IE are you seeing this behavior in? I have 6.0.3790.1830
(W2k3 SP1), and it seems to handle meta refresh correctly. I've included
the script I used to test below. Change the ``Script`` constant to
something appropriate.

<% Option Explicit

Const Script = "localhost/login.asp"

Dim action, secure
action = Request.Form("action")
secure = Request.ServerVariables("HTTPS")
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Default</title>
<% If action="login" Then %>
<meta http-equiv="refresh"
content="0;url=http://<%= Script %>">
<% End If %>
</head>
<body>
<div>Secure: <%= secure %></div>
<div>Action: <%= action %></div>
<form method="post" action="https://<%= Script %>">
<input type="submit" name="action" value="login">
</form>
</body>
</html>

--
Justin Piper
Bizco Technologies
http://www.bizco.com/
Anthony Jones

2006-06-20, 1:23 pm


"Justin Piper" <jpiper@bizco.com> wrote in message
news:op.tbf8hfstcs3d1w@luxembourg.psg.bizcotech.com...
> On Mon, 19 Jun 2006 12:18:14 -0500, Anthony Jones <Ant@yadayadayada.com>
> wrote:
http[vbcol=seagreen]
>
> What version of IE are you seeing this behavior in? I have 6.0.3790.1830
> (W2k3 SP1), and it seems to handle meta refresh correctly. I've included
> the script I used to test below. Change the ``Script`` constant to
> something appropriate.
>
> <% Option Explicit
>
> Const Script = "localhost/login.asp"
>
> Dim action, secure
> action = Request.Form("action")
> secure = Request.ServerVariables("HTTPS")
> %>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <title>Default</title>
> <% If action="login" Then %>
> <meta http-equiv="refresh"
> content="0;url=http://<%= Script %>">
> <% End If %>
> </head>
> <body>
> <div>Secure: <%= secure %></div>
> <div>Action: <%= action %></div>
> <form method="post" action="https://<%= Script %>">
> <input type="submit" name="action" value="login">
> </form>
> </body>
> </html>
>


I was missing the url= from the content attribute. It works fine now
thanks. It is certainly a better solution if you already have a trusted
certificate.

> --
> Justin Piper
> Bizco Technologies
> http://www.bizco.com/



Dave Anderson

2006-06-20, 1:23 pm

Anthony Jones wrote:
>
> If Challange/Response MD5 or SHA1 is not strong enough for
> you then no otherwise yes.


But either of those implemented on the client is still vulnerable to
man-in-the-middle attacks, just as SSL without trust is. But you knew that.



> ...I'd be interested in techniques that allowed SSL to be used
> for login only but did not involved scary message being given
> to the user. Any ideas?


Login at amazon.com.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.


Anthony Jones

2006-06-20, 1:23 pm


"Dave Anderson" <NYRUMTPELVWH@spammotel.com> wrote in message
news:OnL5cSIlGHA.1344@TK2MSFTNGP03.phx.gbl...
> Anthony Jones wrote:
>
> But either of those implemented on the client is still vulnerable to
> man-in-the-middle attacks, just as SSL without trust is. But you knew

that.
>


Yes I did but even a logon created using trusted SSL is still vunerable to
man-in-the-middle attacks when the session in general operates over
unencrypted http. The attack is unable to actually reveal the password for
later use. The objective of this technique is simply to protect the
password. If the session needs protecting or the content then SSL is needed
for the whole session.

>
>
>
> Login at amazon.com.
>


Yes Justin has put me right on this already. With a trusted certificate for
a single machine I would prefer SSL too. Gets a little tricky on IIS to
support multiple SSL websites though and not all my clients want to the
hassle. Clients are nervous about the idea of the password itself floating
about on the internet unencrypted so what I've proposed suits them, their
not exactly MI5.

>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message.

Use
> of this email address implies consent to these terms.
>
>



Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com