Web forms authentication, should I use it?

[Vlad]

Hello, people!
I’m presently trying to choose an appropriate user authentication
solution for online banking system implemented in ASP.NET, and as far as
I understood the best practice of what Mcrosoft has to offer (with the
exception of Windows integrated) is WEB forms authentication. So my
question would be:
- Would using forms authentication really be appropriate for such
security demanding software, considering that authentication cookie will
still be saved on the client’s computer where it cannot be protected by
SSL anymore. Or is it better to implement some tailor made
authentication/authorization mechanism, based on authentication
information storing into session state/viewstate? What would you suggest?

Best regards,
Vlad.

vladi_dPLACEATHEREdotLV

[Brock Allen]

> - Would using forms authentication really be appropriate for such

> security demanding software, considering that authentication cookie
> will
> still be saved on the client's computer where it cannot be protected
> by
> SSL anymore. Or is it better to implement some tailor made
> authentication/authorization mechanism, based on authentication
> information storing into session state/viewstate? What would you
> suggest?

A couple of things about this:

The cookie that Forms authentication issues doesn't have to be persistent.
This is determined by the second parameter to FormsAuthentication.RedirectFromLoginPage
or FormsAuthentication.SetAuthCookie. If this is a real app you're building
then I'd suggest always passing false, which means the cookie won't be persistent.

Also, you can configure the application to issue the require SSL flag on
the cookie meaning the browser is not supposed to send the cookie to the
server unless there is a secure channel (SSL). This is configured in web.config
in the <forms> element with the requireSSL="true" attribute.

If you don't use SSL, then the cookie scheme is just as insecure as Windows
authentication with basic or integrated since those headers to identify the
client are just passed as headers... So in theory anyone could steal and
replay any of those types of identification information.

So, as far as what I'd suggest, if you don't want to rely upon a windows/domain
account for your users, then use Forms authentication. It has the potential
to be just as secure as any of those other schemes. It also has the potential
to be just as insecure too :)

-Brock
[url]http://staff.develop.com/ballen[/url]

[Igor Dombrovan]

Vlad пишет:

> Hello, people!
> I’m presently trying to choose an appropriate user authentication
> solution for online banking system implemented in ASP.NET, and as far as
> I understood the best practice of what Mcrosoft has to offer (with the
> exception of Windows integrated) is WEB forms authentication. So my
> question would be:
> - Would using forms authentication really be appropriate for such
> security demanding software, considering that authentication cookie will
> still be saved on the client’s computer where it cannot be protected by
> SSL anymore. Or is it better to implement some tailor made
> authentication/authorization mechanism, based on authentication
> information storing into session state/viewstate? What would you suggest?
>
> Best regards,
> Vlad.
>
> vladi_dPLACEATHEREdotLV

Hi

Check certificates authentication. Plus you can use the client
certificate for secure documents signing.

Igor

[Paul Glavich [MVP ASP.NET]]

Hi,

I have developed internet banking apps and used forms auth.

1. use SSL to encrypt the traffic. I think you already know this.
2. There has already been a suggestion to NOT use persistent cookies by
Brock Allen so you can make sure of this.
3. The cookies can be encrypted via the FormsAuthentication.Encrypt method
so even if it is stored on the client, it is encrypted. Combine this with
non persistent cookies, and your "attack" surface is reduced considerably.
4. Forms auth IS a custom solution. How you accept credentials, what those
credentials are (eg. might be a PIN number and password instead of username
or password) is entirely up to you. So in essence, you are writing your own
custom auth scheme, just mkaing use of the framework support to enforce it.
Behind the scenes, you can issue your own application specific cookie, that
contains further security items, perhaps a GUID that is used to access
temporary security session details inthe DB or whatever you want to further
ensure your online banking session canot be compromised. In our instance, we
utilised specific session keys (different to the .default generated session
keys) that were validated on each request, and re-issued new ones on each
request. So each request would ensure the previous session key/id was valid,
then re-issued a new one which had short time restrictions and special
encryption properties. What you do is up to you.
5. Optionally, you can go with cookieless authentication (cookieless=true in
web.config), but produces an ugly looking URL which is easier to get at than
the actual cookie, (IMHO)
6. You can use client certificates as suggested by someone else, but this
requires that each person accessing the online banking ap have this client
cert and introduces distribution problems. For a public online banking site,
this is usually more trouble than its worth and distributing these certs on
a large scale really reduces their effectiveness.

--

- Paul Glavich
ASP.NET MVP
ASPInsider ([url]www.aspinsiders.com[/url])


"Vlad" <vladi_dPLACEATHEREdotLV> wrote in message
news:uN3bigSKFHA.2764@tk2msftngp13.phx.gbl...

> Hello, people!
> I’m presently trying to choose an appropriate user authentication
> solution for online banking system implemented in ASP.NET, and as far as
> I understood the best practice of what Mcrosoft has to offer (with the
> exception of Windows integrated) is WEB forms authentication. So my
> question would be:
> - Would using forms authentication really be appropriate for such
> security demanding software, considering that authentication cookie will
> still be saved on the client’s computer where it cannot be protected by
> SSL anymore. Or is it better to implement some tailor made
> authentication/authorization mechanism, based on authentication
> information storing into session state/viewstate? What would you suggest?
>
> Best regards,
> Vlad.
>
> vladi_dPLACEATHEREdotLV

[Unregistered]

> - Would using forms authentication really be appropriate for such

A couple of things about this:

The cookie that Forms authentication issues doesn't have to be persistent.
This is determined by the second parameter to FormsAuthentication.RedirectFromLoginPage
or FormsAuthentication.SetAuthCookie. If this is a real app you're building
then I'd suggest always passing false, which means the cookie won't be persistent.

Also, you can configure the application to issue the require SSL flag on
the cookie meaning the browser is not supposed to send the cookie to the
server unless there is a secure channel (SSL). This is configured in web.config
in the <forms> element with the requireSSL="true" attribute.

If you don't use SSL, then the cookie scheme is just as insecure as Windows
authentication with basic or integrated since those headers to identify the
client are just passed as headers... So in theory anyone could steal and
replay any of those types of identification information.

So, as far as what I'd suggest, if you don't want to rely upon a windows/domain
account for your users, then use Forms authentication. It has the potential
to be just as secure as any of those other schemes. It also has the potential
to be just as insecure too :)

-Brock
http://staff.develop.com/ballen

thanks for very good and useful explanation.