There are 1 set of users for which password verification is done by
over server where as in case of other group of users the password
verification will be done by a third party system which expects
password in the plain format.
Correct me if I am wrong but usage of client certificate doesnt help
protect communication between web server and app server as its job
ends at web server which handles ssl.
Thanks,
Chintan
On Mon, Sep 7, 2009 at 9:59 PM, arvind
doraiswamy<arvind.doraiswamy (at) gmail (dot) com [email concealed]> wrote:
> Hey Chintan,
> Yes client side certificates are possible but a big pain if you have a
> large number of users to whom you have to distribute them too.
>
> However I'm curious, a properly implemented salted hash solution where
> the salt is randomly generated and matched on the server each time the
> client sends it will prevent a lot of attacks. Note - the server
> decides the salt, not the client.
>
> So while I am not contesting your requirement and your reasons I think
> that not much harm is done even if the webserver sees the
> salted-hashed password. It can't be cracked , it can't be replayed so
> what's the problem?
>
> Am I missing something?
>
> Cheers
> Arvind
>
> On Mon, Sep 7, 2009 at 11:34 AM, Chintan Oza<chintan.oza (at) gmail (dot) com [email concealed]> wrote:
>> Dear All,
>>
>> We have a web application which perform user authentication on
>> id+password basis.
>>
>> The architecture is like this.
>> Browser<-HTTPS->WebServer<-->AppServer
>>
>> We have a requirement where password should not be available to the
>> WebServer (even in hashed format).
>>
>> Only solution that I can think of is having an Applet performing PKI
>> encryption on the password before submitting the form.
>>
>> Please suggest if there are any better alternatives.
>>
>> Thanks,
>>
>> Chintan
>>
>>
>>
>
There are 1 set of users for which password verification is done by
over server where as in case of other group of users the password
verification will be done by a third party system which expects
password in the plain format.
Correct me if I am wrong but usage of client certificate doesnt help
protect communication between web server and app server as its job
ends at web server which handles ssl.
Thanks,
Chintan
On Mon, Sep 7, 2009 at 9:59 PM, arvind
doraiswamy<arvind.doraiswamy (at) gmail (dot) com [email concealed]> wrote:
> Hey Chintan,
> Yes client side certificates are possible but a big pain if you have a
> large number of users to whom you have to distribute them too.
>
> However I'm curious, a properly implemented salted hash solution where
> the salt is randomly generated and matched on the server each time the
> client sends it will prevent a lot of attacks. Note - the server
> decides the salt, not the client.
>
> So while I am not contesting your requirement and your reasons I think
> that not much harm is done even if the webserver sees the
> salted-hashed password. It can't be cracked , it can't be replayed so
> what's the problem?
>
> Am I missing something?
>
> Cheers
> Arvind
>
> On Mon, Sep 7, 2009 at 11:34 AM, Chintan Oza<chintan.oza (at) gmail (dot) com [email concealed]> wrote:
>> Dear All,
>>
>> We have a web application which perform user authentication on
>> id+password basis.
>>
>> The architecture is like this.
>> Browser<-HTTPS->WebServer<-->AppServer
>>
>> We have a requirement where password should not be available to the
>> WebServer (even in hashed format).
>>
>> Only solution that I can think of is having an Applet performing PKI
>> encryption on the password before submitting the form.
>>
>> Please suggest if there are any better alternatives.
>>
>> Thanks,
>>
>> Chintan
>>
>>
>>
>
[ reply ]