I understand that this kind of identification cannot be 100% accurate, but example usage would be internet poll, to detect users that have already voted. Is user detection possible with browser sent details? And what kind of information I can get from browser with every request? If I add IP address or location for example town to this, then identification would be more accurate. Are there any possible downsides I should know about?
You may want to check out the research the EFF has conducted, to identify visitors using default browser-transported information - but no cookies.
Here's the link for Panopticlick.
You should not rely on such information.
As I'm sure you are aware all of this information can be easily forged. As you can specify any request header at will (the request header contains IP, location, browser etc.).
You can use it as a poll, but you should keep in mind that the poll will never be 100% accurate.
If you want to know where the user is from make him authenticate in the site with a valid e-mail and set a cookie on his browser.
Another way to check a user's identity/location is using a paid identity validation service like URU for instance. Even this however is never 100% accurate.
ip + location is not a good thing. Much of internet users are behind firewalls/NAT's/proxy's.
Your best best is long term persistent cookie.
Related
I'm using Yubico demo to implement a webauthn server : https://developers.yubico.com/WebAuthn/WebAuthn_Walk-Through.html
I have implemented the CredentialRepository class to replace In Memory with access to a database.
Currently I am facing a problem:
I want to be able to use this server so that a client can connect with a Yubikey (or Andorid phone) to several websites. I would like the customer to register his key for each site. The problem is that the Yubico server does not want us to register the same key several times on the server while keeping the same username.
Would there be a way around this problem by making the registration of a key depend on the origin of the site where the key must be registered and not on the username?
(I don't want to replace the username with a different value for comprehension issues in the database)
All ideas are welcome.
Thank you.
What is preventing you from enrolling an authenticator multiple times for the same account lies within the PublicKeyCreationOptions that is being sent by the relying party. Within the PublicKeyCreationOptions is a field, excludeCredentials (line 22 in the screenshot link below).
PublicKeyCreationOptions Example
If you attempt to register a credential that has a credential ID that matches any of the items in the list, then the WebAuthn ceremony will not complete the request.
Why is this being done?
Users not familiar with how WebAuthn works may not realize that they only need to register an authenticator once, and that they can use that same authenticator across multiple devices. A confused user may attempt to register a security key on multiple devices, and may create the perception of a more cumbersome user experience. This is why we utilize the excludeList in our general guidance.
Here is some background as to how this list is being built.
How is the server creating this list?
When the relying party is built, you pass in the userStorage which allows the rp object to talk to your database where you're storing the credentials. When you begin your registration request, you pass in the userID when you are building the PublicKeyCredentialCreationOptions object needed by the RegistrationRequest object. If you observe the rp.startRegistration method you will see that the excludeList is built by searching userStorage for every credential that matches the userID of the user who made the request.
It's worth mentioning that the our example is typically acting as a relying party for a single origin/application, while yours is handling multiple.
With that context you have a few options
Here are some recommendations:
Provide guidance to your users noting that they can use the same
account/authenticator to enter into your multiple websites. This will only be applicable if your relying party is acting as a single origin authentication service, then routing the user back to the website they are coming from; example, Users in website1.com, website2.com and website3.com are all routed to my-relyingparty.com, authenticated, and routed back to their original site
As noted the java-webauthn-server is looking for registrations by username. You will first need to leverage multiple rp objects as they contain a reference to a specific origin (each registration you create with this rp object will correspond to the identity/origin you set). You can either create multiple instances of the java-webauthn-server for each origin, or create logic in your single instance to 1) Create multiple rp objects for each origin and 2) dynamically choose the rp object to use based on the origin of the users request. You could choose to leverage the same credential repository across multiple server instances or rp by overloading the startRegistrations method to search by both userID and rp ID/origin - While this is technically possible, it'll be a fair amount of rework.
Opt not to send existing credentials in the excludeCredentials list,
but this may be confusing to some users
Hope this helps
Thank you #CodySalas for your interesting answer.
This is what I did before you gave me an answer: I made the client send me back the origin of the client for the startRegistration and startAuthentication steps.
I added a trackedOrigin variable in InMemoryRegistrationStorage and I set trackedOrigin with userStorage.setTrackedOrigin(origin) for the two steps.
So when the Relying Party wants to search for excluded credentials (excludeCredentials) with "getCredentialIdsForUsername()" it will check the trackedOrigin to be able to make a request in the database according to the origin. Username is therefore no longer a uniqueness constraint since excludeCredentials will only have the credentials of keys with the same username AND the same origin.
Now that I saw your answer, I think reconsidered the solution I found because I discovered that the RP ID must be exactly the same as the domain of the client while the sites that will use the webauthn server will not have at all the same domain... Which is problematic but that's another question.
I'll probably open another question for that.
I am attempting to determine if there is a security flaw using the proposed method of maintaining session state when the client has cookies blocked.
Normally I store a UUID in the clients cookies and auto login if the UUID matches whats stored in the database. However, if the client has cookies blocked, I can't access a UUID on their machine and therefore have to resolve to using their IP address and match against the database that way.
I determine the IP address using:
String ip = request.getHeader("X-FORWARDED-FOR");
if(ip == null) {
ip = request.getRemoteAddr();
}
I'm a little green in this area, but I think there might be a security flaw in this approach. For instance, if the user accesses the application on a public wifi network (in a coffee shop, airport, hotel... whatever) it will store the public ip and match their account to that ip. Anyone coming in behind them on that same ip will have complete access to their account unless they specifically remember to log out. How do I prevent this? I'm not totally against using another approach when cookies are blocked besides matching to the ip. I'm just not sure what other approach their might be besides just totally disallowing user logins when cookies are not available. Is this the only truly secure method?
UPDATE
Based on T.J. Crowders comment, recent stats show that 2% of users actual have cookies blocked. I chose to rely on cookies for a number of reasons and show a warning when session state cannot be managed due to cookies being blocked.
...but I think there might be a security flaw in this approach. For instance, if the user accesses the application on a public wifi network (in a coffee shop, airport, hotel... whatever)...
Not just that. People who have wireless broadband in their home will all seem to be from the same IP, so if two people who live together both want to use your site simultaneously (maybe one recommended it to the other), they'll conflict.
If you can't use cookies, you could use the old J2EE technique of putting the session ID in every URL. If you're already using J2EE, you can use its built-in support for this (HttpServletResponse#encodeURL and such), which will use ;jsessionid=token on the URL. If you aren't, it's simple enough to implement the technique using a query string parameter.
The servlet API allows tracking sessions without cookies, using URL-rewriting (every URL pointing to the app in a given session will contain the session ID). This is automatic if you respect a few rules:
always use HttpServletResponse.encodeRedirectURL() when redirecting
always use HttpServletResponse.encodeURL() when generating a URL (for a link, image or whatever)
Note that the JSTL's <c:url> calls encodeURL() for you.
Assume I have a single servlet in a web app, and all users need to be logged in before they can do anything. So in the get and post methods there is an if block to test if the user is logged by trying to extract a session attribute in to process request, and else to redirect to login page if not logged in.
Given this scenario, is there a way an intruder can manipulate the system to gain entry without knowing the password? Assume the password is hard-coded into the servlet. If yes, where would he start?
I would look at http://docs.oracle.com/javaee/5/tutorial/doc/bncbe.html#bncbj and the section linked from that section about specifying authentication mechanisms.
See also (on Stackoverflow) Looking for a simple, secure session design with servlets and JSP and How do servlets work? Instantiation, sessions, shared variables and multithreading
In short, you don't need to do much yourself about checking for a session attribute if you use the mechanisms described on those pages. Your login form can be used in the 'form-login' configuration requiring authentication.
The key of security is around your comment extract a session attribute -- how are you doing this? Are they sending you a query string param? Are they sending you credentials in the method headers?
To #Hogan's point, unless this is over HTTPS the answer is: "No, it is not secure. A man-in-the-middle (MITM) can get the password from your submission and simply re-use it to mask its own nefarious requests".
If the communication IS done over HTTPS, then you should be fine. Having a single hard-coded password is fine, but consider the case where the password gets compromised; now every single client/user/etc. has to change their code.
A better design is to issue clients a key they can send along with their requests that you can use to identify who they are and if a key gets compromise, re-issue a new one to that user/client/etc.
This assumes traffic is over HTTPS
If traffic is not, a lot of this breaks down and you need to look at things like HMAC's. I wrote this article on designing secure APIs -- it should give you a good introduction to how all this nightmare of security works.
If your eyes are rolling into the back of your head and you are thinking "My god, I just wanted a YES/NO", then my recommendation is:
Require all traffic to be over HTTPS
Issue individual passwords to each client so if one gets compromised, every single one isn't compromised.
That should get you pretty far down the road.
Hope that help. This topic is super hairy and I know you didn't want a history lesson and just want to solve this question and move forward. Hope I gave you enough to do that.
I have a list of users across various companies who are using one of the functionality that our website provides. Whenever they contact our business group , we need to send a url via email to the requestor in order for them to upload some data. All these external users do not have any dedicated account. However we do not want a static link to be provided to them as this can be accessed by anyone over the internet. We want dynamic links to be generated. Is this something that is usually done? Is there an industry accepted way of doing this? Should we ensure that the dynamic link expires after a certain amount of time - if so , are there any design options?
Thanks a lot!
Usually, parameters to urls and not the actual urls are what's dynamic. Basically you generate params that are stored somewhere, typically on the database, and send email with the url and the parameter(s). This url is valid for only a limited period of time and possibly only for one request.
Answers to questions:
yes, this is something that is quite commonly used in, for example, unsubscribing from a mailing list or validating an account with a working email address
I'm not aware of any single way that is "industry accepted", there are many ways of doing it, but the idea is not that complex - you just need to decide on a suitable token format
normally you should ensure that the link expires after a certain amount of time. Depending on the use case that can be some days, a week or something else. In practice, you'd remove or disable the generated parameters in your database. However, if this data is something that might be needed for extended periods of time, you might want to think up a functionality so that it can be retrieved later on.
You may have a static URL taking a token as parameter. Eg. http://www.mycompany.com/exchange/<UUID> or http://www.mycompany.com/exchange?token=<UUID>.
The UUID could have a validity in a time range or be limited to a single use (one access or one upload).
Other variant is to use exists cookies on that site in web browser (of course, if they are).
But there are some drawbacks in this solution:
User can open link in different machine, different browser. User can clean all cookies or they can expire after it was visited your site last time when user try to go on granted URL. In these cases user won't access your page.
when people register to my website i don't want to send them a verification e-mail, i just want to check if that e-mail exists. is there a way to do such a thing ?
using apache-tomcat and java as my main programming language.
thanks a lot!
No. There is no way to tell if an email address points to a valid destination. You can check basic syntax, and that the domain has a record in DNS, but that's all.
You can at highest use regex to check if the address is syntactically valid and/or looking up the MX records if the domain is valid, but this still does not guarantee that the email address is legitimate and belongs to the registrant in question. There is really no more reliable way than sending a verification email and waiting for confirmation in a short time-span.
contrary to some of the uneducated answers you can TRY and connect to an MX server and use the VRFY command to see if the sever supports it. Here is a website that will do this for you as an example. If you look at its exchange with the MX server it actually does try and send an email but does a RESET before actually sending it. Testing it with my email address works but I don't get an email. So yes you CAN do what everyone else is saying you can't do. Use an address you know works for your domain, then use one that you don't isn't supported. You will get a 550 on the last RCTP TO command. That is how you know it doesn't exist.
I just wanted to weigh in and say that despite your reluctance to do so, PLEASE send an email and force the user to confirm that they have control of it before allowing that email address to be used in association with an account on your site. Why? Because not doing that, for any reason, means that users can sign up for accounts using email addresses that aren't theirs. They might do so accidentally, or they might do so very much on purpose (e.g., signing others up for accounts for any number of reasons); that's just not kosher, and websites that allow it are open to being reported to their ISPs.
(I say this as the owner of a Gmail account which, at least two to three times a month, is signed up for an account at some website that doesn't force users to confirm their email addresses in this manner. It's irritating, and it puts the onus on me to get the account removed from the offending website. I've now taken to recovering any passwords I can, logging into the account, and then changing the email address to "UNKNOWN#gmail.com" or something like that... it's sorta fun, but I doubt you want this to happen on your website.)
This has been answered already in previous questions here. Without a verification email, the best you can do is look at the email address and look if it seems valid. You can also check things such as the domain, to see if it exists and has MX records. Anyway, see https://stackoverflow.com/questions/3232/how-far-should-one-take-e-mail-address-validation and Using a regular expression to validate an email address
If you just want to verify that it LOOKs like a valid email address, there are many sample Regex's that will verify that. If you want to verify the user has control of the email address, you'll need to send something to it and craft a unique response to verify it.
i guess this is what you are looking for
http://www.strikeiron.com/Catalog/ProductDetail.aspx?pv=5.0.0&pn=Email+Verification
You can use the openid service to check for valids email addresses as stackoverflow does.
http://openid.net/
Email Verification services are very helpful in validating email address. Most of them performs 6 levels of verification like syntax validation, Domain MX record Check, Role based Account detection, Disposable email address (DEA) detection, HoneyPot/Spam track detection and deep level SMTP verification.
Most of them offers API integration, so, you can directly validate email addresses from your application.