It seems to be common practice to lock user accounts after enough failed attempts in a particular time window.
I am wondering how you prevent denial-of-service attacks since a malicious user who had the username of someone he wished to DoS could simply rapidly make logon attempts.
Is the remedy to lock the account for only the IP address of the user who exceeded the logon attempt count+window ?
Is there any better way?
EDIT:
I don't want to make my users solve a captcha on each login attempt.
You shouldn't block the user by its IP, because maybe it is a real user that forgot his pass and did the retries manually.
The worst thing (business-wise) is that a real user will not be able to access your service.
So, your problem is actually "How do I know that the user is not a robot?".
One of the most popular ways to deal with this is to use a different mechanism for multiple login attempts.
For instance, Google uses Captcha after about 3 trials,
so an automatic bot will get stuck on this stage.
Of course it is possible to get the bot to read the captcha, but it's a start.
You can read more about captcha implementation in their official site: http://www.captcha.net/
Other alternative ideas here: http://econsultancy.com/il/blog/63144-six-alternatives-to-using-the-dreaded-captcha-images
Related
Suppose I have an account created on a website (in specific, a PS Network account or Google account), and I only know the login email, but not the password (with no access to the Google account in the PSN case).
Is there a way for me to verify if a given password is the correct one using only HTTP requests or something similar using code? This is to save me the time of trying multiple passwords and having to wait for a server response until I find the right one.
Details:
I'm not trying to hack into someone's account.
I tried to log in to a secondary PSN account I created years ago but I didn't know the password, only the email (I also created a specific google account/email for this purpose, so I don't remember its password either). Even though I don't remember the exact password, I know which combinations of specific words and numbers I might have used back then. But I want to run through "all" the possible combinations with code, instead of doing it manually, to save time and effort. Is there any URL to which I can make POST requests to try and log in using only email and password in the request body, and verify if login was successful? (either on PSN or Google, either one will give me my PSN account back)
Thanks in advance
I tried looking for REST API and URLs that allow me to do this, but it seems to me that Google in specific has gone strict on this, requiring more than just address and password. For the PSN account, I tried to sniff around using developer tools to watch which URLs are requested when I try to login using the Sony website interface, but I can't understand which requests are doing what.
What you want to do is a popular method for hacking account access. it is called bruit force where by the hacker you continues to try passwords over and over again until they gain access. A dictionary file is often used containing combinations of specific words and numbers
No system is going to have an endpoint that will make it easier for hackers to gain access to user accounts by force.
May I suggest using a reset password account recovery option available through most login services these days.
instead of trying to bruit force your way in. Most authorization servers will lock an account after 5 bad attempts.
This is a simple question about terminology.
I know that when MFA is used after login and prior to allowing a sensitive operation, it's referred to as "step-up". However, some applications simply ask for your password once more instead. An example is Github asking for your password prior to you changing some repo settings.
Does the "step-up" term also encompass asking for credentials or password again? If not, what is that called? "Re-authentication"?
Yep. TL;DR: Reauthentication (no dash)
I was recently researching this and came upon your question. Here's how I approached the question, and what I discovered.
I was looking for what to call the design pattern where, once you’ve logged in, if you want to access something like credit card, banking, or other secure, PII, you must first enter your password a 2nd time (once per session) before you can access the protected information.
As you mentioned, it’s sort of like 2FA, but you’re using the same factor twice (password).
An example I see daily is on my Mac, which is encrypted with FileVault, so I login (decrypt) then login again (actual login). Or on banking sites where you log in to authenticate and gain access, but then you must enter your PW a second time during that session to see/do any real transactions.
Google calls this pattern “Authentication” (e.g. when requiring a 2nd pw entry to buy something on a device) which seems WAY too vague for me. So I dug deeper. https://support.google.com/googleplay/answer/1626831?hl=en
IBM calls it "Forced Reauthentication" https://www.ibm.com/docs/en/sva/9.0?topic=reauthentication-concepts
And lastly, NIST.gov calls it "Fixed Periodic Reauthentication" https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
So really, it's just reauthentication.
I'm creating an app where user submissions (e.g. photo) are designed to be captured via crowdsourcing. The app connects to an API using an API key, and the app then submits the data anonymously.
We want to avoid the overhead of people creating user accounts and passwords.
However, it seems to me this is vulnerable to a the problem of the key getting revealed. The result is that spammy submissions could be made much more quickly via browser/wget HTTP requests. Because the app is installed on people's devices, it would take a long time for us to be able to withdraw a key and replace it with another.
The approaches to deal with this problem I can think of are:
Hope that the key stays secret. Not ideal from a risk perspective. Using HTTPS for the API endpoint would reduce this risk, but presumably the app could still be decompiled to reveal it (not that in practice anyone would really bother)
Store a fixed username and password in the app, and submit as that. That basically seems to run the same problem - if the credentials are leaked then this has the same problem as 1.
Require a first-run fetch of a token to auto-create a username and password. However, if the key is compromised then this is no more secure. Also, this means we end up with lots of junky usernames and passwords in our database that really don't mean anything.
Not considered desirable: force users to create a username/password. However, that then means a lot of messing around with accounts, and compromises the anonymity of submissions, meaning data protection implications.
Are there standard patterns dealing with this scenario?
The first time the app runs, it could get a random token from the server, store this, and use it on all subsequent requests. The server just checks that the token is one it produced itself. After each request, block the token for 5 minutes (or make a counter so 10 requests are ok but the 11th gets blocked, depending on your use case). When a token gets misused, block it, so the user will have to deinstall/reinstall your app, or, if he made a script to emulate the app, he'd have to re-register after every few posts (plus you can limit the numer of registrations per IP or something similar).
You can assume any fixed credentials will be compromised. A good attacker can and will reverse-engineer the client. On the flip-side, a username/password combo will compromise anonymity (and nothing is stopping a spammer from creating an account).
Honestly, this is a very difficult problem. The (inelegant) solution involves something like a captcha where you provide a problem that is difficult for a bot but easy for a human to solve (for the record, I think captchas are almost useless, although there have been some less annoying alternatives).
Alternatively, sites like Facebook use sophisticated algorithms to detect spam. (This is a difficult approach so I would not recommend it unless you have the manpower to dedicate to it).
I am thinking for ways to implement a mechanism which enables a user to vote,without logging any of his details. Each user has a set of attributes that enable him to vote. For eg. Id,name,email-id.
Using these attributes we must guarantee that the user can vote for the first time. During this time,complete anonymity is guaranteed.
But if the user comes for a second time to vote,he should not be allowed to vote. Is this remotely possible?We are not storing any of the information related to the user.No ip adddress,email-id or student id. They are just used as a means of authentication.
I read many research papers for this but not able to find anything specific.
a mechanism which enables a user to vote,without logging any of his
details
Sure you can. Just don't log anything. But you do need to store information about which user has voted. You actually need info of the user not even the machine the user used as the user could vote from another machine.
I have an corporate intranet project that needs logins, but doesn't need high security. Impersonating a different user is not useful or very desirable. In similar intranet systems, everyone has the same password as setup by the admin.
I'm hoping to get some suggestions on what password alternatives I could consider. My first thought is to show each user 8 images and have them click on one to be their password. Would this be too annoying or problematic in someway? What other ideas would you suggest?
Why not just use a text based password? It sounds like you are over-complicating things by including images, especially if, as you stated, don't need "high security". I wouldn't consider a text based password "high security" but it does meet your requirements of a login on the intranet. A lot of products have built in functions for passwords so it would be dead simple to implement into your project if you have this available. I'm suggesting you keep it simple and don't assume that impersonating a user isn't something that won't happen without at least a password. You'd want to know who made changes or have some logs that identified who was the user at the time of a certain event.
Remember, security should be baked in, not sprayed on!