I would like to collect analytics on multiple visits from a logged in user, if they opt in.
But I would really like to do it in a way that only the user can link their user account to the anonymised analytics entry. This means, when the user is logged in, they can manage the analytics information stored from their visits, but site administrators won't be able to link the analytics entries to that account (the analytics data and user data is of course stored separately)
Ignoring implicit links in the analytics data (such as user identifying URLs etc), what would be the best way to implement this? Is it too dangerous to use a secure hash of the user's password and account ID to identify the analytics information? (the site administrators won't have the user's password, so won't be able to link the records).
You've dressed this up so that linking a user account to data is not predicatable - but that doesn't mean it that the information is therefore hidden. Regardless users will be making a requset based on a key, which is exclusively derived from their account - so really its just security by obscurity. Since it must be possible for the system to reconcile the users identity with the key against which the data is stored it is therefore possible for someone with backend access to derive the association - even if only at the time of access.
The only way to prevent this is to store the data on a machine where these admins don't have access.
Related
I only wish to employ Auth0 as my application's API provider but otherwise
would prefer to maintain any and all data about my users within my application's own database, thus, as one might well surmise, my application's database contains a users table along with several related tables. So, once a user signs up for my app, I'd need to create records for that user within the database. Then, once the user logs in via Auth0, I'd like to retrieve that user's data via information contained within the access token. (The field that presents itself as most useful for this purpose is "azp," or "authorized party.")
I'm thinking that, once the user signs up, as part of the effort to create the relevant records within the database, I'd save the "authorized party" value to a field on the users table. (Which field I cannot say, but, for now, this seems as sound a plan as any.) Then, when the user logs in via the Auth0 hosted API, I would retrieve their record from the database via the "authorized party" value.
Does this sound like a reasonable/sound plan? This is my first time building a full-on application from scratch, and, well, this particular detail has me scratching my head.
Ok, so I've inherited an open-source project with user logins that are a simple username/password combo. Unfortunately, if someone forgets their password, we don't have a password recovery option. I'm hoping to fix that now, but not sure how to do it securely, given that we don't have any other identifying characteristics. User accounts have no recovery email, no "secret questions," etc.
A user account consists only of 1) username, 2) encrypted password, 3) List of document ids which the user has editor access (but this is publicly visible by viewing the user's public page)
Now that I have access to the project, I will be implementing OAuth or similar, but as for old accounts with forgotten passwords that have since been logged out, is there any right way to ID my users so they can do a password reset?
There is no great way of doing this. You just don't have the information; not even enough to contact users. Until a user has supplied their username and password, you can't communicate with them.
You'll need to add a check that runs every time a user authenticates, which checks if they've set recovery data (email or whatever you decide on). From there you have a variety of options, depending on how important you find the recovery data. In order of severity, you could:
Disallow use of the site until they have added and verified
recovery data. Essentially, full authentication fails if recovery
data is not set.
Prompt them to add recovery data, but allow them to skip it.
Notify them that the ability to set recovery data has been added, but take no further action.
If you are dramatically changing login, you'll need to support the legacy method as well until such time as you want to abandon users who haven't made the switch.
Given the increasing concerns in data privacy, is it possible to build a web app that provides a driven user experience (aka different outcomes on different users based on their specific profiles) without sending any personal information that can be tracked, hijacked or forced by any entity on the web app's servers ?
The question is somewhat vague, but due to the fact that HTTP is stateless, you'll need users to send some kind of information, at the very least user registration and login data to identify them and store their identity in some kind of storage (ex. cookie).
If you dont want the users to post any data, you wont be able to personalize the experience, just provide the same experience to everyone every time they enter your website.
I think you can do this, but you will need to identify users at the start, and then unidentify them later - for example, get them to register with an email address, confirm that address, then create an identifier derived from that address (e.g. a hash or random number), switch to using it as a user name and delete the email address. Then you will be at a point where they can log into an account, but you hold no personal identifiers on them.
I have a set of encrypted financial data for investors and need to store it in a database. The investors must be able to see the data when logged in to the app but the developers and everyone else mustn ot be able to see it.
Additionally the investors are not tech savvy and can not be given a key to use apart from a username and password.
What technologies/encryption approaches can I take with the app so that the financial data can be kept secret from me and other developers by the company, I'm assuming they encrypt it before uploading it for example, but allow the valid users to access it.
Is there a way to do this without putting a technical burden on the investors so that they don't have to have anything more than a username and password whilst also not storing their "keys" in the database so that a developer could technically decrypt it.
I have the following requirement: Retrieve the users from OpenAm which are members of a specific group. Alternatively, if possible, retrieve users defined in a specific data store. All this through web-services.
We have our own JDBC data store implementation which reads users from and authenticates users against our database. That works fine. The data store is one of two data stores in our sub realm. The other data store points to an LDAP.
Now I need to read the users (and later the user attributes) from users being defined in the LDAP data store, and only users of a specific group, if possible.
Previously we did that with wso2. There they had a web-service method that allowed you to retrieve users of a specific group only.
Currently I am looking into the IdentityServices web-service of OpenAm, and I am able to list all users of my realm, and get the attributes. But for performance reasons, it would be nice to be able to refine the search. Is that possible? Am I looking at the wrong web-service?
Regards,
Sascha