I've been thinking about this quite a bit lately, and I would like some feedback from this wonderful community. Is it safe to assume that a user wants to be remembered when they login? And if they are using a public computer, is it safe to assume that they are smart enough to logout before leaving?
I don't really think it's safe to assume anything about the end-user.
Plus, it's easier for a user to just close the browser rather than to log out of every website, so providing a remember me checkbox defaulted to false is user friendly and less hassle for them over-all.
No. In this age of too-little privacy, any potential hole for a breach should be closed. Sites should be getting more secure, not less.
No, it is best to assume nothing, especially something like remembering the user.
What if they are at a friend's house or on a public computer and forget to log out?
No. Never assume that your users will do things that you want them to do if you don't explicitly tell them (i.e. force them) to do so.
The "Remember me" checkbox is an excellent example of how ignorant users can be - even when the checkbox is there, the fact that users are kept logged on on public computers is a problem. It won't help if you start assuming...
Now that most browsers can remember passwords anyway, there's little point in setting a remember-me cookie as well, so you can get rid of that option. Then users can no longer complain if they clear their cookies and then wonder why your site doesn't know them from Adam...
However, do not assume the user will log out. They don't, and with tabbed browsing, your session cookie could stick around for a very long time - maybe several days if they keep using hibernate/sleep mode and only restart their browser when it crashes. Therefore you need to set a reasonable inactivity timeout and require them to log back in once it expires.
No. Don't forget the old phrase:
When you make an assumption, you make
an "ass" out of "u" and "mption".
Thought I would update this discussion for anyone who finds this from Europe, where the EU Cookie Law will come into effect May 25th 2012. The law will require all European websites to obtain informed consent from visitors before they can store or retrieve any information on a computer or any other web connected device.
As the "Remember Me" almost certainly necessitates using a cookie, you absolutely CAN NOT assume that users will want to be remembered, and in fact doing this will become illegal from May 25th unless you somehow otherwise gain consent for cookie use from your users.
There are various strategies for how sites will comply with the new law, a popular choice currently is to have a site wide cookie Opt-In prominently displayed on your site, which disables all cookie operations until the user activates them. That's a discussion for another thread though, the message here is that you can't assume if you your web site operates out of Europe.
If your website is not security-relevant (that is: You're not a bank, medical or insurance company), then I would reverse the checkbox. Make "Remember me" the default and have a checkbox "This us a public computer, do not store my password". That would be my wish as a user, as I hate "Remember me" checkboxes, also because they don't work most of the time.
Is it safe to assume that a user wants
to be remembered when they login?
I would say that yes, in 80% of the cases (total guess on my part), the person connecting to your website is not through a public computer, and they would rather not have to retype their information every
time they come to the website.
And if they are using a public
computer, is it safe to assume that
they are smart enough to logout before
leaving?
No, that's not safe to assume. And smartness isn't even the proper term - it's more a question of remembering or even being aware I would say.
So I say go the safe route. Provide a "Remember me" checkbox, and leave it unchecked by default. People are used to this scenario. It's not that big a deal and it's much less likely to cause you trouble than checking it by default, or even worse not providing it and doing it silently.
I think it should be there on non-vital sites, but never checked by default and never automatically assumed to be wanted. If people don't want to remember their logins or retype them, let the browser's password manager or whatever deal with it, not the site. Users generally don't logout - to many, just closing the browser counts.
Related
I wonder if I might ask for opinions on a simple authentication system I'm thinking about for a pet web site project where the overriding requirement is that the system should have no way to tell who the user is, i.e. have no way of identifying or contacting them.
The system does need to distinguish between these anonymous users of course, and prevent users pretending to be other users.
Perhaps in a strict sense it's not an authentication system at all, more like a distinguishing system.
A simple solution would be to assign a Guid to new users, which gets stored in a cookie/local storage/whatever and used to distinguish them.
Then give the user the facility to copy the Guid, and/or generate a URL that they can bookmark or otherwise store locally, which re-supplies the Guid to the site and stores it as a cookie again - to be used if the cookie is deleted or they want to authenticate from another machine - by using the generated URL or pasting the copied Guid into a 'login' page on the site.
This means there can be no 'I forgot my password' facility; if the user loses their credentials, they are forever lost, that's accepted.
Additionally, if the credentials are stolen, or the user's cookies are compromised, then the credential is stolen forever, there is no way for the real user to lock out the thief, that's also accepted.
Clearly the user would need to make damn sure they store this URL/Guid somewhere safe, that's accepted.
As an aside, there could be a feature that allows the user to regenerate the Guid, which might be used if they accidentally broadcast their Guid somehow, but that also means if somebody steals their Guid and uses the regenerate feature before the 'real' user realises, the real user will be locked out forever - maybe best it's unchangeable so at least if the Guid is compromised, the thief cannot lock out the real user - but this is an aside.
Given the requirement for complete anonymity / non-contactability, and accepting that losing the Guid is like losing a dollar bill, you lose it forever, it seems a reasonable and pleasantly simple solution.
This is essentially the same as having a user/password combination with no email address or other contact details, but more secure than user: sally123, password: mydogsname1968 or whatever just by virtue of it being a Guid, not something the user can remember or easily scribble on a post-it note and stick to a monitor.
It also has the advantage that a user who uses the same machine all the time (and doesn't delete cookies) never has to login or think about credentials at all.
The Guid could actually be two Guids stuck together or three of them interleaved byte by byte, whatever - a unique auto-generated chunk of data that reflects how unnecessarily paranoid the developer is feeling.
Can anyone tell me why this wouldn't be a good solution, given the anonymity/non-contactability requirements and the drawbacks accepted above, or perhaps suggest a better solution.
If it makes any difference to anything, it'll be a Net Core 5 / Blazor Web Assembly / MongoDb application, it's a pet project so doesn't have to pass muster with any client requirements or existing systems etc.
Thanks for any advice/help.
I'm creating an app where user submissions (e.g. photo) are designed to be captured via crowdsourcing. The app connects to an API using an API key, and the app then submits the data anonymously.
We want to avoid the overhead of people creating user accounts and passwords.
However, it seems to me this is vulnerable to a the problem of the key getting revealed. The result is that spammy submissions could be made much more quickly via browser/wget HTTP requests. Because the app is installed on people's devices, it would take a long time for us to be able to withdraw a key and replace it with another.
The approaches to deal with this problem I can think of are:
Hope that the key stays secret. Not ideal from a risk perspective. Using HTTPS for the API endpoint would reduce this risk, but presumably the app could still be decompiled to reveal it (not that in practice anyone would really bother)
Store a fixed username and password in the app, and submit as that. That basically seems to run the same problem - if the credentials are leaked then this has the same problem as 1.
Require a first-run fetch of a token to auto-create a username and password. However, if the key is compromised then this is no more secure. Also, this means we end up with lots of junky usernames and passwords in our database that really don't mean anything.
Not considered desirable: force users to create a username/password. However, that then means a lot of messing around with accounts, and compromises the anonymity of submissions, meaning data protection implications.
Are there standard patterns dealing with this scenario?
The first time the app runs, it could get a random token from the server, store this, and use it on all subsequent requests. The server just checks that the token is one it produced itself. After each request, block the token for 5 minutes (or make a counter so 10 requests are ok but the 11th gets blocked, depending on your use case). When a token gets misused, block it, so the user will have to deinstall/reinstall your app, or, if he made a script to emulate the app, he'd have to re-register after every few posts (plus you can limit the numer of registrations per IP or something similar).
You can assume any fixed credentials will be compromised. A good attacker can and will reverse-engineer the client. On the flip-side, a username/password combo will compromise anonymity (and nothing is stopping a spammer from creating an account).
Honestly, this is a very difficult problem. The (inelegant) solution involves something like a captcha where you provide a problem that is difficult for a bot but easy for a human to solve (for the record, I think captchas are almost useless, although there have been some less annoying alternatives).
Alternatively, sites like Facebook use sophisticated algorithms to detect spam. (This is a difficult approach so I would not recommend it unless you have the manpower to dedicate to it).
I have an corporate intranet project that needs logins, but doesn't need high security. Impersonating a different user is not useful or very desirable. In similar intranet systems, everyone has the same password as setup by the admin.
I'm hoping to get some suggestions on what password alternatives I could consider. My first thought is to show each user 8 images and have them click on one to be their password. Would this be too annoying or problematic in someway? What other ideas would you suggest?
Why not just use a text based password? It sounds like you are over-complicating things by including images, especially if, as you stated, don't need "high security". I wouldn't consider a text based password "high security" but it does meet your requirements of a login on the intranet. A lot of products have built in functions for passwords so it would be dead simple to implement into your project if you have this available. I'm suggesting you keep it simple and don't assume that impersonating a user isn't something that won't happen without at least a password. You'd want to know who made changes or have some logs that identified who was the user at the time of a certain event.
Remember, security should be baked in, not sprayed on!
If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
I'm wondering when login timeouts are being used, specifically when using same session (same browser session). On a number of sites I have completed recently I have added 60 minute timeouts and they seem to be causing problems, such as users are not able to fill out larger forms (like a resume submission--people don't think of copying their resume from another program or saving part way through). On one site, I have implemented a div/popup forcing the user to enter their password to continue in the current session, without having to login again.
But on other sites, such as Facebook, it seems you are never logged out as long as you are using the same browser window, even without "remembering" your password.
The main reason I usually use timeouts is to ensure the data is secure, such that another party can't sit down at the computer a few hours later and use the system as the original user.
I'm wondering how you decide when a site should time out users because of inactivity?
I'm thinking the answer would be language agnostic.
IMO, they're valid when:
security is critical (ie. banking)
the likelihood of seat-swapping is
high (ie. public terminals)
Regardless, there may be instances like your resume system, where you want people on public terminals to be able to carry out an act that may leave them inactive for longer than your desired or necessary timeout.
I suppose you just have to handle that in a smart fashion - either figure out a way they can get the data in quicker (which would be ace, spending an hour filling out a form is not fun - can they just upload a file?), or ensuring they can continue without any data loss after being prompted to log in again.
Even though 60 minutes seems like a long time to fill out a single form (perhaps the forms should be divided into multiple pages?), you can probably use SlidingExpiration to solve the problem where your users get logged out even though the browser session is alive.
I think the timeout for an auth cookie is a Security level decision. If your site is SSL secured, you would probably have minimal timeout values (user session would expire within a matter of minutes). On the other hand, for sites with non-critical security, you could set a medium timeout value.
When I sign on to online banking, for example, it asks me whether or not I am using a "public terminal": and if I say yes then it enforces stricter security, or if no then laxer.