Do GWT support java.security ?
Jean-Philippe Côté
I'm trying to create a login panel... but I don't want to send the password with a HTTPREQUEST.asyncGet() in plain text...
I want to hash it before.. with MD5 ou SHA1... but I don't really know how to do this...
I tried this code :
MessageDigest algorithm;
try {
algorithm = MessageDigest.getInstance("MD5");
algorithm.reset();
algorithm.update((pwd.getText ()).getBytes());
messageDigest = algorithm.digest();
} catch (NoSuchAlgorithmException e) {
// TODO Auto-generated catch block
Window.alert("");
}
Window.alert("PWD: "+messageDigest.toString());
btnLoad.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
String url = GWT.getModuleBaseURL();
url += "auth.php?userName="+userName.getText()+"&pwd="+messageDigest.toString();
HTTPRequest.asyncGet(url, loginHandler);
}});
But when I compile... I got :
[ERROR] Line 18: The import java.security cannot be resolved
[ERROR] Line 19: The import java.security cannot be resolved
[ERROR] Line 78: MessageDigest cannot be resolved to a type
[ERROR] Line 80: MessageDigest cannot be resolved
[ERROR] Line 82: The method getBytes() is undefined for the type String
[ERROR] Line 84: NoSuchAlgorithmException cannot be resolved to a type
How can I make the import os java.security working...
Or if you have a better idea to hash or encode the password before sending...
Thanks
--
Jean-Philippe Côte
Sandy McArthur
they will anytime soon.
If you need to send a username/password securely I'd suggest using
HTTPS.
On Jan 31, 2:06 pm, "Jean-Philippe Côté"
Jason Essington
could either import or just create a GWT class based from one of them
to perform your hash.
A quick google found this one:
http://www.webtoolkit.info/javascript-md5.html
I plan on doing this at some point for my authentication.
But don't forget, you somehow have to get the password to the server
initially as well ...
For now, https is good enough for me.
-jason
Reinier Zwitserloot
Some notes:
- the idea that the password must at some point get to the server
(e.g. during the registration step) as was said before by jason is
FALSE - you can simply send the hash then, too. Of course, the hash is
then pretty much as good as the password, with the only advantage that
if the user is using the same password for all his sites, if this one
gets sniffed, it won't help for any of the other sites of this user.
To avoid this, hash with a factor that is guaranteed to be different
every time (like, say, the time). Of course, for the server to do the
same hashing, it needs to know the original, and then you're stuck
with how you get it there.
- md5 is broken and so is SHA-1. For practical purposes you can use
them, but if you're going to look anyway, go with SHA-256, 224, or
512.
- Even if you sort it all out, there's no way the user knows that you
have this security. As far as they know (no 'secure' logos in the
toolbar and the like) it's a plain-text event. Unless the user
inspects the whole javascript code base EVERY TIME (or uses
exclusively cached versions) he can't be sure that you don't secretly
try to rip off that password. Also, if someone hacks your system or
even just the connection and inserts his or her own javascript
(replaces your hashing script code), he can get at the password. This
is not possible with a proper SSL connection.
It's a novel idea but it's nowhere near as good as SSL encryption.
Unfortunately, that costs money if you want to avoid popups warning
that the certificate is unsigned.
Jason Essington
On Feb 1, 2007, at 1:03 AM, Reinier Zwitserloot wrote:
>
> HTTPS is the only reliable solution.
>
> Some notes:
>
> - the idea that the password must at some point get to the server
> (e.g. during the registration step) as was said before by jason is
> FALSE - you can simply send the hash then, too.
Sending a hashed password is for all intents and purposes the same as
sending the clear text password. It has to be protected via some
method. So, the password does have to get to the server some how.
generally the password itself is not stored, but a hash of it is, and
having that hash is just as good as having the password. so send it
via SSL (HTTS)
> Of course, the hash is
> then pretty much as good as the password, with the only advantage that
> if the user is using the same password for all his sites, if this one
> gets sniffed, it won't help for any of the other sites of this user.
> To avoid this, hash with a factor that is guaranteed to be different
> every time (like, say, the time). Of course, for the server to do the
> same hashing, it needs to know the original, and then you're stuck
> with how you get it there.
basically the client sends a request, if the user is not
authenticated, the server sends a response stating as much and
including a salt. The server stores this salt in a session (so the
client doesn't have to return it)
The client then takes a hash of the password, adds the salt and
hashes that again, and returns it to the server. once it gets to the
server, the server retrieves the hashed password from the database,
adds the salt (previously sent to the client) hashes again and
compares with the response from the client.
This way, any interception of the hashed value is useless because
presumably the salt will be different each time.
Again, this transaction can happen via SSL making it that much more
secure.
> - md5 is broken and so is SHA-1. For practical purposes you can use
> them, but if you're going to look anyway, go with SHA-256, 224, or
> 512.
True, but for most peoples intents MD5 or SHA-1 are still overkill.
The effort required to break them outweighs the value of getting the
login to someone's web account (in most cases).
SSL is still simpler to use and is probably plenty secure for most
purposes.
> - Even if you sort it all out, there's no way the user knows that you
> have this security. As far as they know (no 'secure' logos in the
> toolbar and the like) it's a plain-text event. Unless the user
> inspects the whole javascript code base EVERY TIME (or uses
> exclusively cached versions) he can't be sure that you don't secretly
> try to rip off that password. Also, if someone hacks your system or
> even just the connection and inserts his or her own javascript
> (replaces your hashing script code), he can get at the password. This
> is not possible with a proper SSL connection.
/me whispers "Man in the Middle"
it is possible, but still the effort outweighs the gain in most cases.
> It's a novel idea but it's nowhere near as good as SSL encryption.
> Unfortunately, that costs money if you want to avoid popups warning
> that the certificate is unsigned.
There are CAs that will provide a SSL certificate for a pretty small
amount of money, so it isn't out of the reach of most people.
-jason
Reinier Zwitserloot
On Feb 1, 6:21 pm, Jason Essington <jason.essing...@gmail.com> wrote:
> Sending a hashed password is for all intents and purposes the same as
> sending the clear text password. It has to be protected via some
> method. So, the password does have to get to the server some how.
> generally the password itself is not stored, but a hash of it is, and
> having that hash is just as good as having the password. so send it
> via SSL (HTTS)
>
Do you proofread your replies? I said the exact same thing. It's still
more secure than a plaintext password because users tend to use the
same password on multiple sites. As I already said.
>
> basically the client sends a request, if the user is not
> authenticated, the server sends a response stating as much and
> including a salt. The server stores this salt in a session (so the
> client doesn't have to return it)
>
salt, server-sent timestamp. Potayto potahto.
>
> True, but for most peoples intents MD5 or SHA-1 are still overkill.
> The effort required to break them outweighs the value of getting the
> login to someone's web account (in most cases).
>
He's going to look for an implementation. Why NOT look for the
currently still secure hash algos?
>
> /me whispers "Man in the Middle"
>
Didn't I insinuate that?
> it is possible, but still the effort outweighs the gain in most cases.
>
No, hanging custom javascript in there is quite easy. SSL wins.