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.
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.
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.
Related
I am thinking about how to solve an authentication problem that i have.
I have a MVC-site with an admin area which is going to be used for customer-inputs and its very easy to have formsauthentication to protected the admin area but my problem is that other users could be able to edit other users stuff and thats not what i want =(.
My previous sites only handled authentication for one site and formsauthentication handled all my problems but this site should be able to handle authentication for X users and X customers.
For example user1 logs in to user1 admin area (mysite/customer1) but after log in changes the url to mysite/customer2 and starts editing stuff here.
One solution would be in global.asax and the FormsAuthentication_OnAuthenticate and check the url but there must be better approaches to this right? Maybe i am missing something obvious here?
What if once the user logs in (user1) you save their userId (or some unique identifier) into a claim or session. then just make one page mysite/customer which will read that Id and bring back just that one person's record. so this way the only record they will see is the one associated with their Id and you don't have to make the same pages over and over for other users, so no mysite/customer1, mysite/customer2, mysite/customer3...etc..
I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.
We have already a main site with a login.
We'd like to open a child site from the main site using the main's site login.
In the web world, what's the best practice to pass along the login details in a very safe way ?
Thanks
I don't know if this is the best practice, but when I had to do something similar for two internal websites, I just did it through an access token.
So the user will click a link on the main site which will create a database record in a table that contains at the very least their username, an expiration date, and a GUID.
We then redirect them to the child site using something like http://childsite.aspx?token=GUID
The child site looks up the GUID (if the querystring exists), validates that it's valid/not expired, and if it is valid set the authorization for that username and delete the record from the database.
Nothing gets passed along except a GUID. Which is useless once it's been used once, and it can only be created by a user who has already authenticated.
This works if the sites access a common database. I'm assuming that they do since your question implies that the login credentials for the main site are valid on the child site as well.
I am wanting to know when is the earliest point I can load additional user specific data like permissions into a session object right after login. I am using the membership provider but the data to be loaded is from a custom table. Session start is too late and I have tried the master page.
I'm also wondering where to put that logic to load the additional data.
I know it would be right after the user is authenticated but where? Global, login page, master page, default page etc.
Any advice would be great.
The earliest is obviously right after the user is authenticated. In other words, you should do it immediately your database call to confirm user credentials is successful.
The exact point it's difficult to tell without seeing your code. You may have user authentication logic on your login page (not a good architecture but it's quite common to see this) or you may have the logic on a business layer or a data access layer. You didn't show a piece of code as to tell you where makes more sense for you to have it but it's definitely within the login page or a call to another class made from the login page.
It is definitely not MasterPage or Global.asax
HI Guys I have the same issue and I am looking to solve it. Here is detail I have two web sites WebsiteA and WebSiteB (WebsiteB is not in my control, A type of black box for me.).
Both websites have seprate login page
I have alist of users,password of websiteB which I stored in database.
I want a kind of common login page. If user is login to websiteA and he want to go to websiteB, he dont have to enter the login and password information again.
I can not touch the code of websiteB. it's alredy deployed and runing.
In websiteB in login form they have a Userid textbox and Password textbox and and a login Button. This butoon is not a submit button. It has a click event which calls a function to validate the user. it's not a simple post.
WebsiteB has one webpage which has different frames. After login sucessfull. The pages doesnt go to any other page it remain on the same page but load the different frame.
According to my knowledge. I can use httpwebrequest class. But faceing the following problem.
Can not click the button.
Response.Redirect does not work.
It seems that WebsiteB is not storing any thing in cookies as cookies always return me a empty string
I really appriciate if anyone can help me on it.
How Can I use response.Redirect . As when I redirect it shows me the same login page.
Without knowing how login works to site B I could not say for sure, but at some point, I'm sure there is a post with login information. My best guess at a solution would be try to imitate what site B does on login. Use firebug and watch what gets sent, and what is returned. You'll have to mimic this behavior.
It may be something like:
POST credentials to site B for verification, returns verification result.
If verification is good, use token from verification result to redirect to site B.
Again, without knowledge of site B, I could not say, but whatever it does, it likely does using normal http, thus you can probably duplicate it. That said, site B may forbid you from logging in by only accepting logins from certain URLs.
As for using the HttpWebRequest, I think you'll find you're better off just having a hidden form which you submit from site A.
A HttpWebRequest will execute on the server of WebsiteA. Even if you execute the correct HttpWebRequest POST to WebsiteB, you won't be able to pass that session cookie to the user's browser without also immediately redirecting to WebsiteB.
There are other single-sign-on techniques you may want to investigate - the approach you have described will not work.
HI I figure out . We can create a string of XML and the converting the string into bytes and then use the normal write function of HttpWebrequest to Write the XML.