I would like to update parameter Do you want to remember your user's devices? from No to Always. However, we are currently having quite a number of user profiles. My question is what the impact if any for existing users?
Thanks.
I have conducted quick experiment by toggling the flag between Always and No, everything seems good without any change for existing user.
Related
JHipster implements several best practices for authentication and authorization.
Mainly described here: https://www.jhipster.tech/security/.
But I still do not see an example how to design a solution, which does not involve putting user verification logic all over the place for a very common use case.
Let's say you have a WebPage using REST-API like BankAccountResource from JHipster Sample App and you want to restrict this to only ADMIN role or currently logged in User. Let's say you have 50 of such services for your customers: BankAccount, Address, BillingAddress, UserData, Devices... For every resource a GET and UPDATE must be restricted. Also loading device /api/device/{id} might not include user-id.
How do I prevent UserA from loading UserB's device by guessing it's id?
How do I avoid planting that code in every method?
I guess JHipster/SpringSecurity has concept/objects to handle such use cases. Could you point me, explain how to use them please?
Maybe this question helps a little bit: Restrict URL access control by id in jhipster
Spring Security hast PostFilters to check if an object e.g. loaded by a method may be accessed. If you need more control you can use Access Control Lists for fine grained access control.
References:
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#domain-acls
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#method-security-expressions
I have an application where users of my organization, who are not users of this application can register themselves in the first log. When they register, they can choose one or more app's profiles, like contract manager, supervisor etc. These profiles have specific authorization schemes per page, buttons, regions in app. The user must logoff and login again at the inicial log to see these menu's references
Do you know of any way that these menu's references could be viewed/activated in the first of all logs?
The oracle apex version is 5.1.4.
Regards.
I'm answering my own question as follows:
I do a self-criticism for the question because I consider it to have failed to take into account all aspects of information security. Even though I'm always careful about security, a solution of this kind might attend me, considering a IT's well secure work's scenario, but may not be the case for all environments.
I would consider this a valid question for security experts, who could see in the scenario that I proposed, a failure in the APEX environment, in which I have not yet seen.
In my application I want to prompt a user about a new feature with some kind of a dialog the first time they visit the screen. And on a subsequent visit this dialog is not shown.
The obvious solution is to use a cookie or save this in the database.
But I'm concerned that:
- over time all the checks in the code will result in messy code
- with the database solution - it can bring performance issues.
And also if the user clears his cookies (for example) I don't want them to see every new feature update for the past two years (one screen can be have multiple new features over time).
Is there a stupid/simple way to handle this? How does twitter and facebook do this when they promote their new features?
My environment is MSSQL, ASP MVC if does matter.
Use both - cookies as a caching technique - first check the cookie. If it doesn't contain the flag - then ask the DB.
Also, you can initialize that cookie at login. One DB call per user session.
Personally, I'd use a database flag against the user record.
Like you say, cookies can be destroyed and lead to annoying duplicate reminders.
I don't think you need to worry about "messy code" if you're doing it right.
Since you have user login, I assume you also have some type of server-side session. You could store user preferences in the database, and cache them in the session upon login, avoiding going to the database for every request. As long as you trust your session for authentication purposes, you certainly can trust it for user preferences.
We store it in XML. Then you can use serialization to quickly save/load the settings. We store the XML in SQL (MS SQL have features that support XML)
Well the checks in the code are independant from the place you store the datas, it is a different problem.
As of your question I'ld say to use the database, for speed + ease reasons.
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!
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.