89

I'll start with what to do with your current system: Get in and make a backup of everything. Unless you can demonstrate major losses ($10k+), I wouldn't even begin to think about involving law enforcement. They have their hands full, and given the current patterns on the internet, it's highly likely that your culprit is in a different country than you are. ...


57

Login brute-force protection can be enforced in three ways: Temporary Lockout Permanent Lockout CAPTCHA In my perspective, CAPTCHA is the most reasonable solution to avoid the risk of bruteforce as well as denial of service due to account lockout. You might have seen a CAPTCHA appearing on the login pages of Facebook and Gmail in case you enter wrong ...


25

Yes, some websites do that in order to prevent bruteforce or password guessing attacks. Instead of banning the user, the website should ban the IP address from accessing the website. If the attacker is hopping from one IP address to another and doing the brute force attack, then in that case the website can ban the user id and notify the banned user ...


21

David's answer gave some excellent recommendations (which I highly recommend you follow). I will focus my answer instead on your specific fears in hope to alleviate them. What I wish to accomplish is to acquire as much information about the hacker as possible. I want to download my legacy backups. I want to get in and out as soon as possible. You say you ...


8

To turn your attack scenario through 90 degrees; consider the attacker who, instead of using a list of passwords against a single user, instead uses a single password against a list of users. Imagine I (as the attacker) don't care which account I get access to, I simply want access to any account (say, a bank account). Instead of trying to brute force a ...


8

In this case you don't know how the attacker was able to enter, so you are right to be concerned that the exact same thing will happen again even if you do a complete reinstall. To deal with this problem, you should configure your system for remote logging. A dedicated separate computer saves system logs which cannot be tampered with. You should configure ...


7

It's not a "security flaw" in the sense that something is broken or that the flickers indicate a bug or an attack. Rather, it's an issue with the underlying graphic stack of Linux and the lack of semantics for privileged desktop clients. Just to get this out of the way, the flicker is most likely caused by a poor interaction between your GPU drivers and ...


7

The NIST guidelines say this: the verifier SHALL effectively limit online attackers to no more than 100 consecutive failed attempts on a single account. 100 attempts seem pretty high compared to your quoted five or six attempts. However, apparently NIST still thinks it is adequate. There is a big difference between "at most 100 attempts" and "an ...


7

My precautions are to stay behind a killswitched vpn and spend as little time there as possible. That is infosec voodoo. Assuming you're behind a router with PAT, the attacker is going to have no way to connect back to you. In fact, the VPN creates a tunnel through the PAT layer, so you're actually increasing your exposure by using it! (Althought the VPN ...


5

Yes and it has been done before. This can cause a big problem with certain websites. OWASP lists some examples of how it can go wrong on their page on Blocking Brute Force Attacks... Account lockout is sometimes effective, but only in controlled environments or in cases where the risk is so great that even continuous DoS attacks are preferable to account ...


5

Other answerers have already offered some valuable means by which a website can prevent abuse of anti-password-guessing measures to lock people out. Here is another one: IP whitelisting. @Skynet already suggested blacklisting , but with attackers nowadays being able to build botnets well over a million devices in size, that might not be very effective ...


4

Account lockouts on remote applications (e.g. where the attacker can't reset the number of attempts without further work) are mostly to prevent easy brute force attacks against accounts. If you have users who select very weak or common passwords, and your system doesn't make any attempts to prevent the use of these, it's entirely possible that an attacker ...


4

Let's examine why this person has multiple accounts - the general explanation is that there should be an additional barrier to access administrative functions, reduce logins to that account, etc (https://cloud.google.com/resource-manager/docs/super-admin-best-practices). You can consider their admin account their 'primary' account (even though it's not the ...


3

You're on a hostile device (a user's computer), so have to assume that they can manipulate your code. Therefore, you can't limit in that way: you can ensure that the passwords used are long enough to withstand brute force attempts (e.g. a SHA-256 hash would mean that an attacker would need to try millions of attempts per second in order to be sure of ...


3

The first step is to identify if the attackers even managed to gain access to any accounts, or were still trying to get in. Head over to Have I Been Pwned? and check if any of your accounts have been leaked in the past. If that's a 'yes' - check if you were reusing your passwords. If that's a 'yes' again, go reset them and ensure that you use unique ...


3

You just found the issue, you didn't take advantage of the flaw and never intended to do harm (I assume you wouldn't do any harm to your friends). However, every company should be happy if you report the issue to them. Big companies like Twitter or Facebook even pay nice bounties for this. You might check out HackerOne if the company you are talking ...


3

RFC 4226 doesn't tell me what others are doing, but it does have some viable suggestions in its Section 7.3. Apparently, after the 5 attempts per account and device are exhausted, either a full account lockout or exponentially increasing delays should kick in, semi-permanently. The counter must apply across login sessions and across individual TOTP tokens, ...


3

Drawbacks I see from this approach are: More complicated to implement, especially over a scalable platform, cross thread. May not be effective across load balanced servers. Users may need to be patient. For the above reasons it is not widely implemented.


3

Most hosting providers make available a small OS image (the purpose of which is to facilitate initial OS install when a client wants some custom OS, or to fix errors preventing the OS from booting; typically called “rescue system” or something) which you can boot and gain access to the compromised VPS without ever launching any malware the attackers could ...


3

Why not have an additional field for special users? Don't rely on just the password to set your policy -- define your policy in an appropriate field. Username/password is used to authenticate a user. For authorization, build that into your model.


2

You could standardize on all secret questions being number based. Then, when the questions are asked, they could include a bit on the end to add or subtract some. So for instance, the questions would be: What is the last four of your social security number plus 11? What is the street number of the house you grew up in, minus 2? What is your birth year ...


2

I am not sure exactly what your scenario is explaining. I understand the hacking part, but we need more information. How are they accessing your system? Locally or over the network? Are you concerned about more of a software tool being used to crack your user account on the Windows 10 machine? There is many different ways to be attacked or involved in a ...


2

I'm not sure why it'd be any more difficult to implement than locking the account, or why load balance rs would have any effect. Both approaches require centralized co-ordination about what to do (lock vs delay). I think the main reason is that it's strange behavior, and makes your website look like it's broken (I don't think this is simply patience). ...


2

There is no right or wrong answer. If you implement a more aggressive lockout policy then you will be more secure and you will degrade your user experience. You have to assess where the right balance is for yourself, based on your application's requirements, your knowledge of your user base, the value of the assets you are protecting, your threat model, ...


2

One possibility is that her passwords are being synced through the browser. If this is true then even if she changes her password it can be updated on any synced device (convenient for someone who is not in this situation). To remedy this, she will need to change her browser sync settings and password, then change her facebook password (and others) again. I ...


2

As security practitioner (CISSP) we always have to fight with/work with/debate with the organization between the balance of confidentially and availability. Therefore, in my environment we allow users to unlock their account if they provide sensitive information that an hacker should not know. It just created another step for hackers and to allow ...


2

There is really no "correct" answer that we can give. You need to understand the risks and impacts in order to make a sensible decision. Only you can do that with an understanding of the value of the data and the cost of a breach. Having said that: Using userid on its own would give no real security and it is common for a system to remember the userid in ...


2

Usually account lockouts doesn't terminate a session, otherwise that could be a potential DOS scenario. For changing passwords, most of the companies that I've worked with, we also didn't terminate the session, but we had a SIEM and SOC in place that would contact the user via phone when that happens. If you have mitigations in place (such as a SIEM/SOC ...


2

Limit the amount of attempts that can be made within the 30 seconds. So if you have a token that is valid for 30 seconds and is 6 digits (for example), and you limit the amount of attempts that can be made in 30 seconds to say 5 (again as an example), then the chances of success of bruting forcing the second factor are 0.0005000005000005%.


2

You are correct, the ideal off-boarding process would be to disable the user. However there are situations where the user has company data that is located on his personal profile, be it on premise or in the cloud. Since cloud and on-premise services usually could have some kind disabled user data purging configured. You'd rather be on the safe side and ...


Only top voted, non community-wiki answers of a minimum length are eligible