I'm working on a web application that allows users to create multiple identities. The data is structured (in NoSQL) such that each user has a user document and several alias documents. Alias ids are stored on the user document, but user information is not stored in aliases.
user123: {
aliasIds: [MikeMain, Anon]
email: 'foo#bar.com',
...
}
MikeMain: {
name: 'Mike',
catchPhrase: 'Always remain hydrated'
}
Anon: {
name: 'Unknown',
bio: 'Purposely left blank'
}
This structure allows users to create content using an alias that does not link back to their user document. There is no way for other users to find out which aliases are controlled by the same person by examining data loaded in the client.
However, in the event of a database breach alias anonymity is lost.
My question is: how can I store this data so that even if a malicious third party had access to the whole database, they would not be able to figure out which user owned which alias?
You could create a new record for each alias.
Then you encrypt the ID of that alias record via a encryption key that is in CODE not in DATABASE, then save that encrypted alias record key to the primary profile's record/data.
This way, a compromise of DB will not compromise the anonymity of the profile because they would not have the key to decrypt.
Related
I'm creating a login system that doesn't require email, phone, or any other identification, making it completely anonymous, and I'm worried about the implications of a system like this.
To summarize, I'm creating a system where the user can login without providing any "real" id.
I'm currently thinking of two ways of doing this:
A simple "create account" with user/nickname and password, but without requesting email or phone;
Provide a unique string (or seed phrase) for new users. This string can be used login without any password. Anyone with that string can see and edit that account data;
• In both cases if the user loses the credentials the account can't be recovered, but I don't really care;
• The second one is more practical for the user, he only has to save a randomly generated string. The security might be lower depending on how the user saves the string, however there will nothing on the database that can be used to identify the account owner; permanent cookies can be removed;
If you are wondering, the website is a calculator that currently loses all data once the cookies expire. I'm looking for a way to give users the ability to recover previously inserted data, but I'm not interested at all in linking that data to an email or phone. I'm not interested at all in who uses the system and how they use it.
How bad is this idea? Are there other approaches? Making it 100% anonymous (as possible) vs security and many more implications.
Im struggling with Express.js and MongoDB.
I already configured passport login and passport-jwt, and it works just fine, but now I have a problem.
For example I have two users and one table, and I want when the first user login in the application, they have access the data created by them.
What is the best solution for this? Create one table per user?
Help me out and I appreciate your help!
you can update your schema of data that will be stored inside table, by adding:
owner {
type: mongoose.Schema.Types.ObjectId,
ref: 'User'
}
while user will be the name of modeling that created as users database, so every data inside that table will have id of its owner, and every time you want to display that data or send to the user, you can check if id of the owner of that data equals to the id of the user already login, and depend on that you can display the data of table or not.
and the id of the user will be stored inside req.user._id which will be created by passport package.
I'm developing an application with NodeJS, ExpressJS and MongoDB. Currently I'm working on the user registration process. I would like to store the user account temporary until the user has verified his email address, if the email address is not verified within a certain amount of time, I would like to remove the temporary account.
Currently I've following two ideas to solve the issue:
Creating a mongoose TempUserModel (besides the UserModel), i.e. if the user does the registration a temp user will be created, as soon as the user verified his email address, the temporary user account will be copied to the real Users collection. Some cronjobs could be setup to delete not verified user accounts after a certain amount of time (probably there are better solutions to let expire a mongodb record)
Setup redis to store the temporary user account data, as soon as the email address get verified, a new user will be created in mongodb. With this solution an expire date could be set to remove not verified accounts after a certain amount of time)
Is it better to store a temporary user account in Redis or in MongoDB?
I would recommend storing the temporary user accounts in MongoDB. Storing them in MongoDB has three advantages over Redis:
If you store a temporary user in MongoDB, it will be very easy to convert them to a real user once they have verified. In fact, you could even have the temporary users and verified users share the same schema, with a has_verified field in that schema being the only difference between the two kinds of users. Changing has_verified to true is a lot easier than saving data from Redis to Mongo.
If you are not already planning to create a Redis database for your project, you will only have to maintain MongoDB. Maintaining MongoDB requires less effort and fewer computation resources than maintaining both Redis and MongoDB.
If you ever make changes to your user schema in the future, it would be easier to only make those changes in once place, i.e. MongoDB, rather than to make those changes in two places.
I'm developing custom client/server application that requires client to log in with their username and password. The user accounts are not related to Windows/AD accounts in any way. After login, client application will request other services from server system.
My question is what is the best way to implement this? What kind of architecture would fit best here? I guess some kind of ticket/token authentication system needs to be implemented???
Thanks
You may in fact want to implement a system which passes "tickets" along between the different parts (login server, client, app server). This ticket will contain basic information such as the user ID (the username, the row id, etc). This ticket will either be encrypted with a secret key that the authorized servers share, or will be stamped with a hash of the ticket contents salted with a secret key that the servers share. The first way makes it possible for only the authorized servers to create and read the ticket, and the second way makes it possible for the authorized servers to verify that only the authorized servers could have created the ticket but permits anyone to read the ticket. All app servers will check the ticket (by attempting to decrypt it or by verifying that the hash matches) before proceeding with any actions that should be protected. If this is a web app, then cookies are a good place to store the ticket.
You haven't said much about your architecture, other than it is Client/Server, so I am assuming you're using some sort of forms designer like Windows Forms in VS. In these cases I have always used some form of database table authentication, as it is easy, simple to setup, and reasonably secure. You can even set up groups and roles this way, without much fuss.
Table: Users
Fields: UserID PK
Login Text
Password Text
...
Table: Roles
Fields: RoleID PK
Role Text
...
Table: UserRoles
Fields: UserID FK
RoleID FK
I store user data in a MSSQL table called Users. What I want to is to have accessible all user's data for actually logged user (email, address, phone, if the user is subscriber etc.).
I don't want to use profiles so I decided to use custom MembershipProvider (or do you know some better, less painful way?).
What I don't understand is MembershipUser and Membership.
If I inherite from MembershipProvider, in overriden methods I control access data from and to database.
But how do I use inherited class from MembershipProvider?
If I want to authenticate user by using membership, I should do:
if(Membership.ValidateUser(string username, string password))
{
FormsAuthentication.RedirectFromLoginPage(string username, string password);
}
But where is class inherited from MembershipProvider? And when to use a class inherited from MembershipUser? And what is relation between Membership and MembershipProvider?
While it's not crystal clear on MSDN, it's not all that complicated. There's a trio of classes:
Membership: provides utility methods and a point of entry -- basically a Singleton (static class).
MembershipProvider: acts as a data accessor and factory for MembershipUser objects.
MembershipUser: represents an individual user.
A custom MembershipProvider is selected (by code in Membership) based on your application's configuration: configuration/system.web/membership. Here's where you bring your provider into play. Your MembershipProvider implementation must be written to access whatever data store you prefer for users: your User table in this case.
MembershipUser objects are only created through your MembershipProvider. The MembershipProvider.ValidateUser() method should check against your data store that the user/password combination is valid. The MembershipProvider.GetUser() retrieves user information -- use it within an access protected page and pass in System.Web.HttpContext.Current.User.Identity.Name as the current authenticated user.
This said, I hope you are sure you don't want to use Profiles, and really want to have a separate User table. If you are writing an internal application, using an existing Active Directory or LDAP-enabled data store would reduce administration costs and probably security risks. There are hundreds of things you can easily do wrong when going the MembershipProvider route. Do you use salted hashes? How are you protecting the User table against manipulation? MSDN covers only a fraction of the security issues you may face.
The specific provider used is controlled on the web.config. You can actually set more than 1 provider, and have a default one. Check: http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx.
When called like that, membership just uses the default provider. You would inherit MembershipUser, if you wanted to provide extra info for the user, but that will tie the rest of your code to your specific provider.