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.
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.
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.
If I want to save a response to a query on a website I'm coding to a server, how would I do that?
Here's an example. If I had a site with a "Rate us" form, and a person answered with a "AWFUL SITE!" how would I be able to save & retrieve that information?
There are several ways to do what you want to do. I'll describe two of them.
You could append each rating to the end of a file on the web server. This would be done in a server-side scripting language usually, such as PHP or ASP.NET, and you would probably want to set the permissions on the file so that it's not readable to everyone.
You could set up a table in a database (MySQL or otherwise) and add a new row for each rating given. Again, this would be done in something like PHP or ASP.NET and you would want to make sure you take precautions against SQL injection attacks (not much of a problem if you use PHP Data Objects rather than the deprecated mysql_* functions).
I would personally go for the second option as it's easier to manage and change, and it's easier to set it up so that you can store IP, name, optional email and message in every row. And like I said, you can add a new field later down the line without running into the obvious problems.
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.
There is this site wich in the address bar only shows like "http://example.com/examplepage.aspx".
Normally if it would have parameters behind it you probably could just copy that one.
But since it doesn't, how do i bookmark this page.
It doesn't necessarily have to be a bookmark, but at least an easy way to access the page.
(fyi I know basic HTML and Java, maybe it's only possible programmatically).
thnx
Generally dynamic pages (taking in context with the question) are not book mark friendly.
You could probably sniff the incoming request, and create a fake form which you can then submit later.
However there may be situations where there are parameters such as session id which are valid for only small periods of time.
You should read up on sessions. In really simple terms, a session is assigned to users accessing a website. They have an expiry period. IF you stay idle beyond set time (determined by the developer) you will not be able to get in. And every time you log back in, you may be assign a new session.
You would have noticed, that some websites automatically log you in, this is mostly done with the help of cookies. Cookies work in tandem with sessions, they store very basic information, so the next time you come back to a website, it will be able to identify you as a returning user and provide you with access.
Then again, some pages don't use sessions, they might have their own custom way of identifying users.
Bookmarks can be used in dynamic pages, if the code allows you to send GET requests, if they don't have any other extra parameters which will block you.
To Summarize:
Dynamic page not very bookmark friendly.
There may be parameters used to access a webpage which change constantly, which you cannot really save.
You may be able to get into dynamic pages using bookmarks, if they don't use any of the dynamically changing parameters.
Since you know Java, you should probably read up on JSPs/servlets to get an understanding of what happens behind the scenes in dynamic pages.
Hope this answers your questions.