There are several services which allow change of usernames frequently like Twitter, LinkedIn etc. Some other have very limited options (example: Facebook for two times). And rest does not allow changing usernames.
The major reasons I can understand is, records are kept against usernames and the URL are cached by search engines against the username. But to solve the first problem, which is much vital, applications can use userid instead of username.
Is there any other important issues/reasons for which I should consider disallow changing usernames?
the main issue is social engineering. people associate a reputation with a name (both the user with the name, and the people who interact with them). if you allow names to change then there is less social pressure to preserve a good reputation and more "bad behaviour".
it's all about coercing users to invest social status in a persistent identity. technically they could implement a system that supports name changes (for example, you could use an arbitrary, unique, auto-generated ID to represent the user in the database/cache/file system and display some (user modifiable) string from the database when showing the name in a web page).
There are technical reasons behind some sites disallowing namechanges, such as if the users have the ability to store files, changing the username may break it if the file paths are based on the usernames. However, a good implementation uses user IDs instead, and avoids such things. For the most part, its a social matter of keeping a permanent link between a user's name and an account. Giving the user the ability to switch names gives other users the ability to impersonate them, or steal their name, and makes it difficult to find people sometimes.
I'd also like to note that there is a difference between login usernames, and nicknames. What you are calling 'username' is moreso a nickname if it can be changed, and usually sites that let you 'change your username' are only letting you change your display name - your login remains the same. Steam is a good example of this, it allows you to change a nickname, but your login name can never change.
I have recently came across this dilemma whether to allow user to change username.
I have entered it on my blog: http://www.dizkover.com/post/423/programming-why-not-to-allow-users-to-change-username-in-social-web-application-design
Related
I am implementing something like Facebook posts, but I only want to limit it for users Alice and Bob to see, but John can't see it. May I know what is the proper way to implement this ? I tried googling but all I found is user based authorization, for IIS.
What I had in mind is to implement another table to add allow list, so if the allow list is empty I assume all users' friends are allow to see, but if there are users in the allowed list then only allowed users can see. However I think this might heavily increase the load of my db?
I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.
My requirement is :
I need to store all the details about a person manually by (for example)Admin.
Which Collection usage is best for above requirement means using Predefined Collection Accounts or User Defined Collection?
My Doubt is : If using Accounts package must be used password but my requirement doesn't contains password only person details.So what i can do for this problem using Accounts?
In case using User Defined Collection then how to provide security for this?
I didn't get any idea about this problem.So please suggest me what to do?
Create a collection, called something like "people", "customers", "students", etc (whatever makes sense for your particular use case). There are several important things you need to do to make it secure:
Use the built in accounts-password package to have your user log in to maintain the list.
Remove the insecure and autopublish packages.
Conditionally publish the relevant fields of the people collection, only to your authorized user.
Set allow and deny rules for inserting/updating/removing people documents. Your rules should check that the user is authorized.
Do not store sensitive information like passwords, credit card numbers, social security numbers, etc in clear text in your database.
Use SSL.
Read and watch these two links, where Emily Stark discusses security (specifically content security policies) in Meteor:
https://www.meteor.com/blog/2013/10/27/defense-in-depth-securing-meteor-apps-with-content-security-policy
https://www.meteor.com/blog/2013/08/02/meteor-devshop-6-devshop-live-security-meteor-ui
Remember that no matter what framework/system you use, there is no such thing as absolute, 100% security. You must use defense in depth to achieve the best possible security that you can.
This may have been answered, I looked but honestly don't know what I should search on. because everything I search on isn't what i want.
Anyway, I am building a ASP.NET SAAS project.
This is my delima, multiple companies will be using the software. I am building it so they themselves can manage their user base.
This is all in one SQL Server DB.
Right now the way it is designed I have a user table that has userid (identity), username, password, companyfk, first name, last name, email. the primary key is userid. The secondary Primary key I say is username.
When someone enters in a user with a particular username it will search to see if that username is taken in the entire table (not based off company).
This could be a problem, I see of people trying to find usernames that work and are professional sounding for the organization.
Couple of options
Do I, have the system make the username itself and give it to them?
Do I partially make the user name and allow them to do the rest. Here I could assign each company a 3 letter abbrev and append it to the user name.
Do I make the username search also be specific only for that company. here the problem I see is when they attempt to login how will I know what company will be logging in. I don't think it is wise to advertise a drop down list of all the companies using the system on the log in page.
Do I make a helper tool like yahoo does that as they are typing it tells them if it is
taken and does a suggestion? This is the more difficult of the 5 choices.
Do I just keep it the way it is and let them deal with the headache (easiest choice of all)
I am leaning towards option (2).
And I am wondering if anyone has thoughts on this.
When in doubt, the easiest way to solve the issue is for them to supply their email address and make that their username.
Considering no two email addresses are the same, I'd say you'd have it made.
Agree with Justin on using email address as it’s the most obvious unique field.
If you really want to go with the username I’d consider requiring company ID as additional field when logging in. This was you can have two identical user names in the table but not in the company.
I'm using ASP.Net but my question is a little more general than that. I'm interested in reading about strategies to prevent users from fooling with their HTML form values and links in an attempt to update records that don't belong to them.
For instance, if my application dealt with used cars and had links to add/remove inventory, which included as part of the URL the userid, what can I do to intercept attempts to munge the link and put someone else's ID in there? In this limited instance I can always run a check at the server to ensure that userid XYZ actually has rights to car ABC, but I was curious what other strategies are out there to keep the clever at bay. (Doing a checksum of the page, perhaps? Not sure.)
Thanks for your input.
The following that you are describing is a vulnerability called "Insecure Direct Object References" And it is recognized by A4 in the The OWASP top 10 for 2010.
what can I do to intercept attempts to
munge the link and put someone else's
ID in there?
There are a few ways that this vulnerability can be addressed. The first is to store the User's primary key in a session variable so you don't have to worry about it being manipulated by an attacker. For all future requests, especially ones that update user information like password, make sure to check this session variable.
Here is an example of the security system i am describing:
"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";
Edit:
Another approach is a Hashed Message Authentication Code. This approach is much less secure than using Session as it introduces a new attack pattern of brute force instead of avoiding the problem all togather. An hmac allows you to see if a message has been modified by someone who doesn't have the secret key. The hmac value could be calculated as follows on the server side and then stored as a hidden variable.
hmac_value=hash('secret'&user_name&user_id&todays_date)
The idea is that if the user trys to change his username or userid then the hmac_value will not be valid unless the attacker can obtain the 'secret', which can be brute forced. Again you should avoid this security system at all costs. Although sometimes you don't have a choice (You do have a choice in your example vulnerability).
You want to find out how to use a session.
Sessions on tiztag.
If you keep track of the user session you don't need to keep looking at the URL to find out who is making a request/post.