Hi
When reading this
LoginSecurityFAQ<http://code.google.com/p/google-web-toolkit-incubator/wiki/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
-~----------~----~----~----~------~----~------~--~---

Reply via email to