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 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
-~----------~----~----~----~------~----~------~--~---
