I'm new to user authentication and related digital security issues, so I would like to know if the way I'm doing things is ok. Currently the way my server "remembers" users is based solely on the IP address they have logged in from. If they check the remember me option, I store that IP in the database and from then on, every time that machine enters the website, I check if that IP is associated with one of my users. If so, I log them in.
What is good or bad on that approach?
Related
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.
Ok so people keep botting my multi-ogar edited server(which is like an agar.io private server), and I noticed that they all use the same user-agent. How can I use ws to detect how many connections are coming from the same user agent so I can block them?
Something like
if (useragentconnections += 3) {
ws.terminate()
}
Unless you require some sort of account login/authentication, there is no foolproof mechanism to identify the same user-agent. Here are some techniques that can be used, each with varying degrees of success:
Cookie the connection with some sort of unique ID. All webSocket connections start with an http request so you can cookie them. If this is from a browser, the cookie will be presented at each new webSocket connection from that user agent and you can identify them. If this is a programmatic webSocket coming from some custom code, then they may not retain the cookie so this would not work.
Look at the IP address and count connections from that IP address. If the user is an individual home user, then this will uniquely identify any users connecting from that home network. If this is a corporate user, then there may be many users on that corporate network that appear to be coming from the same IP address via NAT so you may falsely identify lots of users within the same corporate/business network as having the same IP address.
Require some sort of account login/authentication and have some terms of service. If you identify misuse either automatically or manually, you can then ban that account.
Require some manual "human" intervention in order to get logged onto your server such as a captcha. This is to prevent automatic programmatic logins and require that a human be on the other end.
I'm looking for information about authentication but I'm very newbie so I don't know any system.
My requeriments are: An user only can authenticate from one computer/mobile device/tablet.
I'm thinking about a monitoring system of MAC address and when the user connect using other device I can see this like an alert.
What other methods are there? Certificates?.
Repeat, I'm very newbie with this.
PD: My app has been development with framework Symfony2
So first of all MAC address is a network local address, which means that after it goes trough router/switch the MAC address changes, so you cannot relay on this. Even if you wanted to lookup interface MAC addres with your client software MAC's can be changed.
Secondly Certificates give you certain properties like nonrepudiation (you can calculate digital signatures on operations that users do and then the could not deny doing something in your application). But Public Key Infrastructure is really hard to manage! You would need your Certificate Authority to give valid certificates, You would need to monitor and update Certificate Revocation Lists to deny stolen/invalid/forged certificates from being treated as valid and authentic.
If it is not a security centric application and after you analyzed your options I would suggest simple form authentication (username/password/captcha). And write mechanizm that would periodicly (i.e. every second) send an AJAX request refreshing user status, thus you could recognize if user closed browser or has opened window. And in your authentication process you could check for other ACTIVE sessions for given username and deny login or act in some other fashion. If you need more informations about authentication I would recomend looking through security patterns
I realize that mac addresses or machine ids aren't transferred over the internet, however, I would like to lock down our subscription-based website security so that only specific computers can register and have access to its resources.
Large organizations will subscribe to our service and will undoubtedly have more than one ip for their organization. As well, we'd like to give the ability for their qualified employees to access the website on devices outside of their physical organization (for road-trip presentations, etc.).
Is there a sure-fire way to achieve this end (beyond the username/password assigned to each account)? If not, what would be the most effective approach?
Instead of restricting access via IP, you want to use something that's actually secure.
Username and password over an HTTPS connection should at least be unsniffable, but you might want to look in to client SSL certificates. They can be configured in Apache or other web server software. If username/password authentication is not enough, this is the next (and perhaps final) step up.
UPDATE:
That said, what many application providers will do is provide a method for subscribers to implement an ACL for their accounts. You can even force people to consider their ACL before allowing them to access your services. Think of it this way:
An account is set up in your system allowing login from anywhere. Upon creation, the ACL is UNSET.
User logs in and is immediately directed to an ACL setup page, where they must provide either an IP address or range or subnet associated with their account. You can be clever and pre-populate things with their existing IP address or subnet, perhaps even looking things up at ARIN to see if their IP is in a network assigned to the company name on their account.
Once the ACL is set (or they have, despite your warnings, confirmed that they want to keep their ACL open), they can access your services.
If they try log in from elsewhere, they (and you) are notified via email (or SMS or whatever) of an attempted breach.
If they no longer have access to their ACL-listed IPs (i.e. IP renumbering due to a new upstream Internet provider and bad planning), they can call your phone support who will validate them by other means. FAX confirmation perhaps, because that's SO secure...
A user-managed ACL is not a "sure-fire" way, but it may be sufficiently effective for your needs, and it will certainly instill a sense in your customers that you have their best interests at heart.
There is no sure-fire way. That's in the nature of networks. You accept data from a remote machine and you have to trust it at least to some extend.
Take the simple username/password approach. If the usename and the passwords match, you have to trust, that they where entered by the person that the username and password was intended for. This does not fundamentally change if you require more data to be send by the client.
I've had to secure a website administrative login system recently, and wanted to get some second opinions on the method that I'm using, since security tends to benefit from second opinions.
Implementation details: Linux, Debian, Mysql, Php
Ip whitelisting system
Parts:
in-database: username, password, email, ip address, ip whitelist
provided by user: username, password
provided by client: current ip address
In addition to requiring a correct username and password, the ip of the system that you are connecting from has to be whitelisted to allow login. Thus the logic of the system cascades like this:
if ip not whitelisted: you cannot log in, you must verify that ip.
Verify your current ip: Go to a page, put in a username, you get a "We will verify that username [someUsername] if it exists and you will receive an automated email for that account directly." A verification email is emailed to the email on file for that account, if it exists & is active. Otherwise it'll just display the message and do nothing.
Verification email: simply has a link with a private key that matches the key in the verification database, links to the site, the page links verifies the ip for that record in the database.
if ip whitelisted: once whitelisted, correct username/password combinations are accepted for login as normal, incorrect ones are rejected.
That is the system. It seems slightly similar to the method that banks use to verify devices, though not identical, so perhaps it needs refactoring. Any advice?
My only suggestion would be to use Golden Questions versus Emails. Emails are easily compromised.
If you aren't familiar with Golden Questions it is where you get the user to import X amount of Questions and Answers. The first time they log on you randomly get them to answer some subset of them, if they do it correctly you can white-list. The process repeats each time they log on using a new IP.
Some added benefits are a faster user experience, and less interruption (they dont have to wait for an email before being allowed access).