Re: questions on Login Security FAQ
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. Huh? (j)BCrypt is the first link mentioned on
Re: questions on Login Security FAQ
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
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
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
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,
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 +
Re: questions on Login Security FAQ
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
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 never failed; it's just
Re: questions on Login Security FAQ
-- 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
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
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
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
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
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
-~--~~~~--~~--~--~---
Re: questions on Login Security FAQ
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,
Re: questions on Login Security FAQ
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 -~--~~~~--~~--~--~---
