Securing password between webserver & appserver.

[Chintan Oza]

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

[Nikhil Wagholikar]

Hi Chintan,

May be you can think of One Time Password (OTP) as an alternative to PKI.

---
Nikhil Wagholikar
Practice Lead | Security Assessments & Digital Forensics
Network Intelligence (India) Pvt. Ltd. [NII Consulting]
Web: http://www.niiconsulting.com/
Comprehensive Information Security Training
http://iisecurity.in/courses/Training%20Calendar.html

2009/9/7 Chintan Oza <chintan.oza@...>

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

[Lou Cipher]

Chintan,

I am not sure if I understand your question. If you are using the
webserver as the middleware, the authentication credentials will have
to pass through it one way or the other.

Can you please provide more details as to what problem are you trying
to address?  Thanks

Saqib
http://kawphi.blogspot.com

[Chintan Oza]

Dear Saqib,

Yes the webserver will be in the middle.

The password verification will be performed by the application server.

We just dont want the password to be available at the webserver where
the ssl communication ends.

Chintan

On Mon, Sep 7, 2009 at 1:10 PM, Ali, Saqib<docbook.xml@...> wrote:

> Chintan,
>
> I am not sure if I understand your question. If you are using the
> webserver as the middleware, the authentication credentials will have
> to pass through it one way or the other.
>
> Can you please provide more details as to what problem are you trying
> to address?  Thanks
>
> Saqib
> http://kawphi.blogspot.com
>

[Robert Hajime Lanning]

On Mon, Sep 7, 2009 at 7:04 AM, Chintan Oza<chintan.oza@...> wrote:
> Browser<-HTTPS->WebServer<-->AppServer
>
> We have a requirement where password should not be available to the
> WebServer (even in hashed format).

CHAP should work just fine.  Just make sure the challenge is randomly generated.

--
And, did Galoka think the Ulus were too ugly to save?
                                         -Centauri

[Lou Cipher]

in that case, a pre-shared secret or PKI seems to be the only way.

Saqib
http://kawphi.blogspot.com


On Mon, Sep 7, 2009 at 1:40 AM, Chintan Oza<chintan.oza@...> wrote:

> Dear Saqib,
>
> Yes the webserver will be in the middle.
>
> The password verification will be performed by the application server.
>
> We just dont want the password to be available at the webserver where
> the ssl communication ends.
>
> Chintan
>
> On Mon, Sep 7, 2009 at 1:10 PM, Ali, Saqib<docbook.xml@...> wrote:
>> Chintan,
>>
>> I am not sure if I understand your question. If you are using the
>> webserver as the middleware, the authentication credentials will have
>> to pass through it one way or the other.
>>
>> Can you please provide more details as to what problem are you trying
>> to address?  Thanks
>>
>> Saqib
>> http://kawphi.blogspot.com
>>
>

[EXT-Adams, Randall E]

Hello Chintan,

You are right.  Without changing your architecture or requirements you
would have to have the client encrypt the message before sending it
through an untrusted web server.

If you are worried about message integrity you will have to encrypt the
message with one key then create a MAC with another key.  You will have
to maintain two sets of public/private keys here.

Maybe OpenSSO is something you would be interested in.  Effectively it
allows you to put a servlet filter into your web application that
redirects the user to go log into a separate application server before
being redirected back to your application.

OpenSSO would be a lot of work -- all it really gets you is the ability
to delegate authentication to a different app server.  I would rather
support OpenSSO (with all its complexity) than a custom applet-based
crypto solution.

https://opensso.dev.java.net/


Respectfully,
Randall

-----Original Message-----
From: Chintan Oza [mailto:chintan.oza@...]
Sent: Monday, September 07, 2009 2:04 AM
To: webappsec@...
Subject: Securing password between webserver & appserver.

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

[arvind doraiswamy]

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@...> 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
>
>
>

[Ken Schaefer]

Is this an internal application? Kerberos can be used to solve this problem for internal apps.

Alternatively, can you use client certificate based authentication?

Cheers
Ken

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On Behalf Of Chintan Oza
Sent: Monday, 7 September 2009 2:04 PM
To: webappsec@...
Subject: Securing password between webserver & appserver.

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

[Chintan Oza]

Hi Arvind,

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@...> 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@...> 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
>>
>>
>>
>

[Martin O'Neal]

 
> You are right.  Without changing your
> architecture or requirements you would
> have to have the client encrypt the
> message before sending it through an
> untrusted web server.

Just stating the obvious here though; if the web server is genuinely
untrusted, then logically none of this can be secured anyway.

An attacker at the web server is a classic MITM. All they need to do is
remove the client side auth code as it passes on the way out to the
client, and then they will always receive a clear-text password back
from the client. POW!

If you don't trust the server, then a web delivery mechanism probably
isn't the right architecture at all.

Martin...

[Martin O'Neal]

> Or why not bypass the webserver altogether
> for auth if itisnt trusted. Send credentials
> directly to the app server, that is assuming
> the app server is publicly accesible.

Yup, would work. However, it would be a novel situation in which the
credentials were sensitive, but the data was not.

I would personally be trying to resolve the untrusted web server
situation...

Martin...
       

[arvind doraiswamy]

You're right, the client side CC is just another alternative if you're
worried about passwords being in clear text. If you have Client side
certs you can probably even do away with authentication as only
specific users will have the cert, though most places have the cert
and the login form as well to protect against the cert being stolen.

The SSL , yes will end at the Web server..but hey that is what it is
supposed to do. The deal though is - If you have a salted hash
mechanism with the salt controlled at the server, the password will
still be encrypted ...NOT by the SSL but because of the salt and the
MD5/SHA1 you are using on the client side to encrypt it.

The Client side code in this case won't be bypasssed. Well, I mean you
can of course intercept and remove the Javascript but the server won't
accept a request without a valid salted password hash..so you should
be fine. A lot of apps I've seen do this.

Lastly if you're concerned with the traffic between the WebServer and
the DB, you'll want to ensure that all your queries are also sent over
SSL(You'll probably need to enable this on the DB first). Incase your
app server(Tomcat/Weblogic etc) if at all you have one is on a
separate server , you'll need to look at encrypting content between:

a)Client and the WS
b WS and the AS
c)AS and the DB

Hope that clarifies things a little more.

Cheers
Arvind

On Tue, Sep 8, 2009 at 10:50 AM, Chintan Oza<chintan.oza@...> wrote:

> Hi Arvind,
>
> 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

[Till Elsner]

What about securing (i.e. encrypting) the connection between web  
server and app server itself, like connecting to the app server from  
the web server via a SSH-forwarded local port? You could keep the  
original authentication method and have the entire communication  
encrypted anyway.

Greetings
Till

Am 07.09.2009 um 08:04 schrieb Chintan Oza:

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

[bigbert007]

Till - great recommendation, I'll expand on it.

Depending on the back end app server, there is usually a mechanism in
place for creating a trust between the web server and appserver and then
encrypting that connection with SSL.  When credentials are entered the
entire pipe is encrypted from the client > webserver > app server based
upon that trust relationship and SSL- encrypted connection

Websphere has this option available as does Tomcat.  I suspect that
Coldfusion and other app servers have something similar.

Good luck.

Don

Till Elsner wrote:

> What about securing (i.e. encrypting) the connection between web
> server and app server itself, like connecting to the app server from
> the web server via a SSH-forwarded local port? You could keep the
> original authentication method and have the entire communication
> encrypted anyway.
>
> Greetings
> Till
>
> Am 07.09.2009 um 08:04 schrieb Chintan Oza:
>
>> 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
>>
>>
>
>
>

[Calderon, Juan Carlos (GE, Corporate, consultant)]

Don that is an interesting suggestion

Do you have more specific information, since I only know that SSL/IPSec
can be end-to-end in a per link basis, but the idea of a real End-to-End
encryption using SSL, that is the case of Chintan is interesting.

Any link or whitepaper on how to do this in Tomcat as you mention?

Regards,
Juan Carlos

-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of bigbert007
Sent: Martes, 08 de Septiembre de 2009 10:34 p.m.
To: webappsec@...
Subject: Re: Securing password between webserver & appserver.

Till - great recommendation, I'll expand on it.

Depending on the back end app server, there is usually a mechanism in
place for creating a trust between the web server and appserver and then

encrypting that connection with SSL.  When credentials are entered the
entire pipe is encrypted from the client > webserver > app server based
upon that trust relationship and SSL- encrypted connection

Websphere has this option available as does Tomcat.  I suspect that
Coldfusion and other app servers have something similar.

Good luck.

Don

Till Elsner wrote:

> What about securing (i.e. encrypting) the connection between web
> server and app server itself, like connecting to the app server from
> the web server via a SSH-forwarded local port? You could keep the
> original authentication method and have the entire communication
> encrypted anyway.
>
> Greetings
> Till
>
> Am 07.09.2009 um 08:04 schrieb Chintan Oza:
>
>> 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
>>
>>
>
>
>