Re: How do I protect my login page from prying eyes (forms authentication)?

Sounds a bit like chicken and egg. The forms authentication needs to know which page is the login page, otherwise it cannot provide access to that page and bypass the authentication for it.

Guess so. I suppose I could have the login page in the main site (ie not in the secured bit), so there wouldn't be any problem getting at it when not logged in.

<snip>
At the end of the day though, you're just practicing security through obscurity. Sure, do this if you want to, but I'd rather devote time and energy to making my site secure even if someone discovers the "protected" site. And this page will only stay hidden for so long. Once it's out in the open (and if it's believed the contents are high valued, and people suspect that you've hidden the login page as a security measure), you may be *more* likely to be attacked.

OK, maybe I didn't make myself quite clear enough. The problem I have is that one of the pages in the secured folder generates a printable invoice. This means that when the site owner prints an invoice, the URL of this page will be shown in the footer. This is basically an invitation to try loading the page. If an unauthorised user tries to load the page, they get sent to the login page, which is an invitation to try gaining access.

So, without any security measures, the simple act of sending out invoices encourages ordinary people to try and hack the site.

My intention is to use URL rewriting so that the URL shown at the bottom of the page is something like http://domain/order23.aspx, which is a non-existent page. If they try to load it, they get a 404, which will discourage 99.999% of people. That's a very good start.

Obviously there will always be determined hackers. This approach is not expected to stop them, it is intended to keep the vast majority of curious customers away from the protected part of the site. The issue of securing the protected part from serious hackers is a separate one.

The simple fact of the matter is: all web servers/web sites which are exposed to the internet get attacked.

Correct, and anything you can do to protect the server is worthwhile. This approach is intended to keep the vast majority of interested, but non-malicious people away from the private section of the site.

Thanks for the reply. Any further comments?

--
Alan Silver
(anything added below this line is nothing to do with me)
.

Relevant Pages

  • Re: Linked Table-Embed Password
    ... > for the one login was the security. ... Don't confuse data security issues with data integrity issues. ... It may be common, but it's not secure. ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)
  • Re: Logins and mdw file
    ... If you can get in without a login, ... Creating userids and passwords in an MDW file DOES NOT secure the file. ... You need to make backup copies of your files, then read the security FAQ. ... > I have three Access programs running on a variety of PC's ...
    (microsoft.public.access.formscoding)
  • Securing user table with sha function
    ... Now moving on into other aspects of security:P I was thinking of a way to ... secure my login inputs the best way possible. ... Seeing how many different types of injection attacks their is and while ... AND how to secure for injection attacks? ...
    (php.general)
  • Re: How do I protect my login page from prying eyes (forms authentication)?
    ... I suppose I could have the login page in the main site (ie not ... >>At the end of the day though, you're just practicing security through ... Have the secure website generate invoices in the non-secure site, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Ten least secure programs
    ... it's probably better you leave the topic alone ... I said I do not have security issues with the programs I code. ... I didn't realize you were a Linux user, ... > the most widely used and secure UNIX flavors? ...
    (Security-Basics)