PDA

View Full Version : User authentication question



scooter
16 Feb 2010, 1:39 PM
Howdy all,
I've been going through all the posts but don't see exactly what I need.

Is it considered bad practice to use the built in auth that apache will give
you? I currently have apache configured to authenticate against the ldap
servers. Upon hitting the app, apache does the authentication and then
I make an ajax call to find the role that the user belongs. Everyone,
even unauthenticated users, get "user" access.

The purpose of authentication in this app it to provide a simple way to
have usernames available for history tables. It also provides access to
a few delete buttons. The app will always be on the intranet, so primary
security isn't that high on the list.

Is it better to turn off the apache auth and create an entry point that's
sole purpose is login with user/pass and authenticate against ldap?

Thanks for any design help here.

Scott

Mike Robinson
16 Feb 2010, 1:44 PM
I would go so far as to say that it is highly recommended that you use the built-in security of your server (e.g. LDAP-based) as your first and perhaps your most-important line of defense.

After all, this is an AJAX world, which means that you "bare a lot of secrets" the moment the user successfully connects and JavaScript code starts coming down. If the user is "barred at the door," and cannot even connect to your site without authorization, your position is considerably strengthened from the get-go.

You should also, of course, use https: encryption from the get-go, so that no credentials are ever passed-around "in the clear." The site should be such that a non-encrypted connection attempt is either refused, or redirected to secure.

scooter
16 Feb 2010, 1:56 PM
Thanks for the reply, Mike. I'd prefer to use apache/ldap auth, but something just
seemed off with the rest of the way I was doing the implementation.

Basically, even though you can use this as an unauthenticated user, I still force them
to provide credentials. My entry page will not remove the load mask until they are
authenticated. I couldn't think of better way to handle that. It seems everyone else
uses a user/pass form page, and then if the auth is successful, redirects to their app.

I just wanted apache to authenticate, then the app would determine the role they should
be assigned before allowing them to proceed.

Thanks,

Scott

aw1zard2
16 Feb 2010, 2:26 PM
There are a lot of tricks you can do behind the scenes to add more security.

Even though we do ajax and login form we encrypt SHA-512 the username/email and the password before sending to the server along with the php session id. And immediately after that we make a new php session id before bringing up the next page. The next page checks session id's and that the session hasn't timed out. So the first time the login form sends data over that session id is invalid cause we change it first thing. Would have to be a dang fast hack to reroute it. LOL

One of my old jobs also used to install a plug-in in browsers to get the hash of serial numbers making the system it was on it checked against a known list database. Kind of like what Microsoft does with their XP product keys you change 1 hardware piece and it throws a flag up during next activation. But that job had sensitive projects it needed the extra extra security.

I've also done the ldap auth as well it just depends on how far your willing to take the security.

My current project does the first security I described plus uses Ext. direct to poll the server to make sure the connection is live. Plus for that special key I made for the poll if it don't match with the ip it got on first login it closes the session.

:D

Gunmen
20 Feb 2010, 12:32 PM
There are a lot of tricks you can do behind the scenes to add more security.

Even though we do ajax and login form we encrypt SHA-512 the username/email and the password before sending to the server along with the php session id. And immediately after that we make a new php session id before bringing up the next page. The next page checks session id's and that the session hasn't timed out. So the first time the login form sends data over that session id is invalid cause we change it first thing. Would have to be a dang fast hack to reroute it. LOL



Can you tell me / provide me an example how you encrypt the username and password in extjs before sending it to the server and how to decrypt on the server side? I assume you need some kind of key-pair solution?

Thanks!

aw1zard2
2 Mar 2010, 2:01 PM
Can you tell me / provide me an example how you encrypt the username and password in extjs before sending it to the server and how to decrypt on the server side? I assume you need some kind of key-pair solution?

Thanks!


I made found a js util that handles sha512 that matches perfectly with php's encrypt of it.

I never decrypt it never have to. Just have to check and see if the encrypted values are equal.

I encrypt it during the click event on the login button being clicked before submitting the form values to php. Really you could use this with the password only my app requires data to be encrypted. After the first login we do use a key pair within the application. Which the javascript web app gets the key pair from a java plugin installed on each client that uses the software. Since Java can do a better secure remote link to the server. ;)



buttons:[{
text:'Login',
formBind: true,
// Function that fires when user clicks the button
handler:function(){
var enc_pass = hex_sha512(login.getForm().findField('loginPassword').getValue());

login.getForm().findField('loginPassword').setValue(enc_pass);
login.getForm().submit({
method:'POST',
waitTitle:'Connecting',
waitMsg:'Sending data...',

//*** and rest of code here ***

Gunmen
3 Mar 2010, 1:09 AM
Hi aw1zard2,

Thanks for sharing! I do understand your solution. I have some follow up questions:
- Does the hex_sha512 function use a token-key to encrypt the data? Where is it?

- What if the username / password is wrong, then the user sees his encrypted version in the text input field?

Thank again.

aw1zard2
3 Mar 2010, 9:00 AM
During on blur events I copy the original values for username only to a variable. The SHA-512 doesn't use any token-key it is just an encrypted Hash like MD5 just bigger. If the password etc is wrong it gets cleared out and the username gets set back to the original value.

In my example I just showed doing the password encrypted leaving the username alone.

:)

aw1zard2
3 Mar 2010, 9:16 AM
We also use Ext.Direct for polling from our web app to the server so we can keep track of timeouts and if someone just closes the browser window or alt-f4's out. We have it on a 30 second poll so we can keep the back end cleaned and garbage free as well as log out someone on the front end when the php session times out.

Also we do tracking of where users were so we can re-login them back into the last page they was at if they would like or they can always start at home.

Could this be overkill? Most definitely but for the projects I handle, there's never enough security to protect a person's information and/or a company's. I know we are just ahead of the curve on things.

:D

Mike Robinson
4 Mar 2010, 8:37 AM
Thanks for the reply, Mike. I'd prefer to use apache/ldap auth, but something just
seemed off with the rest of the way I was doing the implementation.
Uhh... I don't mean to sound catty here, but, "so, change your implementation." /:)

First of all, I presume you will be using "https://" anyhow. If you are "talking passwords," then this is of course a very basic prerequisite. Therefore, the confidential portions must be put into a separate virtual-host. Consider also having Apache enforce (LDAP-controlled) password security to that host.

Over an https link, you can AJAX passwords "in the clear" because you know that nothing is actually "in the clear."

The client should be identifying itself with a cookie whose value includes tamper-prevention logic which is automatically checked by the host. The secure-side will have one cookie value and the non-secure side will have another one that looks totally different.

You can also consider first sending the user to a non-AJAX page which requires the username and password, and which upon-approval delivers customized JavaScript-based content. The code which arrives on the client and executes there, is therefore tailored to what the host knows that the user is allowed to do. (But the host is cagey and distrusting, and checks all requests it receives regardless... "defense in layers.")