|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
At What Point Does the Security Begin?If an ASP.NET page with the usual username and password fields is not secure
(it's called at http, not https) but posts to a page through https that does the username/password lookups, is this process secure? Or do both pages need to be going through https? In other words: http://mydomain/login.aspx posts to https://mydomain/validate_login.aspx the post will be done over SSL in this case - which is OK.
but after the validation suceeded - how do you want to identify that user as authenticated on subsequent requests? I guess you want to issue something like a ticket (usually a cookie) - be awar that when only your validate_login page is SSL secured, the cookie will be transmitted back and forth using plain http and can be stolen, thats of course not as bad as disclosed credentials - but still this cookie could be used to logon to your application. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > If an ASP.NET page with the usual username and password fields is not > secure (it's called at http, not https) but posts to a page through > https that does the username/password lookups, is this process secure? > Or do both pages need to be going through https? > > In other words: > > http://mydomain/login.aspx > posts to https://mydomain/validate_login.aspx Thanks, Dominick.
Since this application is actually plain old ASP, not .NET (I still haven't learned enough .NET to port the app, but it will be ported as soon as I figure out the .NET equivalent of server-side includes in the code section), I'm tracking it with a server variable, and all pages behind the login are posted through SSL. Would this be sufficient when I port this to .NET, too? When ported, I plan to use forms-based auth, in which I understand .NET uses a cookie behind the scenes without the need for user code. My question came about because our web designers want to move the login and password prompts to the home page, where they currently reside on their own SSL-secured page. I've been arguing that this isn't secure, but apparently I'm wrong. Show quoteHide quote "Dominick Baier [DevelopMentor]" wrote: > the post will be done over SSL in this case - which is OK. > > but after the validation suceeded - how do you want to identify that user > as authenticated on subsequent requests? I guess you want to issue something > like a ticket (usually a cookie) - be awar that when only your validate_login > page is SSL secured, the cookie will be transmitted back and forth using > plain http and can be stolen, > > thats of course not as bad as disclosed credentials - but still this cookie > could be used to logon to your application. > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > > > If an ASP.NET page with the usual username and password fields is not > > secure (it's called at http, not https) but posts to a page through > > https that does the username/password lookups, is this process secure? > > Or do both pages need to be going through https? > > > > In other words: > > > > http://mydomain/login.aspx > > posts to https://mydomain/validate_login.aspx > > > what server variable? in session?
--------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Thanks, Dominick. > > Since this application is actually plain old ASP, not .NET (I still > haven't learned enough .NET to port the app, but it will be ported as > soon as I figure out the .NET equivalent of server-side includes in > the code section), I'm tracking it with a server variable, and all > pages behind the login are posted through SSL. Would this be > sufficient when I port this to .NET, too? When ported, I plan to use > forms-based auth, in which I understand .NET uses a cookie behind the > scenes without the need for user code. > > My question came about because our web designers want to move the > login and password prompts to the home page, where they currently > reside on their own SSL-secured page. I've been arguing that this > isn't secure, but apparently I'm wrong. > > "Dominick Baier [DevelopMentor]" wrote: > >> the post will be done over SSL in this case - which is OK. >> >> but after the validation suceeded - how do you want to identify that >> user as authenticated on subsequent requests? I guess you want to >> issue something like a ticket (usually a cookie) - be awar that when >> only your validate_login page is SSL secured, the cookie will be >> transmitted back and forth using plain http and can be stolen, >> >> thats of course not as bad as disclosed credentials - but still this >> cookie could be used to logon to your application. >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >>> If an ASP.NET page with the usual username and password fields is >>> not secure (it's called at http, not https) but posts to a page >>> through https that does the username/password lookups, is this >>> process secure? Or do both pages need to be going through https? >>> >>> In other words: >>> >>> http://mydomain/login.aspx >>> posts to https://mydomain/validate_login.aspx Yes, a session variable that my app creates.
Something like: If bValidated Then Session("userID") = Request.Form("username") Else Session("userID") = "" End If All secure forms examine this variable, and if empty redirect to the login page: If Session("userID") = "" Then Response.Redirect("login.asp") -salty- Show quoteHide quote "Dominick Baier [DevelopMentor]" wrote: > what server variable? in session? > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > > > Thanks, Dominick. > > > > Since this application is actually plain old ASP, not .NET (I still > > haven't learned enough .NET to port the app, but it will be ported as > > soon as I figure out the .NET equivalent of server-side includes in > > the code section), I'm tracking it with a server variable, and all > > pages behind the login are posted through SSL. Would this be > > sufficient when I port this to .NET, too? When ported, I plan to use > > forms-based auth, in which I understand .NET uses a cookie behind the > > scenes without the need for user code. > > > > My question came about because our web designers want to move the > > login and password prompts to the home page, where they currently > > reside on their own SSL-secured page. I've been arguing that this > > isn't secure, but apparently I'm wrong. > > > > "Dominick Baier [DevelopMentor]" wrote: > > > >> the post will be done over SSL in this case - which is OK. > >> > >> but after the validation suceeded - how do you want to identify that > >> user as authenticated on subsequent requests? I guess you want to > >> issue something like a ticket (usually a cookie) - be awar that when > >> only your validate_login page is SSL secured, the cookie will be > >> transmitted back and forth using plain http and can be stolen, > >> > >> thats of course not as bad as disclosed credentials - but still this > >> cookie could be used to logon to your application. > >> > >> --------------------------------------- > >> Dominick Baier - DevelopMentor > >> http://www.leastprivilege.com > >>> If an ASP.NET page with the usual username and password fields is > >>> not secure (it's called at http, not https) but posts to a page > >>> through https that does the username/password lookups, is this > >>> process secure? Or do both pages need to be going through https? > >>> > >>> In other words: > >>> > >>> http://mydomain/login.aspx > >>> posts to https://mydomain/validate_login.aspx > > > Ok - and session ids are also transmitted via cookies - if i know the session
id of an authenticated user, i can become that authenticated user... back to square 1 :) --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Yes, a session variable that my app creates. > > Something like: > > If bValidated Then > Session("userID") = Request.Form("username") > Else > Session("userID") = "" > End If > All secure forms examine this variable, and if empty redirect to the > login page: > > If Session("userID") = "" Then Response.Redirect("login.asp") > > -salty- > > "Dominick Baier [DevelopMentor]" wrote: > >> what server variable? in session? >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >>> Thanks, Dominick. >>> >>> Since this application is actually plain old ASP, not .NET (I still >>> haven't learned enough .NET to port the app, but it will be ported >>> as soon as I figure out the .NET equivalent of server-side includes >>> in the code section), I'm tracking it with a server variable, and >>> all pages behind the login are posted through SSL. Would this be >>> sufficient when I port this to .NET, too? When ported, I plan to use >>> forms-based auth, in which I understand .NET uses a cookie behind >>> the scenes without the need for user code. >>> >>> My question came about because our web designers want to move the >>> login and password prompts to the home page, where they currently >>> reside on their own SSL-secured page. I've been arguing that this >>> isn't secure, but apparently I'm wrong. >>> >>> "Dominick Baier [DevelopMentor]" wrote: >>> >>>> the post will be done over SSL in this case - which is OK. >>>> >>>> but after the validation suceeded - how do you want to identify >>>> that user as authenticated on subsequent requests? I guess you want >>>> to issue something like a ticket (usually a cookie) - be awar that >>>> when only your validate_login page is SSL secured, the cookie will >>>> be transmitted back and forth using plain http and can be stolen, >>>> >>>> thats of course not as bad as disclosed credentials - but still >>>> this cookie could be used to logon to your application. >>>> >>>> --------------------------------------- >>>> Dominick Baier - DevelopMentor >>>> http://www.leastprivilege.com >>>>> If an ASP.NET page with the usual username and password fields is >>>>> not secure (it's called at http, not https) but posts to a page >>>>> through https that does the username/password lookups, is this >>>>> process secure? Or do both pages need to be going through https? >>>>> >>>>> In other words: >>>>> >>>>> http://mydomain/login.aspx >>>>> posts to https://mydomain/validate_login.aspx How does the hacker get that session id when the whole thing is sent through
SSL? Show quoteHide quote "Dominick Baier [DevelopMentor]" wrote: > Ok - and session ids are also transmitted via cookies - if i know the session > id of an authenticated user, i can become that authenticated user... > > back to square 1 :) > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > > > Yes, a session variable that my app creates. > > > > Something like: > > > > If bValidated Then > > Session("userID") = Request.Form("username") > > Else > > Session("userID") = "" > > End If > > All secure forms examine this variable, and if empty redirect to the > > login page: > > > > If Session("userID") = "" Then Response.Redirect("login.asp") > > > > -salty- > > > > "Dominick Baier [DevelopMentor]" wrote: > > > >> what server variable? in session? > >> > >> --------------------------------------- > >> Dominick Baier - DevelopMentor > >> http://www.leastprivilege.com > >>> Thanks, Dominick. > >>> > >>> Since this application is actually plain old ASP, not .NET (I still > >>> haven't learned enough .NET to port the app, but it will be ported > >>> as soon as I figure out the .NET equivalent of server-side includes > >>> in the code section), I'm tracking it with a server variable, and > >>> all pages behind the login are posted through SSL. Would this be > >>> sufficient when I port this to .NET, too? When ported, I plan to use > >>> forms-based auth, in which I understand .NET uses a cookie behind > >>> the scenes without the need for user code. > >>> > >>> My question came about because our web designers want to move the > >>> login and password prompts to the home page, where they currently > >>> reside on their own SSL-secured page. I've been arguing that this > >>> isn't secure, but apparently I'm wrong. > >>> > >>> "Dominick Baier [DevelopMentor]" wrote: > >>> > >>>> the post will be done over SSL in this case - which is OK. > >>>> > >>>> but after the validation suceeded - how do you want to identify > >>>> that user as authenticated on subsequent requests? I guess you want > >>>> to issue something like a ticket (usually a cookie) - be awar that > >>>> when only your validate_login page is SSL secured, the cookie will > >>>> be transmitted back and forth using plain http and can be stolen, > >>>> > >>>> thats of course not as bad as disclosed credentials - but still > >>>> this cookie could be used to logon to your application. > >>>> > >>>> --------------------------------------- > >>>> Dominick Baier - DevelopMentor > >>>> http://www.leastprivilege.com > >>>>> If an ASP.NET page with the usual username and password fields is > >>>>> not secure (it's called at http, not https) but posts to a page > >>>>> through https that does the username/password lookups, is this > >>>>> process secure? Or do both pages need to be going through https? > >>>>> > >>>>> In other words: > >>>>> > >>>>> http://mydomain/login.aspx > >>>>> posts to https://mydomain/validate_login.aspx > > > OK - if ALL pages the user access afterwards are behind SSL (even graphics
and other stuff like .css etc) and the use cannot somehow "log out" and come back to the non-SSL area, then this is fine. Otherwise the browser will happily send the session cookie also for non-SSL resources. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > How does the hacker get that session id when the whole thing is sent > through SSL? > > "Dominick Baier [DevelopMentor]" wrote: > >> Ok - and session ids are also transmitted via cookies - if i know the >> session id of an authenticated user, i can become that authenticated >> user... >> >> back to square 1 :) >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >>> Yes, a session variable that my app creates. >>> >>> Something like: >>> >>> If bValidated Then >>> Session("userID") = Request.Form("username") >>> Else >>> Session("userID") = "" >>> End If >>> All secure forms examine this variable, and if empty redirect to the >>> login page: >>> If Session("userID") = "" Then Response.Redirect("login.asp") >>> >>> -salty- >>> >>> "Dominick Baier [DevelopMentor]" wrote: >>> >>>> what server variable? in session? >>>> >>>> --------------------------------------- >>>> Dominick Baier - DevelopMentor >>>> http://www.leastprivilege.com >>>>> Thanks, Dominick. >>>>> >>>>> Since this application is actually plain old ASP, not .NET (I >>>>> still haven't learned enough .NET to port the app, but it will be >>>>> ported as soon as I figure out the .NET equivalent of server-side >>>>> includes in the code section), I'm tracking it with a server >>>>> variable, and all pages behind the login are posted through SSL. >>>>> Would this be sufficient when I port this to .NET, too? When >>>>> ported, I plan to use forms-based auth, in which I understand .NET >>>>> uses a cookie behind the scenes without the need for user code. >>>>> >>>>> My question came about because our web designers want to move the >>>>> login and password prompts to the home page, where they currently >>>>> reside on their own SSL-secured page. I've been arguing that this >>>>> isn't secure, but apparently I'm wrong. >>>>> >>>>> "Dominick Baier [DevelopMentor]" wrote: >>>>> >>>>>> the post will be done over SSL in this case - which is OK. >>>>>> >>>>>> but after the validation suceeded - how do you want to identify >>>>>> that user as authenticated on subsequent requests? I guess you >>>>>> want to issue something like a ticket (usually a cookie) - be >>>>>> awar that when only your validate_login page is SSL secured, the >>>>>> cookie will be transmitted back and forth using plain http and >>>>>> can be stolen, >>>>>> >>>>>> thats of course not as bad as disclosed credentials - but still >>>>>> this cookie could be used to logon to your application. >>>>>> >>>>>> --------------------------------------- >>>>>> Dominick Baier - DevelopMentor >>>>>> http://www.leastprivilege.com >>>>>>> If an ASP.NET page with the usual username and password fields >>>>>>> is not secure (it's called at http, not https) but posts to a >>>>>>> page through https that does the username/password lookups, is >>>>>>> this process secure? Or do both pages need to be going through >>>>>>> https? >>>>>>> >>>>>>> In other words: >>>>>>> >>>>>>> http://mydomain/login.aspx >>>>>>> posts to https://mydomain/validate_login.aspx "salty" <sa***@discussions.microsoft.com> wrote in message I would still argue for keeping the login fields on their own SSL page. Not > My question came about because our web designers want to move the login > and > password prompts to the home page, where they currently reside on their > own > SSL-secured page. I've been arguing that this isn't secure, but apparently > I'm wrong. for security's sake but rather for user confidence sake. When a user enters his username/password on an SSL protected page, he sees the little lock icon in his browser. This confers a sense of 'security' to the user, whereas he might be slightly worried if the lock icon isn't present on the login page... Regards, Pieter Philippaerts On 2006-06-24, Pieter Philippaerts <pieter.nospam@mentalis.org> wrote:
Show quoteHide quote > "salty" <sa***@discussions.microsoft.com> wrote in message Perhaps browsers should start displaying the 'lock' icon as soon as the>> My question came about because our web designers want to move the login >> and >> password prompts to the home page, where they currently reside on their >> own >> SSL-secured page. I've been arguing that this isn't secure, but apparently >> I'm wrong. > > I would still argue for keeping the login fields on their own SSL page. Not > for security's sake but rather for user confidence sake. When a user enters > his username/password on an SSL protected page, he sees the little lock icon > in his browser. This confers a sense of 'security' to the user, whereas he > might be slightly worried if the lock icon isn't present on the login > page... form target is https.. Tim Van Wassenhove wrote:
> On 2006-06-24, Pieter Philippaerts <pieter.nospam@mentalis.org> wrote: Pieter is right when arguing against login over SSL from non-protected> > "salty" <sa***@discussions.microsoft.com> wrote in message > > > > I would still argue for keeping the login fields on their own SSL page. Not > > for security's sake but rather for user confidence sake. When a user enters > > his username/password on an SSL protected page, he sees the little lock icon > > in his browser. This confers a sense of 'security' to the user, whereas he > > might be slightly worried if the lock icon isn't present on the login > > page... > > Perhaps browsers should start displaying the 'lock' icon as soon as the > form target is https.. > page. Not only because of little lock icon, but also because it makes phishers life so much easier. - Displaying the icon on the forms that target SSL as Tim suggested, would require more than just simple check of https address in the target of form, but also check of certificate, check that certificate matches the name of protected page as well as it belongs to the domain of unprotected page (otherwise phishers could just copy company looking webpage and put ssl login to https://malicious.hacker.com or to https://112.113.114.115). The last rule (matching domains) will likely to break many existing web pages used this wicked practice, because too often we can find pages that logons from say http://www.somecompany.com to https://protected.somecompany.com. Change established infrastructure (certificates and URLs) is much higher burden than redirecting everything over insecure connection. - You see where we going here? - little icon is a *little* icon which could be easily overseen if the rest of page perfectly matches user's expectations. - Users trained to enter password on unprotected page is more likely to become victim of phising than one who never enters his password without ssl protection. plus many many more other reasons... Instead of showing such icon when form targets ssp protected page it would have been much better if there were a Wall of Shame for every site that asks users loging from non-ssl protected page, and that every browser show that Wall of Shame every time the user enters web page of such company. -Valery. http://www.harper.no/valery 
Other interesting topics
Need advise...
Import SIMPLEBLOB session key into .NET? [assembly: SecurityPermission] question Help : Access denied ??? Bad Data with DES Decryption Active Directory and ASP.NET 2.0 IDentifiy user acl on a folder ???? permission for socket access https and httplistener Microsoft CryptoAPI CSP Availability |
|||||||||||||||||||||||
