client side secrets

[Bas Bloemsaat]

Hi,

This maybe more of a Javascript question than PHP, but as it requires some
understanding about what is sent over the line and what not, I assume this
is the better forum to ask.

I'm building a php app, and I'm planning to use md5/hmac-md5 for the
password protection. I cannot always use ssl, for that would simplify
things, and provide much better protection.

For this to work, I need to generate a secret (no problem), and pass this to
the client (this can be done by using the md5 of the password as a symmetric
key). So far so good.

Now, to prevent someone having to type his password any time he wants to
change a password (which is doable for ordinary users, but not for admins
who do this routinely for other users), I want this secret stored in the
client, available to javascript, between pages.

A cookie isn't an option, as that's sent over the line. I was thinking to
put the application a (hidden)frame, and the secret in a variable in
another, but I have the feeling there should be an easier way. Does anyone
have an idea?

Thanks,
Bas

[David Walker]

Re: client side secrets

> Now, to prevent someone having to type his password any time he wants to[color=blue]
> change a password (which is doable for ordinary users, but not for admins
> who do this routinely for other users), I want this secret stored in the
> client, available to javascript, between pages.[/color]

Just use a different script for admins - if they are logged in as an admin
they can change any password in the database just by typing the new one in,
and possibly the admin's own old password to verify that it is an admin
logged in. Normal users can only change theirs if they can type their old
one in first and then their new one.
[color=blue]
> A cookie isn't an option, as that's sent over the line. I was thinking to
> put the application a (hidden)frame, and the secret in a variable in
> another, but I have the feeling there should be an easier way. Does anyone
> have an idea?[/color]

A hidden frame will still be accessible by viewing the source so that is not
going to provide any sort of security over a cookie.

What I do with passwords is they log in (without ssl, but security isn't
hugely important), PHP then checks that password against the value in the
database, and if it matches then use sessions (either in a cookie or as a
query string on the url) which keeps the details of what access they have on
the server - a much safer place for it to be. Every other page then just
checks the session data to make sure it is a logged on user. For changing
passwords, just ask them for their old one just to verify it is the user
changing it and they haven't just left it logged in somewhere. For admins
though, PHP can deal with verifying that it is a admin that is logged in and
the admin can change any password.

But most importantly, using javascript for password validation / storage is
not at all secure, and theres no reason you would need to do it. Keep the
password server-side except when the user has to enter the password - but
never send a password back to the page. Also, once you recieve the password
in your PHP script, hash it and only ever use the hash values - the script
should never see the password again.

Its a bit of a rethink to what you're doing, but seems to be a better way to
do what you're doing.

David

[Bas Bloemsaat]

Re: client side secrets

[color=blue]
> Just use a different script for admins - if they are logged in as an admin
> they can change any password in the database just by typing the new one[/color]
in,[color=blue]
> and possibly the admin's own old password to verify that it is an admin
> logged in. Normal users can only change theirs if they can type their old
> one in first and then their new one.[/color]
The way I see it is the following: everyone (including admins) have to type
their own password to change it. This is the usual way of doing things. But
admins also routinely change passwords of other (new) users. To have
them type their password at every opportunity is a bit much.
[color=blue]
> A hidden frame will still be accessible by viewing the source so that is[/color]
not[color=blue]
> going to provide any sort of security over a cookie.[/color]
That isn't really a problem. If they can get to the browser physically, they
can also install a keylogger or something. That's beyond my control. What I
worry about is about the communication. The scheme I was thinking about (for
encryption I use hmac-md5):

Client --------------------------------- Server

login:
*request login screen -------->
*generate secret and keep it in
sessionvariable
*encrypt secret with md5sum(pwd)
as key
<-------- *send encrypted secret
*decrypt secret if password
is entered correctly
*store secret (locally) during
session
*send md5(md5(passwor d)
+sessionid) to verify login -------->
*if md5(md5(passwor d)+sessionid)
matches with expectation, login
is succesful, else retry

password change (admin changes other users' passwords):
*encrypt(md5(ne wpassword))
using secret as key -------->
*if md5(oldpwd) matches, the
md5(newpwd) is stored

This way: the password is never sent during login. The md5(password) is only
sent hashed with the sessionid. This ensures that even that cannot be
snooped.
The md5(password) is only sent during password change, and even that's
encrypted.
[color=blue]
> But most importantly, using javascript for password validation / storage[/color]
is[color=blue]
> not at all secure, and theres no reason you would need to do it. Keep the[/color]
I don't want do that. I only use the password to generate the md5(password).
That's what I store in the DB, serverside. The client side doesn't even
store that during the session, I only want to use the secret, which is only
valid for one session.

Hope this clears things up a bit. Now I still need an elegant way to store
the secret on the client between requests :)

Regards,
Bas

[David Walker]

Re: client side secrets

> The way I see it is the following: everyone (including admins) have to
type[color=blue]
> their own password to change it. This is the usual way of doing things.[/color]
But[color=blue]
> admins also routinely change passwords of other (new) users. To have
> them type their password at every opportunity is a bit much.[/color]

Well you can decide that in your own code - if you don't want admins to have
to enter their password, just serve admins with a different form that just
asks for username and new password, and if they are logged in as admin
assume they have the access to do so.
[color=blue]
> That isn't really a problem. If they can get to the browser physically,[/color]
they[color=blue]
> can also install a keylogger or something. That's beyond my control. What[/color]
I[color=blue]
> worry about is about the communication. The scheme I was thinking about[/color]
(for[color=blue]
> encryption I use hmac-md5):[/color]

Ah right - so basically you want to encrypt with javascript before the
password leaves the computer, and use this key as the salt for the
encryption? If this is right, I understand what you're trying to do, and in
which case my previous suggestion won't do it as you realised.

Unfortunately no idea how you'd do it - a lot of people have javascript
turned off, and as far as i'm aware md5 functions aren't standard in
javascript so I think you could have a lot of problem with doing it.
Personally my site doesn't need particularly high security so I send it
unencrypted at the first stage, and keep it encrypted from then on. Even if
you can get something in javascript, it will probably be a lot of effort if
you want it to work on all browsers, and really if you need good security
you should use ssl, if you don't its probably not worth the effort.
[color=blue]
> Hope this clears things up a bit. Now I still need an elegant way to store
> the secret on the client between requests :)[/color]


You could store it anywhere in javascript really - putting it in a hidden
frame will be no more difficult for someone to see than putting it in the
middle of the main page. If you are generating some sort of random key to
use each time, then it really doesn't matter whether the user can see it or
not. You could just use the session ID really, they are unique and
accessible to both server and client easily.

If you do still want to try though then I can't be much more help.

Sorry

David

[Bas Bloemsaat]

Re: client side secrets

> Unfortunately no idea how you'd do it - a lot of people have javascript[color=blue]
> turned off, and as far as i'm aware md5 functions aren't standard in
> javascript so I think you could have a lot of problem with doing it.[/color]
You can download those here: http://pajhome.org.uk/crypt/md5/
I'd only have to port them to php as that doesn't support hmac-md5, but the
code can be pretty much reused.
[color=blue]
> You could store it anywhere in javascript really - putting it in a hidden
> frame will be no more difficult for someone to see than putting it in the
> middle of the main page. If you are generating some sort of random key to
> use each time, then it really doesn't matter whether the user can see it[/color]
or[color=blue]
> not. You could just use the session ID really, they are unique and
> accessible to both server and client easily.[/color]
I don't care if the user sees it or not. He has the password anyway. It's
the man in the middle I'm worried about. And he definately has the
sessionid.
[color=blue]
> If you do still want to try though then I can't be much more help.[/color]
Thanks for your time anyway :) Your comment made me check and spot some
things I have to think about.

Regards,
Bas

[David Walker]

Re: client side secrets

> You can download those here: http://pajhome.org.uk/crypt/md5/[color=blue]
> I'd only have to port them to php as that doesn't support hmac-md5, but[/color]
the[color=blue]
> code can be pretty much reused.[/color]

Ah yeah, looks quite good. I never realised that the code for MD5 was
actually available, which is why I didn't think you'd be easily able to add
it in javascript.
[color=blue]
> Thanks for your time anyway :) Your comment made me check and spot some
> things I have to think about.[/color]

OK. Sorry if i've been a bit negative - I do now see both what you are
trying to do and how you are going to do it. Hope its helped even in just a
little way.

Good luck

David