Re: questions on Login Security FAQ

[JasonG]

> I think you're trying to argue that your solution will stop the hacker
> because he'll never guess that he's supposed to hash username+password
> instead of just password.

No.  I'm making the point that in a well organized environment, the
database and application are separated and through division of
responsibility your database people don't have access to your
application just as your application people don't have access to your
database (beyond what has been granted for operation of the
application, obviously).  Your hacker doesn't have to be someone from
the outside and it doesn't have to be a developer.  It could just as
easily be a DBA (or someone acting the part).  A DBA working alone
will typically not have the knowledge of what goes into the hash - nor
will a typical DBA even have the knowledge of how to produce the
hash.  By just hashing the password you make it pretty easy for him to
get in using skills even a novice DBA already has (i.e. select,
insert).  Your entire argument seems to be based on the assumption
that your attacker is intelligent and skilled and a developer -
without consideration for the fact that there are many more people out
there who are none of these things but who may be motivated to hack
into an application just the same.  No matter what you do - yes there
will always be some way your system can become compromised.  The goal
of security is to make that job as difficult as possible without over-
encumbering the application itself.  IMHO if your application is
deployed using division of responsibility best practices, then you
should take advantage of that fact by ensuring your attacker requires
knowledge of more than just one piece of the puzzle in order to break
in.  I think assuming your attacker will only come from one direction
or that your attacker is only after your password or that your
attacker will always be someone skilled at hacking or a developer is
foolish.  Why make it easy for even an unskilled DBA to break in with
no knowledge of how the application or its security?

 > Given a username + a salt + a hash of (salt+username+password),
**You
> CANNOT change any one of those individually without knowing all of
> them!**
>
> So, there IS NO WAY to change a username, unless the user enters their
> password.

Right.  Exactly.  In most real-life production systems, this is
perfectly acceptable, and in fact it is often desired.


As for the "fear mongering"... it was a simple and perfectly relevant
question for this thread.  Has anyone (and this means other people as
well as Reinier) heard of a commercial or otherwise fully supported
Java implementation of BCrypt?  The reason for this question is also
simple --> jBCrypt in its current state is a hard sell to any
regulated organization's legal/audit department.  I'm not bashing
BCrypt.  I'm not saying it is a bad product or a weak algorithm or
that it should be avoided.  I'm simply asking if there exists a Java
implementation that is a little easier for legal/audit to swallow that
jBCrypt.  If the answer is "no", then just say so.  There is no need
for insults or name-calling.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

Answers inline.

On Sep 22, 3:36 pm, JasonG <[EMAIL PROTECTED]> wrote:
> Dearest Reinier,
>
> I'm a little perturbed by your response.
>
> Let's start with session handling.  I had initially made a point that
> if you are using a J2EE back end, then you don't have to worry about
> handling session IDs because that is pretty much handled for you.

No, I said that you have to worry about session id security,
regardless of who sets it. This IS a security related post, isn't it?

> Are you advising GWT developers to come up
> with their own session key handling when using a J2EE back end?  (A
> simple "yes" or "no" will do).

Security isn't a yes/no proposal.

I suggest you do a little investigation and e.g. make sure that your
back end doesn't try to stuff session ID into the URL if cookies are
disabled.

>
> Next - on to hash input.  Again, I'd like to steer away from the
> "BCrypt solves world hunger" argument and focus on my original advice,

BCrypt merely adds some measurable security which is useful when you
don't know what you're doing. There is a reason I've been strenuously
suggesting it to you.


> which was to hash more than just a password.  One reason for this
> argument stems from my understanding that, generally speaking, "more
> is better" where key material is concerned (hence longer passwords are
> better?)...  and if you are going to encrypt a password anyway, you
> can leverage that same mechanism to validate additional important
> information (such as a user's login, role, etc...).  Let's take a look
> at a possible scenario where the person cracking into your system
> (perhaps a DBA) is after something other than your password - maybe
> that something is to invoke some sort of function rather than obtain
> data in the database.  Whatever that something is, let's assume for a
> moment that it is easiest obtained through the administrative role
> within the application.  Somehow this person has managed to gain
> access to the user table in your database server (but not your app
> server), and copies his hashed password into the administrators
> password field.  What happens next?  Can he now get into the
> application as the administrator?  Answer:  Most likely "YES".  Why?
> Because the hashed password used only the cleartext password (+ random
> salt) as key material.  Unless I have overlooked something, even
> BCrypt does not prevent this problem.  He didn't even have to guess
> your password in order to hack into the admin account for your
> application.

See, that doesn't even make sense. You make two non-sensical points,
and no good ones.

1. If your users table is compromised, *YOUR USERS TABLE IS
COMPROMISED*. If he can set password, he can set user. Duh.

2. Aside from being void due to the point above, you are arguing
security by obscurity, which sucks, and there is no obscurity to speak
of in the first place. Either the attacker knows your hash scheme and
he can hash username+password just as easily as just a password, or he
doesn't, and he has to guess all parameters to the hashing scheme.
There are a lot of them:

 - salt length
 - where's the salt stored? prefix or postfix, or separate field?
 - which hashing algorithm is used?
 - what initialization values were used to set up the algorithm?
 - which information was used to create the hash?

I think you're trying to argue that your solution will stop the hacker
because he'll never guess that he's supposed to hash username+password
instead of just password. This is exactly my point: Thinking that
you're actually making things better which such a tiny roadbump is
exactly what screws you over; your security approach is like tossing
peas at a steamroller to try and impede its progress. You build a big
wall, and you don't get distracted by pointless exercises. "More isn't
better" at all. Especially if you don't know what you are doing. Get
it right once, and then stop worrying. In other words: Use BCrypt, and
don't complicate matters.

> (it really is not a big deal to
> regen a password hash on a username change so I have to say that is a
> pretty weak argument).

It's a huge deal.

Because you can't.

Given a username + a salt + a hash of (salt+username+password), **You
CANNOT change any one of those individually without knowing all of
them!**

So, there IS NO WAY to change a username, unless the user enters their
password. Let's say you are changing someone's username because he
asks you to in an email. You can't do it without mailing back if he'd
like to provide you a password. Your previously suggested potential
scheme of hashing in everything in the users table is even worse.
While the pain of locking in usernames forever is manageable, that's
the exception, and not the rule.

>
> On a final note - I read up on jBCrypt and it looks great, but   I
> would, however, add a concern that jBCrypt is currently a version 0.2
> product produced by an individual, with a license containing no sort
> of warranty.

I'm really getting

Re: questions on Login Security FAQ

[alex.d]

On 22 Sep., 15:36, JasonG <[EMAIL PROTECTED]> wrote:
> Most likely "YES".  Why?
> Because the hashed password used only the cleartext password (+ random
> salt) as key material.
I think you are missing Reinier's point JasonG. Adding username or
whatsoever information to the pass doesn't bring you ANY additional
security AT ALL. It just doesn't - that's what salt is for. It's
making stuff like renaming users etc. harder. But I also don't see how
this can hurt(don't really get Reinier's "collision-point") so if you
really, really, really wan't to do it - it's up to you. Just don't
convince the others to do something completely unnecessary.

> On a final note - I read up on jBCrypt and it looks great, but   I
> would, however, add a concern that jBCrypt is currently a version 0.2
> product produced by an individual, with a license containing no sort
> of warranty.  This is fantastic for average Joe building a web
> application at home or for open source projects - but impractical (and
> possibly not even an option) for anyone building applications for
> financial, insurance, health care, government, or any other highly
> regulated vertical.  There's that whole indemnity issue the lawyers
> and auditors will usually fight over unless they have already approved
> it.
True. Only goverment-approved algorithms can be used in such
structures and Bcrypt is not among them as far as i know. But most of
the developers will be more than satisfied to have it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[JasonG]

Dearest Reinier,

I'm a little perturbed by your response.

Let's start with session handling.  I had initially made a point that
if you are using a J2EE back end, then you don't have to worry about
handling session IDs because that is pretty much handled for you.  You
continue to make some sort of cryptic (pardon the pun) response to
this.  Let's try a straightforward question in hopes of a
straightforward answer: Are you advising GWT developers to come up
with their own session key handling when using a J2EE back end?  (A
simple "yes" or "no" will do).

Next - on to hash input.  Again, I'd like to steer away from the
"BCrypt solves world hunger" argument and focus on my original advice,
which was to hash more than just a password.  One reason for this
argument stems from my understanding that, generally speaking, "more
is better" where key material is concerned (hence longer passwords are
better?)...  and if you are going to encrypt a password anyway, you
can leverage that same mechanism to validate additional important
information (such as a user's login, role, etc...).  Let's take a look
at a possible scenario where the person cracking into your system
(perhaps a DBA) is after something other than your password - maybe
that something is to invoke some sort of function rather than obtain
data in the database.  Whatever that something is, let's assume for a
moment that it is easiest obtained through the administrative role
within the application.  Somehow this person has managed to gain
access to the user table in your database server (but not your app
server), and copies his hashed password into the administrators
password field.  What happens next?  Can he now get into the
application as the administrator?  Answer:  Most likely "YES".  Why?
Because the hashed password used only the cleartext password (+ random
salt) as key material.  Unless I have overlooked something, even
BCrypt does not prevent this problem.  He didn't even have to guess
your password in order to hack into the admin account for your
application.

However... if the hashed password had been formed using username
+password input as I suggested in the beginning, then the copied
hashed password in the above example will not work.  The attempt to
hack into the admin account will fail because the password will only
validate if used with the correct username.  Note also that the same
mechanism could be used to validate other information such as a
person's role.  Think of it as a parallel to the MD5 or PGP signatures
used to validate downloads and perhaps you will see my point.

So those were my two pieces of additional advice and I'm sorry but I
still don't see any reason to withdraw them.  Java app servers do a
half-decent job of session ID management and I will continue to use
them until I hear otherwise.  As for the username+password argument...
true, you made a valid point that a salted hash does not give you an
easy "lookup token", but I also think the benefit of credential
validation should not be overlooked even if it means changing your
username is slightly more complex (it really is not a big deal to
regen a password hash on a username change so I have to say that is a
pretty weak argument).

On a final note - I read up on jBCrypt and it looks great, but   I
would, however, add a concern that jBCrypt is currently a version 0.2
product produced by an individual, with a license containing no sort
of warranty.  This is fantastic for average Joe building a web
application at home or for open source projects - but impractical (and
possibly not even an option) for anyone building applications for
financial, insurance, health care, government, or any other highly
regulated vertical.  There's that whole indemnity issue the lawyers
and auditors will usually fight over unless they have already approved
it.  I would be interested in knowing if anyone has heard of a
commercial or otherwise fully supported Java implementation of BCrypt.

thanks,

J


On Sep 19, 8:15 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> Answers inline...
>
> On Sep 19, 3:12 pm, JasonG <[EMAIL PROTECTED]> wrote:
>
> > First of all, I don't understand your (A) response.   I said "you
> > don't need to worry so much about passing session IDs since the app
> > server will pretty much handle that for you"... and your response
> > seems to just reiterate what I said - but you stated it in a manner as
> > though you were disagreeing with me.  I don't get it.
>
> From a security point of view, which is what this thread is about, who
> does the sessionid passing is mostly immaterial. It should also be
> noted that the first servlet engine for tomcat started the boneheaded
> 'sessionid in the URL' security fart, so the userbase size of a j2ee
> container is no guarantee that the security is sorted out properly.
>
>
>
> > Secondly, BCrypt is not mentioned in the original author's post at
> > all, nor does it seem to be mentioned in the linked guide to
> > security.
>
>

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

I have seen a number of independent reviews of BCrypt, I have talked
to security people I trust, and, for the big finale: I reviewed it
myself.

My assessment of BCrypt is: It's as secure as blowfish. I have also
reviewed blowfish, but, that's a bit above my station. Fortunately,
blowfish is designed by Bruce Schneier, -and- gone through a serious
amount of peer review, so if you don't trust Blowfish, then you don't
trust anything, and the only way to have piece of mind is become an
expert crypto researcher and review -everything- yourself. Feel free
to, but I think we're edging just -a tad- away from the intents of the
LoginSecurityFAQ (namely: Practicality).

BCrypt is not really a 'hash' in the traditional sense. Hashes are
designed to have two properties. In order of importance:

A) It is effectively impossible to generate some content which so
happens to hash to the same value as given content, other than brute
forcing.

B) It is fast to calculate the hash.


B is not unimportant. For example, git names every last little thing
you do with a SHA-1 hash. If you go and checkout a couple of gigs
worth of project, you really don't want that process to take
significantly longer just because your CPU is choking on all the
hashing it needs to do.


Unfortunately, for password hashing, B is really bad. You want a hash
which is -slow- to calculate. Which makes this a bit of a niche; there
aren't many places where you really want slow hashing. (The reason
slow hashing is good for password hashing, is because it makes the
creation of 'rainbow tables' and brute forcing a limited set of likely
passwords impossible or at least very very expensive).

That principle is what BCrypt was built around: You can configure the
salt factor size, which has very direct consequences for calculation
time. The default is 10, but if you crank that up to, say, 25, then
just calculating one hash takes literally years on a standard CPU. The
idea is to set it to the highest value your CPU can handle without
getting bogged down / what you need. I've gone with the standard 10
which is already extremely secure, but if you have very very sensitive
data, you can go for 12 to 15. (If you read this as: Longer passwords
take longer to hash, don't worry - that's not the case. The time to
calculate is dependent on solely on the size of the input salt factor,
which you set).


Assuming the algorithms are up to snuff, BCrypt beats SHA-256 just
because its a lot slower (and, very useful, -configurably- slower).


On Sep 20, 2:23 pm, al0 <[EMAIL PROTECTED]> wrote:
> I have not seen any proof that BCrypt works :) Yews, the authors
> stated that it is great, but who believes to authors? Have you seen
> any independent assesment of BCrypt? Or it comparision with other
> modern hashes (e.g. SHA-256)?
>
> On Sep 20, 2:15 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
>
> > Answers inline...
>
> > On Sep 19, 3:12 pm, JasonG <[EMAIL PROTECTED]> wrote:
>
> > > First of all, I don't understand your (A) response.   I said "you
> > > don't need to worry so much about passing session IDs since the app
> > > server will pretty much handle that for you"... and your response
> > > seems to just reiterate what I said - but you stated it in a manner as
> > > though you were disagreeing with me.  I don't get it.
>
> > From a security point of view, which is what this thread is about, who
> > does the sessionid passing is mostly immaterial. It should also be
> > noted that the first servlet engine for tomcat started the boneheaded
> > 'sessionid in the URL' security fart, so the userbase size of a j2ee
> > container is no guarantee that the security is sorted out properly.
>
> > > Secondly, BCrypt is not mentioned in the original author's post at
> > > all, nor does it seem to be mentioned in the linked guide to
> > > security.
>
> > Huh? (j)BCrypt is the first link mentioned on the LoginSecurityFAQ. I
> > didn't just add that - that's been there since I posted the second
> > draft, a long long time ago. It wasn't mentioned in the original
> > author's post, which is exactly why *I* mentioned it. BCrypt is a
> > fantastic idea. You should be using it when storing passwords in a
> > database.
>
> > >  I was not intending to write an all encompassing guide here
> > > but perhaps I should have been a little more clear.  I said "in
> > > addition to what others have said" and "regardless of which hash
> > > algorithm".  Put those two together and this was meant to be taken
> > > as:  it doesn't hurt to concatenate the username+password+some-other-
> > > string on hashed passwords stored in the DB, regardless of algorithm.
>
> > No - you don't get it, evidently.
>
> > 1) You -cant- query the database for HASH(username+password), because
> > if that worked, you by definition have really bad saltless hashing. So
> > what's the point, then? Why store the username as well? You're just
> > making it harder to rename usernames (bad), and...
>
> > 2) You risk collisions. Ass

Re: questions on Login Security FAQ

[Ed]

I like JaSypt, works fine and very friendly.
Has some nice Spring integration features such that you can store the
hashed value of some password in the spring property file instead of
the plain password. Can be useful...

It sounds like I am having JaSypt shares :( ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[al0]

I have not seen any proof that BCrypt works :) Yews, the authors
stated that it is great, but who believes to authors? Have you seen
any independent assesment of BCrypt? Or it comparision with other
modern hashes (e.g. SHA-256)?

On Sep 20, 2:15 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> Answers inline...
>
> On Sep 19, 3:12 pm, JasonG <[EMAIL PROTECTED]> wrote:
>
> > First of all, I don't understand your (A) response.   I said "you
> > don't need to worry so much about passing session IDs since the app
> > server will pretty much handle that for you"... and your response
> > seems to just reiterate what I said - but you stated it in a manner as
> > though you were disagreeing with me.  I don't get it.
>
> From a security point of view, which is what this thread is about, who
> does the sessionid passing is mostly immaterial. It should also be
> noted that the first servlet engine for tomcat started the boneheaded
> 'sessionid in the URL' security fart, so the userbase size of a j2ee
> container is no guarantee that the security is sorted out properly.
>
>
>
> > Secondly, BCrypt is not mentioned in the original author's post at
> > all, nor does it seem to be mentioned in the linked guide to
> > security.
>
> Huh? (j)BCrypt is the first link mentioned on the LoginSecurityFAQ. I
> didn't just add that - that's been there since I posted the second
> draft, a long long time ago. It wasn't mentioned in the original
> author's post, which is exactly why *I* mentioned it. BCrypt is a
> fantastic idea. You should be using it when storing passwords in a
> database.
>
> >  I was not intending to write an all encompassing guide here
> > but perhaps I should have been a little more clear.  I said "in
> > addition to what others have said" and "regardless of which hash
> > algorithm".  Put those two together and this was meant to be taken
> > as:  it doesn't hurt to concatenate the username+password+some-other-
> > string on hashed passwords stored in the DB, regardless of algorithm.
>
> No - you don't get it, evidently.
>
> 1) You -cant- query the database for HASH(username+password), because
> if that worked, you by definition have really bad saltless hashing. So
> what's the point, then? Why store the username as well? You're just
> making it harder to rename usernames (bad), and...
>
> 2) You risk collisions. Assuming that the idea is that this username
> +password combo is somehow a unique key, collisions can happen, and
> that's no good.
>
> But mostly:
>
> 3) my advice is: Use BCrypt. Your advice is: hash on username+password
> instead of just password, which is much worse than listening to me.
> Your point is basically: If you forget to listen to any (good) advice,
> then listen to MY advice. This makes no sense; the premise was
> already: Programmer did not listen to ANY advice. We've got three
> options here:
>
> A) Programmer doesn't listen to advice. Okay. We can chat here until
> the end of days, but he's not listening. Shame, but, we can't stop
> him.
>
> B) Programmer listens to the only advice that mattered: He uses
> BCrypt. Peachy. Your advice is now irrelevant and in fact slightly
> bad: He just lost the ability to rename his username and needs the
> username in his check routine which clutters his parameter lists.
>
> C) Programmer wanted to listen to advice but the chatter is starting
> to confuse him, and he turns into #A: He stops reading and just goes
> his own way, most likely doing it very wrong. This is important, as
> java tends to suffer a lot form this principle: Don't overwhelm people
> with 15 answers. Just give the best answer, and if that particular
> answer doesn't fit the asker's needs, let him get back to you about
> that. Don't throw half a book at him, especially if most of the advice
> in it is pretty much irrelevant or useless. That's another very good
> reason why you shouldn't mention your username+password hashing
> scheme. It doesn't add anything useful to the discussion: Either the
> user is doing his salt/hashing correctly, and your scheme doesn't add
> anything, or he's not doing it correctly, and your scheme adds very
> very little.
>
> > Why?   Because if you happen to be using a weak algorithm or even a
> > strong one for which a weakness is later discovered, you are better
> > off
>
> Just to set you straight on this one: If BCrypt's salt/hash concept is
> somehow broken, then a username+password hash is equally or even worse
> broken; BCrypt already uses different source material for the same
> passwords by different users. This is like screwing a highschool
> locker padlock on a $10,000 dollar safe door. If someone is going to
> get access to the safe's contents, you can be certain the padlock
> didn't stop the criminal for even a second. He either bypassed the
> lock entirely, or he got the code from someone, or he actually can
> pick locks; and if he can pick a safe, he can open that padlock in an
> instant.
>
> In the mean time, the padlock, which has

Re: questions on Login Security FAQ

[Ed]

> So, that very shallow review says: It's all good. But no guarantees on
> the jasypt author's security chops.

Thanks Reinier (your pointers are exactly how I use it :) )


-- Ed
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Ian Bambury]

>
>  -- Reinier "gently nudging the casual reader back onto the straight
> and narrow with a velvet touch" Zwitserloot


I think the 'people person' quote was closer :-)

Ian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

Answers inline...

On Sep 19, 3:12 pm, JasonG <[EMAIL PROTECTED]> wrote:
> First of all, I don't understand your (A) response.   I said "you
> don't need to worry so much about passing session IDs since the app
> server will pretty much handle that for you"... and your response
> seems to just reiterate what I said - but you stated it in a manner as
> though you were disagreeing with me.  I don't get it.

>From a security point of view, which is what this thread is about, who
does the sessionid passing is mostly immaterial. It should also be
noted that the first servlet engine for tomcat started the boneheaded
'sessionid in the URL' security fart, so the userbase size of a j2ee
container is no guarantee that the security is sorted out properly.

>
> Secondly, BCrypt is not mentioned in the original author's post at
> all, nor does it seem to be mentioned in the linked guide to
> security.

Huh? (j)BCrypt is the first link mentioned on the LoginSecurityFAQ. I
didn't just add that - that's been there since I posted the second
draft, a long long time ago. It wasn't mentioned in the original
author's post, which is exactly why *I* mentioned it. BCrypt is a
fantastic idea. You should be using it when storing passwords in a
database.

>  I was not intending to write an all encompassing guide here
> but perhaps I should have been a little more clear.  I said "in
> addition to what others have said" and "regardless of which hash
> algorithm".  Put those two together and this was meant to be taken
> as:  it doesn't hurt to concatenate the username+password+some-other-
> string on hashed passwords stored in the DB, regardless of algorithm.

No - you don't get it, evidently.

1) You -cant- query the database for HASH(username+password), because
if that worked, you by definition have really bad saltless hashing. So
what's the point, then? Why store the username as well? You're just
making it harder to rename usernames (bad), and...

2) You risk collisions. Assuming that the idea is that this username
+password combo is somehow a unique key, collisions can happen, and
that's no good.

But mostly:

3) my advice is: Use BCrypt. Your advice is: hash on username+password
instead of just password, which is much worse than listening to me.
Your point is basically: If you forget to listen to any (good) advice,
then listen to MY advice. This makes no sense; the premise was
already: Programmer did not listen to ANY advice. We've got three
options here:

A) Programmer doesn't listen to advice. Okay. We can chat here until
the end of days, but he's not listening. Shame, but, we can't stop
him.

B) Programmer listens to the only advice that mattered: He uses
BCrypt. Peachy. Your advice is now irrelevant and in fact slightly
bad: He just lost the ability to rename his username and needs the
username in his check routine which clutters his parameter lists.

C) Programmer wanted to listen to advice but the chatter is starting
to confuse him, and he turns into #A: He stops reading and just goes
his own way, most likely doing it very wrong. This is important, as
java tends to suffer a lot form this principle: Don't overwhelm people
with 15 answers. Just give the best answer, and if that particular
answer doesn't fit the asker's needs, let him get back to you about
that. Don't throw half a book at him, especially if most of the advice
in it is pretty much irrelevant or useless. That's another very good
reason why you shouldn't mention your username+password hashing
scheme. It doesn't add anything useful to the discussion: Either the
user is doing his salt/hashing correctly, and your scheme doesn't add
anything, or he's not doing it correctly, and your scheme adds very
very little.

> Why?   Because if you happen to be using a weak algorithm or even a
> strong one for which a weakness is later discovered, you are better
> off

Just to set you straight on this one: If BCrypt's salt/hash concept is
somehow broken, then a username+password hash is equally or even worse
broken; BCrypt already uses different source material for the same
passwords by different users. This is like screwing a highschool
locker padlock on a $10,000 dollar safe door. If someone is going to
get access to the safe's contents, you can be certain the padlock
didn't stop the criminal for even a second. He either bypassed the
lock entirely, or he got the code from someone, or he actually can
pick locks; and if he can pick a safe, he can open that padlock in an
instant.

In the mean time, the padlock, which has added absolutely no value to
your security setup, IS annoying you everytime you want access to the
safe. Hence, just get rid of the bloody thing, it's making it harder
for you in operation, and its making it harder for a security analyst
because it obscures the true protection measures with irrelevancy.

> A time could come when BCrypt "was" as well.

Again, your scheme adds nothing. Stop confusing people with
fearmongering talk about BCrypt someday failing. DES 

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

I don't know jasypt, so I can't make guarantees (actually, nobody can,
but you know what I mean). However, there are two good signs:

1) The API is specifically for password checking. This is a lot better
than using a generic hasher and doing the salting yourself. The
authors of the library had password hashing in mind when they wrote
it. If they did their job right, it should be good for password
hashing.

2) The API call is checkPassword(thePassword, theHash). This is the
'right' form of such a library. Contrast to e.g.
hash(thePassword).equals(theHashFromTheDB), which is the -wrong- form
(because there's no salt in that mix at all), or even hash(saltFromDB
+thePassword).equals(hashFromDB), which is probably okay, but requires
more acts on behalf of the library user, including generating a
cryptographically secure salt somehow.

So, that very shallow review says: It's all good. But no guarantees on
the jasypt author's security chops.

On Sep 19, 12:27 pm, Ed <[EMAIL PROTECTED]> wrote:
> Like Rob mentioned, always interesting to read Reinier's post :)...
>
> > B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
> > Don't think about it, you failed the test. Use tools written by the
> > experts) - is a better take on a technique called 'salt hashing',
>
> I noticed you mentioned this a few times before in this forum.
> The tool I use:http://www.jasypt.org/. I hope this is written by
> experts as well :(
>
> -- Ed
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[JasonG]

Reinier,

Thanks for the additional input.  Can I get some more clarification
from you though?

First of all, I don't understand your (A) response.   I said "you
don't need to worry so much about passing session IDs since the app
server will pretty much handle that for you"... and your response
seems to just reiterate what I said - but you stated it in a manner as
though you were disagreeing with me.  I don't get it.

Secondly, BCrypt is not mentioned in the original author's post at
all, nor does it seem to be mentioned in the linked guide to
security.  I was not intending to write an all encompassing guide here
but perhaps I should have been a little more clear.  I said "in
addition to what others have said" and "regardless of which hash
algorithm".  Put those two together and this was meant to be taken
as:  it doesn't hurt to concatenate the username+password+some-other-
string on hashed passwords stored in the DB, regardless of algorithm.
Why?   Because if you happen to be using a weak algorithm or even a
strong one for which a weakness is later discovered, you are better
off with a concatenated string than just storing the passwords "as
is"... especially for brute force attacks targeting weak password
strings such as the word "password" or "secret".  So I was stating
that I prefer to do this than to put all my trust just in the
algorithm.  By no means was I advocating to make up your own security
- I said "in addition to what others have said"... and by that I mean,
if BCrypt is the latest and greatest, then by all means - use it.
Just remember, there was a time when DES was considered the ultimate
encryption algorithm.  A time could come when BCrypt "was" as well.

I find the best "best practices" advice described in timeless generic
terms - without specifying the names of algorithms or 3rd party
libraries.  So my question to you is, could you please restate some
useful advice or a best practice in such a manner?

Thanks,

J

On Sep 18, 10:50 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> JasonG: Thanks for being a nice example of the cluelessness of your
> average programmer. You've got it all, totally, 100% backwards. Don't
> feel too insulted, you're like almost everyone else out there.
> However, you should most definitely stop handing out security advice.
> Seriously.
>
> A) J2EE doesn't magically work without session keys. It just handles
> them for you; they are still stuck in a cookie someplace. HTTP is
> stateless. A session is by necessity involved.
>
> B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
> Don't think about it, you failed the test. Use tools written by the
> experts) - is a better take on a technique called 'salt hashing',
> invented a few decades ago. With salt hashing, two people with the
> same password do not have the same hash in the database. The fact that
> you don't even know the principle of salt hashing means you're a few
> decades behind the times.
>
> C) You don't check HASH(username+password), because BCrypting 'abc123'
> and BCrypting 'abc123' again does NOT result in the same hash value!
> That's the whole point. You BCrypt('abc123') exactly once, and then
> later, you get the hash from the db and ask BCrypt to verify that
> 'abc123' was used to generate that hash. Even if you somehow solved
> this problem (by removing the salting from the equation which is very
> stupid), then there's still the birthday paradox (wikipedia that) to
> ensure that there are actual serious odds of a collision. In case of a
> collision, some random user will log in as someone else, or if you add
> a unique constraint, some user will someday pick/change his password
> and get a persistent server error. Big whoops.
>
> On Sep 18, 3:48 pm, JasonG <[EMAIL PROTECTED]> wrote:
>
> > Hi Cresteb,
>
> > I have a couple of things to add to what others have said.
>
> > 1 - I presume all of the session talk in this thread is in regards to
> > non-Java languages for the server-side.  If you are using a J2EE
> > application on the back end you don't need to worry so much about
> > passing session IDs since the app server will pretty much handle that
> > for you once authentication has been established.  In fact, you are
> > encouraged not to.
>
> > 2 - When generating a password hash to store in a DB, regardless of
> > what hash algorithm is used I will typically hash the (username
> > +password) and place that in the password field.  This offers a couple
> > of advantages.  a) you get a single "ticket" by which a user can be
> > looked up if both values are known.  b) if your data gets compromised,
> > even the passwords of users who stupidly use the same common password
> > (i.e. "password", "secret", etc...) won't show up the same in the
> > database.  To make it even better you can add another element to the
> > mix (secret+username+password) so that the same username+password in
> > different applications shows up differently in the database.
>
> > On Aug 19, 10:1

Re: questions on Login Security FAQ

[walden]

The very first axiom in security is to not have a single point of
(security) failure, which can be extended to this correlary:

"Never put all your trust in one security expert."

Trust me.. ;-)

Walden

On Sep 19, 6:27 am, Ed <[EMAIL PROTECTED]> wrote:
> Like Rob mentioned, always interesting to read Reinier's post :)...
>
> > B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
> > Don't think about it, you failed the test. Use tools written by the
> > experts) - is a better take on a technique called 'salt hashing',
>
> I noticed you mentioned this a few times before in this forum.
> The tool I use:http://www.jasypt.org/. I hope this is written by
> experts as well :(
>
> -- Ed
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Ed]

Like Rob mentioned, always interesting to read Reinier's post :)...

> B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
> Don't think about it, you failed the test. Use tools written by the
> experts) - is a better take on a technique called 'salt hashing',

I noticed you mentioned this a few times before in this forum.
The tool I use: http://www.jasypt.org/. I hope this is written by
experts as well :(

-- Ed
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

We need to invent a TCP/IP compatible cluestick on the double!

On Sep 18, 6:36 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 11:31 AM, Rob Coops <[EMAIL PROTECTED]> wrote:
> > Always fun to read a Reinier comment to pretty much anyone.
>
> > Seriously Reinier though you usualy are quite correct with your facts and
> > knowledge you might try to leave the baseball bat on the filed and not bash
> > someonce head in for a change. I would not be surprized if people are scared
> > to post here for they fear the wrath of the ever present Reinier.
>
> I don't know--Reinier was away from this group for a while and I
> wasn't the only one that missed him enough to say so publicly.  I've
> even experienced the pointy end of Reinier's missives and lived to
> tell the tale.  I think he's a valuable contributor and security is,
> as you mention below, one of those subjects that needs tough love.
>
> > On the other hand I am still looking forward to the day when fingers will
> > automaticaly be broken every time a developer codes a well known and
> > described security flaw into their application.
>
> Indeed.  A small tasering might be a good idea, too.
>
> Ian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Ian Petersen]

On Thu, Sep 18, 2008 at 11:31 AM, Rob Coops <[EMAIL PROTECTED]> wrote:
> Always fun to read a Reinier comment to pretty much anyone.
>
> Seriously Reinier though you usualy are quite correct with your facts and
> knowledge you might try to leave the baseball bat on the filed and not bash
> someonce head in for a change. I would not be surprized if people are scared
> to post here for they fear the wrath of the ever present Reinier.

I don't know--Reinier was away from this group for a while and I
wasn't the only one that missed him enough to say so publicly.  I've
even experienced the pointy end of Reinier's missives and lived to
tell the tale.  I think he's a valuable contributor and security is,
as you mention below, one of those subjects that needs tough love.

> On the other hand I am still looking forward to the day when fingers will
> automaticaly be broken every time a developer codes a well known and
> described security flaw into their application.

Indeed.  A small tasering might be a good idea, too.

Ian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Rob Coops]

Always fun to read a Reinier comment to pretty much anyone.

Seriously Reinier though you usualy are quite correct with your facts and
knowledge you might try to leave the baseball bat on the filed and not bash
someonce head in for a change. I would not be surprized if people are scared
to post here for they fear the wrath of the ever present Reinier.

On the other hand I am still looking forward to the day when fingers will
automaticaly be broken every time a developer codes a well known and
described security flaw into their application.

On Thu, Sep 18, 2008 at 4:50 PM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote:

>
> JasonG: Thanks for being a nice example of the cluelessness of your
> average programmer. You've got it all, totally, 100% backwards. Don't
> feel too insulted, you're like almost everyone else out there.
> However, you should most definitely stop handing out security advice.
> Seriously.
>
> A) J2EE doesn't magically work without session keys. It just handles
> them for you; they are still stuck in a cookie someplace. HTTP is
> stateless. A session is by necessity involved.
>
> B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
> Don't think about it, you failed the test. Use tools written by the
> experts) - is a better take on a technique called 'salt hashing',
> invented a few decades ago. With salt hashing, two people with the
> same password do not have the same hash in the database. The fact that
> you don't even know the principle of salt hashing means you're a few
> decades behind the times.
>
> C) You don't check HASH(username+password), because BCrypting 'abc123'
> and BCrypting 'abc123' again does NOT result in the same hash value!
> That's the whole point. You BCrypt('abc123') exactly once, and then
> later, you get the hash from the db and ask BCrypt to verify that
> 'abc123' was used to generate that hash. Even if you somehow solved
> this problem (by removing the salting from the equation which is very
> stupid), then there's still the birthday paradox (wikipedia that) to
> ensure that there are actual serious odds of a collision. In case of a
> collision, some random user will log in as someone else, or if you add
> a unique constraint, some user will someday pick/change his password
> and get a persistent server error. Big whoops.
>
>
> On Sep 18, 3:48 pm, JasonG <[EMAIL PROTECTED]> wrote:
> > Hi Cresteb,
> >
> > I have a couple of things to add to what others have said.
> >
> > 1 - I presume all of the session talk in this thread is in regards to
> > non-Java languages for the server-side.  If you are using a J2EE
> > application on the back end you don't need to worry so much about
> > passing session IDs since the app server will pretty much handle that
> > for you once authentication has been established.  In fact, you are
> > encouraged not to.
> >
> > 2 - When generating a password hash to store in a DB, regardless of
> > what hash algorithm is used I will typically hash the (username
> > +password) and place that in the password field.  This offers a couple
> > of advantages.  a) you get a single "ticket" by which a user can be
> > looked up if both values are known.  b) if your data gets compromised,
> > even the passwords of users who stupidly use the same common password
> > (i.e. "password", "secret", etc...) won't show up the same in the
> > database.  To make it even better you can add another element to the
> > mix (secret+username+password) so that the same username+password in
> > different applications shows up differently in the database.
> >
> > On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote:
> >
> > > Hello!
> >
> > > I have some basic questions on the Register + Login + Keep session
> > > alive process described on the Login Security FAQ.
> >
> > > I know this is a little bit offtopic, but it would be really helpful
> > > for me and other newbies if anyone can clarify some issues.
> >
> > > This is how I see the process with some questions attached, please
> > > correct it where necessary!
> >
> > > Register:
> >
> > > 1) Send username and password from client to server.
> > > Q: I guess all the sites make this step over https so anyone can sniff
> > > the password, right?
> >
> > > 2) Store in the DB the username and the hash of the password.
> >
> > > Login:
> >
> > > 1) Send username and password from client to server (again over SSL).
> >
> > > 2) Calculate the pasword's hash and look for a register in the DB that
> > > contains that username and hash combination.
> >
> > > 3) Return a session ID from server to client.
> > > Q: Is this also done through https? If not, can't it be this session
> > > id intercepted and used later to make a query as if you were other
> > > user?
> >
> > > During the session:
> >
> > > 1) For every request from the client, include the session id, so the
> > > server knows which user is sending the request and it is able to check
> > > if the session is still active.
> > > Q: Is secure eno

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

JasonG: Thanks for being a nice example of the cluelessness of your
average programmer. You've got it all, totally, 100% backwards. Don't
feel too insulted, you're like almost everyone else out there.
However, you should most definitely stop handing out security advice.
Seriously.

A) J2EE doesn't magically work without session keys. It just handles
them for you; they are still stuck in a cookie someplace. HTTP is
stateless. A session is by necessity involved.

B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
Don't think about it, you failed the test. Use tools written by the
experts) - is a better take on a technique called 'salt hashing',
invented a few decades ago. With salt hashing, two people with the
same password do not have the same hash in the database. The fact that
you don't even know the principle of salt hashing means you're a few
decades behind the times.

C) You don't check HASH(username+password), because BCrypting 'abc123'
and BCrypting 'abc123' again does NOT result in the same hash value!
That's the whole point. You BCrypt('abc123') exactly once, and then
later, you get the hash from the db and ask BCrypt to verify that
'abc123' was used to generate that hash. Even if you somehow solved
this problem (by removing the salting from the equation which is very
stupid), then there's still the birthday paradox (wikipedia that) to
ensure that there are actual serious odds of a collision. In case of a
collision, some random user will log in as someone else, or if you add
a unique constraint, some user will someday pick/change his password
and get a persistent server error. Big whoops.


On Sep 18, 3:48 pm, JasonG <[EMAIL PROTECTED]> wrote:
> Hi Cresteb,
>
> I have a couple of things to add to what others have said.
>
> 1 - I presume all of the session talk in this thread is in regards to
> non-Java languages for the server-side.  If you are using a J2EE
> application on the back end you don't need to worry so much about
> passing session IDs since the app server will pretty much handle that
> for you once authentication has been established.  In fact, you are
> encouraged not to.
>
> 2 - When generating a password hash to store in a DB, regardless of
> what hash algorithm is used I will typically hash the (username
> +password) and place that in the password field.  This offers a couple
> of advantages.  a) you get a single "ticket" by which a user can be
> looked up if both values are known.  b) if your data gets compromised,
> even the passwords of users who stupidly use the same common password
> (i.e. "password", "secret", etc...) won't show up the same in the
> database.  To make it even better you can add another element to the
> mix (secret+username+password) so that the same username+password in
> different applications shows up differently in the database.
>
> On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote:
>
> > Hello!
>
> > I have some basic questions on the Register + Login + Keep session
> > alive process described on the Login Security FAQ.
>
> > I know this is a little bit offtopic, but it would be really helpful
> > for me and other newbies if anyone can clarify some issues.
>
> > This is how I see the process with some questions attached, please
> > correct it where necessary!
>
> > Register:
>
> > 1) Send username and password from client to server.
> > Q: I guess all the sites make this step over https so anyone can sniff
> > the password, right?
>
> > 2) Store in the DB the username and the hash of the password.
>
> > Login:
>
> > 1) Send username and password from client to server (again over SSL).
>
> > 2) Calculate the pasword's hash and look for a register in the DB that
> > contains that username and hash combination.
>
> > 3) Return a session ID from server to client.
> > Q: Is this also done through https? If not, can't it be this session
> > id intercepted and used later to make a query as if you were other
> > user?
>
> > During the session:
>
> > 1) For every request from the client, include the session id, so the
> > server knows which user is sending the request and it is able to check
> > if the session is still active.
> > Q: Is secure enough just sending the session ID in order to identify
> > the user?
> > Q: The same as above...should it be sent through https?
>
> > 2) Check if the session ID is valid or not. If its valid, send the
> > response with the data of the associated user.
> > Q: Is it also recommended to send a new session ID on each request so
> > we increase the security?
>
> > Please, feel free to suggest me any document related with this topic.
>
> > Thanks is advance!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

Boy, you guys are a stubborn lot aren't you?

MD5 doesn't change the facts of the case in any significant way.

MD5 hashing on the client is still a pain in the behind, and it's
still not worth it. Forget, for a moment, that it's also a weaker hash
algorithm.

It's still more to download, more CPU processing, and all for a teensy
tiny amount of gain. It also remains highly unpractical until someone
rolls out a library for GWT and does some speed and download size
tests so we've got some tangibles to talk about. Until then, the login
security FAQ should not be changed.



On Sep 18, 9:34 am, "alex.d" <[EMAIL PROTECTED]> wrote:
> What about "easy"-hashing on the client side like for example md5?
> Sure, lately there were several reports about possibilities to crack
> it quicker than expected(a few hours or even minutes) but i haven't
> seen any working tool to make it work yet. So hasing with md5 on the
> client side, and than with BCrypt on the server, should eliminate
> probably 90% of the attack attempts. And if somebody is ready to go
> the hard way, well, then there is probably not that much you can do
> about it - if somebody want's to hack you - they will succeed.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[JasonG]

Hi Cresteb,

I have a couple of things to add to what others have said.

1 - I presume all of the session talk in this thread is in regards to
non-Java languages for the server-side.  If you are using a J2EE
application on the back end you don't need to worry so much about
passing session IDs since the app server will pretty much handle that
for you once authentication has been established.  In fact, you are
encouraged not to.

2 - When generating a password hash to store in a DB, regardless of
what hash algorithm is used I will typically hash the (username
+password) and place that in the password field.  This offers a couple
of advantages.  a) you get a single "ticket" by which a user can be
looked up if both values are known.  b) if your data gets compromised,
even the passwords of users who stupidly use the same common password
(i.e. "password", "secret", etc...) won't show up the same in the
database.  To make it even better you can add another element to the
mix (secret+username+password) so that the same username+password in
different applications shows up differently in the database.

On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I have some basic questions on the Register + Login + Keep session
> alive process described on the Login Security FAQ.
>
> I know this is a little bit offtopic, but it would be really helpful
> for me and other newbies if anyone can clarify some issues.
>
> This is how I see the process with some questions attached, please
> correct it where necessary!
>
> Register:
>
> 1) Send username and password from client to server.
> Q: I guess all the sites make this step over https so anyone can sniff
> the password, right?
>
> 2) Store in the DB the username and the hash of the password.
>
> Login:
>
> 1) Send username and password from client to server (again over SSL).
>
> 2) Calculate the pasword's hash and look for a register in the DB that
> contains that username and hash combination.
>
> 3) Return a session ID from server to client.
> Q: Is this also done through https? If not, can't it be this session
> id intercepted and used later to make a query as if you were other
> user?
>
> During the session:
>
> 1) For every request from the client, include the session id, so the
> server knows which user is sending the request and it is able to check
> if the session is still active.
> Q: Is secure enough just sending the session ID in order to identify
> the user?
> Q: The same as above...should it be sent through https?
>
> 2) Check if the session ID is valid or not. If its valid, send the
> response with the data of the associated user.
> Q: Is it also recommended to send a new session ID on each request so
> we increase the security?
>
> Please, feel free to suggest me any document related with this topic.
>
> Thanks is advance!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Ravi M]

> If you want to be sure you can use MD5 and SHA1 (both considered
> weak now) if no other hash-algorithms like SHA256 are available.

FYI, post #5 on this thread:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/59f3aafcf4951523/83edc30eabccc671

says:

> After some more research I did not find a bcrypt implementation in
> JavaScript but there are implementations for  MD4, MD5, SHA1 at
> http://pajhome.org.uk/crypt/md5/ and an implementation for SHA-256 at
> http://anmar.eu.org/projects/jssha2/

In fact, the whole thread is probably of interest to anyone who is
interested in this one.

Regards

Ravi

On Sep 18, 12:54 pm, Lothar Kimmeringer <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> alex.d schrieb:
>
> > What about "easy"-hashing on the client side like for example md5?
> > Sure, lately there were several reports about possibilities to crack
> > it quicker than expected(a few hours or even minutes) but i haven't
> > seen any working tool to make it work yet.
>
> You can't "decrypt" a hash, but you can find a text that
> lead to the same hash-value as the original password does.
> So all you need is a dictionary of all possible hash-values
> and a text that lead to this hash-value. Nowerdays storage-
> medias can hold this number of entries, so there is no
> special tool necessary; a simple database does the trick.
>
> > So hasing with md5 on the
> > client side, and than with BCrypt on the server, should eliminate
> > probably 90% of the attack attempts.
>
> If you want to be sure you can use MD5 and SHA1 (both considered
> weak now) if no other hash-algorithms like SHA256 are available.
> It's quite unlikely to find a text easily that lead to the same
> hash-values for MD5 and SHA1 like the original password did.
> This can be considered as a temporary solution until other
> hashing algorithms like SHA256 have been found its way into
> the cryptography libraries out there.
>
> > And if somebody is ready to go
> > the hard way, well, then there is probably not that much you can do
> > about it - if somebody want's to hack you - they will succeed.
>
> NPI: Strange point of view. I hope you're not working for a website
> where I place orders using my credit-cards.
>
> Regards, Lothar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[al0]

I dare to say that SHA1-weakness is mostly of theoretical value. It is
secure enough for any practicaly purpose (save probably digital
signing of documents with multiyear lifespan, and protecting of
extremely sensitive information that may attract attackers that have
in their disposision supercomputers or networks with thousands of
computers). so it is still suitable for client-side password hashing -
anyway for extemely sensitive application more strict (then client
hashing)measures are required.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Lothar Kimmeringer]

alex.d schrieb:
> 
>>> And if somebody is ready to go
>>> the hard way, well, then there is probably not that much you can do
>>> about it - if somebody want's to hack you - they will succeed.
>> NPI: Strange point of view. I hope you're not working for a website
>> where I place orders using my credit-cards.
> 
> Every piece of code written by man has errors. With enough time and
> resources it is possible to find this errors and exploit them.

True but it's not an argument to make things easier just because
a good hacker will break it anyway (IMHO).


Regards, Lothar

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[alex.d]

> Hi Alex,
>
> alex.d schrieb:
>
> > What about "easy"-hashing on the client side like for example md5?
> > Sure, lately there were several reports about possibilities to crack
> > it quicker than expected(a few hours or even minutes) but i haven't
> > seen any working tool to make it work yet.
>
> You can't "decrypt" a hash, but you can find a text that
> lead to the same hash-value as the original password does.
> So all you need is a dictionary of all possible hash-values
> and a text that lead to this hash-value. Nowerdays storage-
> medias can hold this number of entries, so there is no
> special tool necessary; a simple database does the trick.

Actually with that weakness that scientists found in md5-algorithm it
was possible to find a password(not decrypt) much quicker than by just
brute-forcing.

> > So hasing with md5 on the
> > client side, and than with BCrypt on the server, should eliminate
> > probably 90% of the attack attempts.
>
> If you want to be sure you can use MD5 and SHA1 (both considered
> weak now) if no other hash-algorithms like SHA256 are available.
> It's quite unlikely to find a text easily that lead to the same
> hash-values for MD5 and SHA1 like the original password did.
> This can be considered as a temporary solution until other
> hashing algorithms like SHA256 have been found its way into
> the cryptography libraries out there.

Exactly my point.

> > And if somebody is ready to go
> > the hard way, well, then there is probably not that much you can do
> > about it - if somebody want's to hack you - they will succeed.
>
> NPI: Strange point of view. I hope you're not working for a website
> where I place orders using my credit-cards.

Every piece of code written by man has errors. With enough time and
resources it is possible to find this errors and exploit them. Most of
the people will not have money or time to hack for example amazone. It
doesn't mean it's impossible. Any governmental structure like Homeland
security on the other side has potential to hack itself into almost
everything.

> Regards, Lothar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Lothar Kimmeringer]

Hi Alex,

alex.d schrieb:
> What about "easy"-hashing on the client side like for example md5?
> Sure, lately there were several reports about possibilities to crack
> it quicker than expected(a few hours or even minutes) but i haven't
> seen any working tool to make it work yet.

You can't "decrypt" a hash, but you can find a text that
lead to the same hash-value as the original password does.
So all you need is a dictionary of all possible hash-values
and a text that lead to this hash-value. Nowerdays storage-
medias can hold this number of entries, so there is no
special tool necessary; a simple database does the trick.

> So hasing with md5 on the
> client side, and than with BCrypt on the server, should eliminate
> probably 90% of the attack attempts.

If you want to be sure you can use MD5 and SHA1 (both considered
weak now) if no other hash-algorithms like SHA256 are available.
It's quite unlikely to find a text easily that lead to the same
hash-values for MD5 and SHA1 like the original password did.
This can be considered as a temporary solution until other
hashing algorithms like SHA256 have been found its way into
the cryptography libraries out there.

> And if somebody is ready to go
> the hard way, well, then there is probably not that much you can do
> about it - if somebody want's to hack you - they will succeed.

NPI: Strange point of view. I hope you're not working for a website
where I place orders using my credit-cards.


Regards, Lothar

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[alex.d]

What about "easy"-hashing on the client side like for example md5?
Sure, lately there were several reports about possibilities to crack
it quicker than expected(a few hours or even minutes) but i haven't
seen any working tool to make it work yet. So hasing with md5 on the
client side, and than with BCrypt on the server, should eliminate
probably 90% of the attack attempts. And if somebody is ready to go
the hard way, well, then there is probably not that much you can do
about it - if somebody want's to hack you - they will succeed.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: questions on Login Security FAQ

[Reinier Zwitserloot]

Intro note: If this post sounds condescending because it rehashes a
lot of what has been said and mostly presumes the reader is clueless
on the topic, I apologize. That is not my intent at all; I'm merely
trying to be extremely clear because, with security, you don't get a
bug report during test, you get a mob of angry users a few months into
deployment. My thanks for indulging me.


The problem with hashing on the client is that you need to include a
hash library on the client. This is non-trivial and pumps up the
download size. This is especially important if you ARE using SSL, due
to wonky caching behaviours. Sidenote: The reason a lot of websites
jump through hoops to weave in and out of SSL instead of just going
SSL whole hog isn't, usually, CPU concerns. It's the asinine crap the
browsers shove in your face when in SSL mode in a backward attempt to
protect the world from idiot web server maintainers. But I digress.
The main goal of hashing, after all, is not so much wire security, but
not leaking a big batch of passwords if you decide to copy the
production db to your notebook for some on-the-road debugging and
someone nicks it. See reddit.com founders for a few induhviduals who
screwed that up.

Assuming for a moment the web app isn't SSL:

If people were perfect security conscious users, they'd pick a
different password for all services and the difference between sending
the password over the wire or the hash is entirely moot; either will
grant you access to the webapp in question and no others. The point,
of course, is that people aren't that perfect (and it isn't fair to
blame them for this) and tend to re-use passwords, and by hashing on
the client, you sidestep this problem entirely; knowing the hash of a
user for webapp A allows you to log in as that user for webapp A. It
gives you bupkis for webapps B, C, all the way through Z, even if the
user used the same password on every single one of those. This is all
presuming you use BCrypt and you aren't a foolhardy moron who decides
to roll his own hash/salt scheme and does it wrong.

I'm still not aware of a BCrypt implementation that is halfway
workable (remember, BCrypt is explicitly designed to be slow as
molasses) on the client. The LoginSecurityFAQ was written to be
practical. I did not at the time consider client side hashing (or http
digest) practical. If there is one for JS, it should probably be
wrapped into a nice GWT library of sorts. Also, remember, there are
tons of webservices out there that don't use SSL for login, and reuse
a password at any one of those, and you've compromised all your
webapps that use that password. Remember, the vast majority of line
sniffing occurs very close to the source (open WiFi, internet cafe
router). Log in to your GWT app, google mail (not over https), and
let's say some online game, and the client side hashing, or lack
thereof, of the GWT app is utterly moot: The game or gmail already
gave away the keys to the kingdom, and in the process allows the
sniffer to log into the GWT app as well.

It would be nice if GWT apps set a better example for this world and
did it right (e.g. by hashing on the client), but the odds that this
complicated act actually translates to tangible security benefits is,
as far as I can tell, really quite small. That doesn't make it a bad
idea; on the contrary, you should always endeavour to go the extra
mile for security, because the status quo tends to be badly borked.
However, client side hashing isn't cheap or easy. I don't think its
justified to do it in this case.

By all means, prove me otherwise, and I'll update the FAQ.
Incidentally, I think anyone with incubator commit access can fiddle
with that FAQ, and feel free to, though I would prefer it if the
practical spirit of the document remains intact.

On Sep 17, 6:45 pm, hezjing <[EMAIL PROTECTED]> wrote:
> Hi
> When reading this
> LoginSecurityFAQ
>
>     String password = /*(get password from incoming JSON or GWT-RPC 
> request)*/;
>     String hashFromDB = /*(obtain hash from user's db entry)*/;
>     boolean valid = BCrypt.checkpw(password, hashFromDB);
>     if ( valid ) generateSessionIDAndSendItBackToClient();
>     else sendErrorToClient("Wrong Username or Password.");
>
> The article explained that the password is retrieved from the incoming JSON
> or GWT-RPC.
> If I read this correctly, this means the password is sent over the wire (and
> not secured)?
>
> On Wed, Aug 20, 2008 at 11:25 PM, walden <[EMAIL PROTECTED]>wrote:
>
>
>
>
>
> > Hi cresteb,
>
> > When contemplating security for a network application, you have to ask
> > yourself how secure is secure enough.  Security on the web is like the
> > locks on your doors: there is no sure way to prevent all attacks; you
> > can only lower the value to potential attackers by making the attack
> > harder to achieve.
>
> > A couple of notes on your writeup (independently numbered):
>
> > 1. F

Re: questions on Login Security FAQ

[hezjing]

Hi
When reading this
LoginSecurityFAQ


String password = /*(get password from incoming JSON or GWT-RPC request)*/;
String hashFromDB = /*(obtain hash from user's db entry)*/;
boolean valid = BCrypt.checkpw(password, hashFromDB);
if ( valid ) generateSessionIDAndSendItBackToClient();
else sendErrorToClient("Wrong Username or Password.");


The article explained that the password is retrieved from the incoming JSON
or GWT-RPC.
If I read this correctly, this means the password is sent over the wire (and
not secured)?



On Wed, Aug 20, 2008 at 11:25 PM, walden <[EMAIL PROTECTED]>wrote:

>
> Hi cresteb,
>
> When contemplating security for a network application, you have to ask
> yourself how secure is secure enough.  Security on the web is like the
> locks on your doors: there is no sure way to prevent all attacks; you
> can only lower the value to potential attackers by making the attack
> harder to achieve.
>
> A couple of notes on your writeup (independently numbered):
>
> 1. For registration, I would never send a password over the wire, only
> its hash.  If your entire interaction is going to be over SSL, ignore
> that, because it's a given.
>
> 2. HTTP Digest Authentication, which was by no means maturely
> implemented eight years ago, is a different story today.  It
> alleviates most concerns by never sending identifying information in
> clear text and by changing salt (or whatever they call it) to make Man
> In Middle and other attacks harder.  In my view, most of the gyrations
> developers go through today with http<-->https switching and sessions
> and session cookie duplication, and so on and so on, are a poor
> alternative to HTTP Digest, which deserves a fresh look.
>
> Hope this helps,
>
> Walden
>
>
> On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote:
> > Hello!
> >
> > I have some basic questions on the Register + Login + Keep session
> > alive process described on the Login Security FAQ.
> >
> > I know this is a little bit offtopic, but it would be really helpful
> > for me and other newbies if anyone can clarify some issues.
> >
> > This is how I see the process with some questions attached, please
> > correct it where necessary!
> >
> > Register:
> >
> > 1) Send username and password from client to server.
> > Q: I guess all the sites make this step over https so anyone can sniff
> > the password, right?
> >
> > 2) Store in the DB the username and the hash of the password.
> >
> > Login:
> >
> > 1) Send username and password from client to server (again over SSL).
> >
> > 2) Calculate the pasword's hash and look for a register in the DB that
> > contains that username and hash combination.
> >
> > 3) Return a session ID from server to client.
> > Q: Is this also done through https? If not, can't it be this session
> > id intercepted and used later to make a query as if you were other
> > user?
> >
> > During the session:
> >
> > 1) For every request from the client, include the session id, so the
> > server knows which user is sending the request and it is able to check
> > if the session is still active.
> > Q: Is secure enough just sending the session ID in order to identify
> > the user?
> > Q: The same as above...should it be sent through https?
> >
> > 2) Check if the session ID is valid or not. If its valid, send the
> > response with the data of the associated user.
> > Q: Is it also recommended to send a new session ID on each request so
> > we increase the security?
> >
> > Please, feel free to suggest me any document related with this topic.
> >
> > Thanks is advance!
> >
>


-- 

Hez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---