I have a potential customer, a restaurant, for which I would like customers to use a Qr Code to access a form to rate the dish they have eaten.
To make it as simple as possible to keep the user until the end of the notation, I am looking for a way to authenticate the user without going through the creation of a user space. In my eyes, I doubt the usefulness of the latter on the site of a small structure such as a neighborhood restaurant. He has not yet established his strategy for his web presence. At the moment, he just uses Instagram.
So I'm looking for a way to authenticate my user without their registration and at the same time certify their reviews and ratings.
I thought :
to the mac address or phone number but it is a violation of privacy,
the IP address: it can be dynamic,
a cookie/localStorage: the user can refuse or delete it, and like again the dish.
I will use Nodejs, Reactjs and any database.
Related
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
Below is a proposal for dealing with a situation of website security. I am wondering whether it seems feasible, from both a technical and usability point of view. I want to make sure that the proposal does contain any glaring errors.
A. THE WEBSITE
The website in question is a school website where students may purchase various items. These students get an account on the website with a username and password, which they can use to login. Once they login, they have access to protected pages with private content which are unavailable to the public at large.
B. THE SECURITY CONCERN
The owners of the website wish to prevent a situation where a single student signs up on the website, obtains a username and password, and then circulates those credentials to a circle of friends who are then able to login to the website and illegally view the private content.
C. THE SOLUTION
The central idea we have come up with to deal with this security problem is to permit each student to login to the website on two devices only. Once a student logs in on two different devices, they are restricted to those two devices. If they then attempt to login on a third device, the system would simply not permit them to do so. It is our understanding that other websites offering private content, such as Netflix, use such an approach.
D. IMPLEMENTATION
Two ideas come to mind to implement the above security measure: a. IP address. b. Cookies. We rule out IP addresses, which can change, and choose cookies. Websites such as amazon.com allow their customers to login once, and then whenever they return to the website, they are always recognized. This is almost certainly achieved through cookies.
Thus each time a student logs in, we will store on their device a cookie. And we will also store this cookie in our database under that student's account. Thus each time a student logs in on any device, we will check whether the device they are currently logging in on contains the cookie we have stored for that student. If it does not, we will know that the student is logging in on a different device. We will thus be able to know how many devices the student is trying to login on.
E. DRAWBACKS
We have identified at least three possible drawbacks to this approach:
Clearing Cookies. People can, for a variety of reasons, choose to clear the cookies from their computer.
A bona fide person may occasionally not have access to their usual device, and wish to login on a different computer.
People do purchase new devices from time to time.
These are examples of situations where a bona fide user, for legitimate reasons, wishes to login, but will be unable to, due to the website's security restriction of two devices.
We have some ideas as to how to build logic into the system to deal with such situations, which we may implement in the future, but for the time being, we feel that such situations are sufficiently rare that we do not need to handle them programmatically.
Rather, for now, in the event that a student is locked out, they will get a screen with a message explaining why we have not allowed them into the system, and a button which they can click on which will automatically generate an email to the site administrators.
The email will inform them that a student wishes to login on a third device. The administators can then contact the student, and, if they are satisfied that the need is bona fide, they will be able to take steps from the CMS to allow that student in.
The size of the student body is sufficiently manageable that the above approach should be feasible.
F. FAIR WARNING
We will inform the students of these security measures when their account is activated, in order to prevent unpleasant surprises.
This is a typical example of trying to fix via IT a real-world policy problem; in this case, forbidding students to share their credentials.
The solution you are proposing limits usability (for the reasons which you already listed under Drawbacks) and does not ensure security because cookies - and especially content - can be copied around. In short, it is feasible, but can easily be circumvented. It's up to you to decide whether it is worth to implement it. It would probably be better to enforce the "no sharing credentials" rule e.g. set up random checks and send any student caught violating the rule to the Dean.
I was thinking of creating a voting app. The general idea is
browse a gallery
an awesome pic grabs your attention
hit the vote button underneath it
code magic happens
vote is counted
at a certain date, vote buttons become non-active and the app counts
the votes
This will be a web app, which means html5-css3-express.js-redis framework, or something similar.
How can I ensure that the user cannot vote for the same pic twice? By making him sign up? Huge procedure for just a voting app, dont you think? Plus, I guess I will also need a CAPTCHA thing to avoid unwanted, mass sign up.
But if I use coockies of HTML5 local Storage API, what is stopping the same user to clear his/her coockies and vote for the same pic again and again?
What is the best method?
Thanks alot
The most secure way is by using accounts to keep track of who has voted. Accounts are easy to implement in your application and you don't even need to hold the account data yourself if you use a service like Passport.js. You'll likely have a database set up already which makes it easy to keep account data as well.
The other method is to keep track of IP addresses but this has some issues (say, if a user uses a proxy). Also an IP address will cover all clients on a network means if one person votes on an image, all others will be unable to afterwards.
Easy way may be using npm package mongoose-voting where all logic for voting is already implemented.
There is also requirement for keeping track of users, so if you don't want a user to sign-up, you can automatically create a user by using the visitor’s IP address as the user’s ID.
There are many ways to manipulate vote results, but at the level you described, most of them are unnecessary.
well you dont need to build a login system these days as you can use any of the open id login authentication.E.g providers are facebook, google, yahoo and twitter.
We have an MVC application which we need to do some security check before we let user to start using system. The use case is below;
We have Company table which stores valid IP addresses(also range). And company has associated users. If a user logs in from an unidentified email address, we need to make sure that user is still working for corresponding company. Therefore, we use company email address to validate the user.
I have 2 ways to implement this;
1) Generate a token, and send a link with token as query string to the user, when user clicks on this link, I will validate the user for a certain period of time(1 day)
2) Sending user's email a 6 digit number when user successfully logs in, and ask user to enter that pin number. If the pin is valid, then validate the user.
I recently see many big companies using pin numbers and your mobile no. That made me think that the second method is more secure than the first one(I have no facts, only assumption). Is that true?
Which one of these methods is more secure? if non of them, what is the best way of implementing this use case.
Thanks
Have you looked at IP spoofing - I wouldn't recommend using IP addresses for security.
1) - I don't understand how that is secure...
2) - called two factor authentication and would typically involve sending a pin to a mobile, and not an email.
If implemented properly 2) should be secure, but that is an additional step and not a complete security model. I would start by looking at the authentication that is part of MVC5.
If you want to have a jump start on two factor authentication without building a solution from scratch, look at this open source framework that can easily integrate into an MVC4 application. As Joe R mentioned, relying on IPs for security is not a standard practice.
We have an application that includes a voting component.
To try and minimise voter fraud we allow N number of votes from the same IP address within a specific period. If this limit is hit we ignore the IP address for a while.
The issue with this approach is if a group of people from a school or similar vote they quickly hit the number. Their voting can also occur very quickly (e.g. a user in the class asks his classmates to vote which causes a large number in a short period).
We can look to set a cookie on the user's computer to help determine if they are sharing accounts or check the user agent string and use that too.
Apart from tracking by IP, what other strategies do people use to determine if a user is a legitimate or a shared account when the actual IP is shared?
If your goal is to prevent cheating in on-line voting, the answer is: you can't, unless you use something like SSL client certificates (cumbersome).
Some techniques to make it harder would be using some kind of one time token sent trough e-mail or SMS. Every smart kid knows how to cheat control cookies using privacy mode of modern web browsers.