Welcome, Guest. Please login or register.
Did you miss your activation email?
Nov. 01, 2014, 02:00:23 AM
56628 Posts in 12745 Topics by 19623 Members
Latest Member: aGenRa12
News:
 
The PRADO Community » Legacy - archived » Prado v2.x » Tips, Snippets and Tutorials » Secure Login example « previous next »
Pages: [1] Print
Author Topic: Secure Login example  (Read 7297 times)
zwetph
Guest
« on: Nov. 03, 2004, 10:41:22 PM »

Using the examples of __PPS__ I created this first example of how to use javascript to hash the userid and password before sending it to the server. I had some trouble combining javascript with the buttons. Used a gladiator image as submit button  :?
Logged
Qiang
PRADO Team Leader
Administrator
Diamond Member
*****

Karma: 99
Offline Offline

Posts: 3241



View Profile
« Reply #1 on: Nov. 04, 2004, 09:19:46 PM »

You didn't include the js file in!

hmm, in this way, what if the hashed data is intercepted and the hash method is also known? I think a salt from the server should be used.

Component-wise, I think you can extend TCustomValidator and add two properties: UsernameControl, PasswordControl. If the new validator is added into a login form, then the client side javascript of the validator will hash the user login info (based on the two new properties because the validator will know what field data to hash with).

Forgive me if I made it wrong about the security concept.
Logged
__PPS__
Junior Member
**

Karma: 0
Offline Offline

Posts: 32


View Profile
« Reply #2 on: Nov. 04, 2004, 10:16:24 PM »

How to make it work?
I got many errors instead.
Code:

Warning: Invalid argument supplied for foreach() in /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php on line 164

Warning: Invalid argument supplied for foreach() in /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php on line 173

Warning: Invalid argument supplied for foreach() in /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php on line 176

Fatal error: Uncaught exception 'Exception' with message 'Unknown page requested ''.' in /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php:548 Stack trace: #0 /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php(457): TApplication->loadPage('') #1 /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php(333): TApplication->pageService('') #2 /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php(376): TApplication->serveRequest('page') #3 /usr/local/www32/htdocs/prado/securelogin.php(6): TApplication->run() #4 {main} thrown in /usr/local/www32/htdocs/prado/WEB-INF/framework/TApplication.php on line 548
[/code]
Logged
zwetph
Guest
« Reply #3 on: Nov. 05, 2004, 12:09:57 AM »

I added the jscript file and will soon make the suggested changes.
I will also setup a test environment to test my zipped components before publishing  Cheesy

Please read (again)
http://www.xisc.com/forum/viewtopic.php?t=63&postdays=0&postorder=asc&start=0. I talked about possible attacks there.


I will try to explain this again but now from a different perspective why I think we need a salt.

Case 1:
When the user posts his userid and login they are captured on the clientside. The password is hashed. Nothing else. SHA-1(P)

Threat:
An attacker intercepts all traffic from and to the user and thus knows the userid (plain) and hashed password.

Impact:
1. The attacker can use the userid and hashed password to login to the site.
2. The attacker can use the same hashed password at a later time at the same site
3. The attacker can use the hashed password at a different site that also uses SHA-1 hashed passwords with no salt.


Case 2:
We hash the password with a random salt SHA-1(P + S)

Threat:
An attacker intercepts all traffic from and to the user and thus knows the userid (plain) and hashed (password + salt).

Impact:
1. The attacker can use the userid and hashed (password+salt) to login to the site if he also captures the session.

The attacker CAN NOT use the same hashed password+salt at a later time at the same site.
The attacker CAN NOT use the hashed password+salt at a different site that also uses SHA-1 hashed passwords with no salt.

Did you spot the differences?

What does the salt do:
1. it binds the hash to the session (you need to intercept the session)
2. it binds the response to the request (you need to get both)
3. it makes the hash useless at a later time (new session so new salt)
4. it makes the hash useless on other sites (never the same salt)

You can however still:
1. try to guess the password
2. intercept the session

To prevent password guessing:
1. use larges passwords

A salt or any other thing which is send in plain tekst to the user will prevent an attacker of sniffing let's say salt and userid and thus brute force sha1 with userid + unknown + salt or any other combination.

I'm also not aware of sha1 being susceptable to least or most significant constructions.

OK, I hope this helps clearify the subject.
[/quote]
Logged
__PPS__
Junior Member
**

Karma: 0
Offline Offline

Posts: 32


View Profile
« Reply #4 on: Nov. 06, 2004, 03:16:49 PM »

Quote from: zwetph
You can however still:
1. try to guess the password
2. intercept the session


I found that there is already exist something what we talk here about: http://www.cs.ucsd.edu/users/mihir/papers/rfc2104.txt
Here's javascript implementation I wrote: http://66.11.179.15/hmac This method should be better.

Basicly, in case with passwords we get:
hash = sha1( X^B1 + sha1(X^B2 + salt))
Where B1 and B2 are 64 byte buffers of 0x5c and 0x36, respectively. X is the P, or sha1(P), and salt is the salt value, or salt+U


Quote
I'm also not aware of sha1 being susceptable to least or most significant constructions.

What does it mean??
Logged
zwetph
Guest
« Reply #5 on: Nov. 06, 2004, 06:41:07 PM »

Quote from: __PPS__
Quote from: zwetph
You can however still:
1. try to guess the password
2. intercept the session


I found that there is already exist something what we talk here about: http://www.cs.ucsd.edu/users/mihir/papers/rfc2104.txt
Here's javascript implementation I wrote: http://66.11.179.15/hmac This method should be better.

Basicly, in case with passwords we get:
hash = sha1( X^B1 + sha1(X^B2 + salt))
Where B1 and B2 are 64 byte buffers of 0x5c and 0x36, respectively. X is the P, or sha1(P), and salt is the salt value, or salt+U


Quote
I'm also not aware of sha1 being susceptable to least or most significant constructions.

What does it mean??


What I meant by the last remark is in cryptography you can sometimes create stronger or weaker encrypted values by putting the most significant (the values that changes most, like timestamp) as the first value before encrypting. This is especially true for DES3. But to my knowledge not for SHA-1.
Furthermore, I'm aware of the HMAC concept or more commonly known as keyed hashing.  It's exactly what the other examples are about. The shared secret between the user and the server is the hashed password. I say hashed password because the server should only store a hashed version of the password in it's datastore. Thus the server does not know the real password like the user does, but shares the same secret because the user has given him his hashed password when the account was created.

The suggested padding is better since this would make brute force attacks more difficult.

I ran into compatibility issues with my examples in PRADO, since client scripts don't work in Firefox. Will continue if I figured it out.
Logged
__PPS__
Junior Member
**

Karma: 0
Offline Offline

Posts: 32


View Profile
« Reply #6 on: Nov. 06, 2004, 10:40:38 PM »

Quote
I ran into compatibility issues with my examples in PRADO, since client scripts don't work in Firefox. Will continue if I figured it out.


Let me know what scripts do not work in firefox. Mine for sure work with firefox. I still cannot make my installation run all the examples without errors so that I could fix the js stuff. For a quick fix, try this

1) In "prado_validator.js" replace all occurences of "final" with something else. I replace it with "finalXXX". In firefox it's a reserved name (probably comes from Java);
2)  In "prado_validator.js" Replace all occurences of document.all[...] with document.getElementById(...)
3) In TValidator.php and TValidationSummary.php replace document.all[...] with document.getElementById(...).

For me it fixed most of the problems.
Logged
clementchen
Junior Member
**

Karma: 0
Offline Offline

Posts: 33


View Profile
« Reply #7 on: Dec. 02, 2004, 07:40:30 AM »

Quote from: zwetph
I had some trouble combining javascript with the buttons. Used a gladiator image as submit button  :?

Hi, I'm a newbie here. I don't know if this issue remains but I succeeded using the text button by replacing "CausesValidation" with "onclick" in LoginPage.tpl finally. :wink:
[Old]
Code:
<com:TButton ID="Login" Text="Login" CausesValidation="HashLogin('Form:Username', 'Form:Password');" />

[New]
Code:
<com:TButton ID="Login" Text="Login" onclick="HashLogin('Form:Username', 'Form:Password');" />
Logged
jreymol
Senior Member
***

Karma: 0
Offline Offline

Posts: 61


View Profile
« Reply #8 on: May. 31, 2005, 09:42:41 PM »

Suppose I want to validate my users with a x509 digital certificate.

I would give every authorized user a personal certificate. But, how would login page be?
Logged
haniotak
Senior Member
***

Karma: 0
Offline Offline

Posts: 76


View Profile
« Reply #9 on: Jun. 02, 2005, 02:01:40 PM »

jreymol:
There wouldn't be a login page at all, probably.

You'd have a component that detects the SSL connection, gets the username from t variables, and automatically logs the user on. Magic!
Logged
jreymol
Senior Member
***

Karma: 0
Offline Offline

Posts: 61


View Profile
« Reply #10 on: Jun. 03, 2005, 08:37:09 AM »

I don't know how to deal with that.

Anyway I have set up my apache to work with https. I think this way I can be confident username and password can travel to my server securely enough.

I'm working on a private application my users can work on through internet. It seems https is enough for me.
Logged
olav
Junior Member
**

Karma: 0
Offline Offline

Posts: 8


View Profile
« Reply #11 on: Sep. 13, 2005, 09:52:18 AM »

When I try to run the secure login example, all that comes up is a blank screen. I have the default setup of prado, and think all the paths is correct. Any ideas why the blank screen comes up?

~Olav!
Logged
Pages: [1] Print 
« previous next »
Jump to: