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: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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
