1
votes

My bank's website has 2 login pages for online banking. On the first page, I enter my username. If I don't enter a valid username, I get an error message, and do not get to the 2nd page. The 2nd page displays a picture based on my user name, and has me enter my password. If I manually type a URL to a page inside the site after entering my username but before entering my password, I am redirected back to the first login page.

Is there a good way to implement this in ASP.NET with Forms Authentication? I only get 1 loginUrl in my web.config.

I am fairly certain my bank uses Java.

2
I am always amazed how no one can ask how to do anything without getting more comments on if they need to do it or why they want do it. If someone wants to do something in an industry standard way, they probably don't need to post a question. If someone wants opinions on whether they should do something a certain way, they would explicitly ask this. - Brad
To clarify, our login page is a simple username/password page because that is what the users and developers like - if we wanted something different, we would have done something different. The people who pay me and the people who pay them want to discuss changing it. Any good developer who likes being paid should arm themselves with all possible technical knowledge to all possible solutions before going into that sort of meeting. - Brad
I love getting paid! But I would arm myself with the facts about using nonstandard logins and how it inhibits usability. Look at the issues people have with just OpenID. Not to mention, users don't read screens of instructions, they expect certian behavior when they are faced with a user/password challange. Like I said, it's not ideal to do some backwards way of authenticating, but it's your paycheck. I just gave you my idea, and thoughts on the topic. You asked the question, I gave a thoughtful answer. - Tim Meers
OH and by the way, if you are only worried about the single entry in the web.config, you may be thinking about it backwards. After all, you are comming up with a "new way" of doing things, so you will control the steps the user goes through not just relying on that single entry issue that isn't really an issue at all. - Tim Meers

2 Answers

0
votes

I do not find this a good idea, because this way any attacker know if the user name is the correct, then its need to know the password.

Second reason is that is more complicate and you need to be sure that you do not forget something on the way to login.

Third reason is that is not the common way to login, so people did not have use to it.

If you like to make the same, you need 2 pages, in the first you ask the user name, then you search on your local database if this is a valid user, then you keep this user name on a variable that you send on the second page that is the actual login. On the second page you have a common asp.net login module, but you have hide the user name, and at the same time you have set it with the value from the previous page. And then the rest is up to you.

0
votes

Hey I know the bank on this one. Well provided it's the same bank there is another page that the user has to visit if they are on a computer thats never accessed the login before. Once the enter the user name they visit a question answer page where the question is a random one they picked when they first signed up or at least when they thought up this cockeyed login page. Then they visit the password page.

You can implement this yourself if you are using the built in AspNetSqlMembershipProvider provider you can customize the built in login control and override the OnLoggingIn method. You can then do what ever checks you need on that login and move it to another page. On the next page you can override other methods the same way like: OnAuthenticate, and OnLoggedIn while still using the built in control (but customized) if needed. Then you can set the login page in your web.config to your first login page. You can see MSDN for other methods as well.

Now as already pointed out this is not ideal because it's not typical and most users will not understand what is going on or think it's flaky (just like i do about the bank). Not to mention you will need to do additional checks similar to how that bank is doing it to make sure everything is legit coming from the client. So in the end I wouldnt recomend it, it's to much hassle for the end user mainly.