Re: Secure login form

Re: Secure login form

Old forum URL: forums.lhotka.net/forums/t/3533.aspx


ozitraveller posted on Thursday, September 13, 2007

Hi

I'm looking for some help to make my app more secure. Currently I'm using the login form from PTTracker. So I'm wondering whether anyone has any idea how I can lockdown the login form so it's not spoofable and passwords are not passed around in the clear. Is there a windows login dialog that can be called? I have been looking at changing all the string variables to SecureString.

Any help would greatly appreciated.

Thanks

dean replied on Thursday, September 13, 2007

This is an article from 2006 about secure login:

http://www.developerfusion.co.uk/show/4693/

Haven't used it but thought I would pass it along.

Dean

RockfordLhotka replied on Friday, September 14, 2007

The normal solution, and the one I'd recommend, is to use SSL for the login.aspx page. That's what most web sites do, because SSL is a well understood and trusted protocol that solves the whole issue.

ozitraveller replied on Sunday, September 16, 2007

Thanks Rocky and dean.

I wish winform security was as easy to implement as webforms so I could use something like ssl, but alas, I'm only using winforms. And most of the articles I've seen still use string to pass the password around, pre-SecureString. I been to the pluralsight site and found Keth Brown's example: prompting for a password. Good but still only an example.

The 'Credential Management API ' example looks promising, maybe I can use some of it, as I am only interested in the secure dialog returning a securestring. I could change the Keth Brown example it's in C++.

RockfordLhotka replied on Sunday, September 16, 2007

I did assume web.

 

But Windows is typically easier. The only time your username/password combo would go across the wire in that setting is through the data portal. Again, the typical answer is to use SSL to protect the data flowing across the network – and you can use SSL and the data portal with the WCF, Remoting and Web services channels.

 

The EnterpriseServices channel can also be encrypted – that’s just a setting in the COM+ application dialog on the server.

 

The WCF channel can also be encrypted using WCF encryption – based on WS-Security I believe – which is much like SSL in that it is certificate based.

 

Passing the string around inside your WinForms app itself is kind of a non-issue, because that’s inside the same AppDomain at all times. Since the unencrypted string must, at some point, be available to your code, the key to decrypt the string would also need to be available within the AppDomain – meaning you can’t actually encrypt the value – all you can do is use a “fancy” form of obfuscation or encoding.

 

In other words, it is kind of silly to encrypt the value in memory, because the key is there too – and any hacker who has access to your private fields to get at the encrypted string can, by definition, get at the private field containing the key…

 

So all you can really do is protect the value on the wire – where it is more vulnerable anyway (assuming a hacker can put a tap on your network) – and that’s easily handled through SSL.

 

Rocky

 

 

 

From: ozitraveller [mailto:cslanet@lhotka.net]
Sent: Sunday, September 16, 2007 6:12 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Secure login form

 

Thanks Rocky and dean.

I wish winform security was as easy to implement as webforms so I could use something like ssl, but alas, I'm only using winforms. And most of the articles I've seen still use string to pass the password around, pre-SecureString. I been to the pluralsight site and found Keth Brown's example: prompting for a password. Good but still only an example.

The 'Credential Management API ' example looks promising, maybe I can use some of it, as I am only interested in the secure dialog returning a securestring. I could change the Keth Brown example it's in C++.



ozitraveller replied on Monday, September 17, 2007

Thanks Rocky.

I need to look further into SSL then.

Copyright (c) Marimer LLC