Password Number Password

[Nickie Koskinen]

An accurate and up-to-date email address, and/or phone number ensure you never lose access to your X account. There are a few ways to change your password, and keeping this information up to date simplifies resetting your account or password.

Note: Resetting your password will log you out of all your active X sessions. Additionally, password reset via text message isn't available to accounts that are enrolled in login verification. You can only reset your password through email.

If you frequently receive password reset messages that you did not request, it may be a good idea to turn on the Password reset protection in your account settings and set up two-factor authentication.

Thanks for doing this @mkanavakatini! I do think that providing this functionality for the main/default password field (just as 1Password does) as well would be beneficial for a lot of users though. It would be more cluttered if the user wanted to take advantage of this but had to create an additional and unnecessary custom field just to do so.

Currently only in browser but there was some PR chat on me helping bring this to other platforms. Was thinking I can sit on it for a few weeks post release, get some feedback from the community, then look to expanding it from there

I feel that the number could be much higher - not allowing retries is mainly to prevent automated brute force attacks, I think. The likelihood of a brute force attack getting the password right in 4 retries is almost the same as getting it in 3 retries - i.e. very very small. I think this can be kept much higher without compromising security.

Unless you have separate means of restricting access to the login form itself, a good baseline is don't have a hard limit. That's because it's way too easy for someone to be completely locked out of their account.

This is bad because of the denial of service, obviously, but it's also a security concern in itself. It will increase support requests from people asking for their accounts to be unlocked, and the people doing the unlocking will become habituated, and social engineering attacks starting with "hey, my account is locked" become that much easier.

One of the main factors is how big the range of possible passwords is in your specific scenario. Assuming an attacker has no further information about the password and must brute force the right combination he has a chance of 1 to the number of possible password combinations to guess the specific password right.

For example with a 4 digit PIN number there are 10,000 possible combinations (10^4). The chance of guessing a specific combination with one attempt is 1 to 10,000 or 0.01%. Allowing two attempts doubles the chance of guessing it right to 0.02%.

It's up to you to find the right tradeoff for your specific scenario.But keep in mind that brute forcing is not the only attacking method you may have to consider. Some attackers may have additional information about the target and can therefore improve the chance of guessing right by trying a more likely combination (eg. if a targeted person uses personal information within its password and the attacker knows about it).

The problem is Denial of Service. It can happen two ways: 1) Attackers runs brute-force in such a way that it ends up saturating the server, and now nobody can access the service. 2) Users (malicious or not) may try too many times, leading to the access being locked.

It should be noted that only locking the IP at firewall level or web server configuration level will have a real impact in server load. Yet, if you are only locking the origin when paired with the given account, the logic will be in server side code. It is also true for the rest of sulutions that they require server side code.

"Lock": "prevent access until further authentication is provided", to provide further authentication means to follow similar - if not the same - steps as those provided to users who forgot their password.

"Origin": the IP, user agent, or other techniques the server may use to identify the source of a connection. If used, it should be mentioned in the privacy policy that the server will log such information.

Using a CAPTCHA may become an inconvenience for legitimate users that may be having problems typing the password. Current reCAPTCHA mitigates this problem by using behavior analytics to identify human users.

Using a retry time reduces the usability of the service, as it becomes an inconvenience for legitimate users that may be having problems typing the password. This is worst than CAPTCHA as it is cognitive downtime.

Brute-force/dictionary attacks are still viable if the attacker performs an attempt once each hour or so. Alternatives to deal with this problem include security policies to change the password frequently (which the user may render ineffective by choosing similar passwords) and IDS or other analytics to detect attackers (which could be circumvented by distributing the attack from multiple sources - hopefully that is expensive enough to be a deterrent itself).

Also, failed attempts by an attacker in a third location will lock out the legitimate user. Combining origin lock with account lock would allow more granular control. In this case, the account would be locked only for the origin from where access is being attempted.

Combining origin lock with account lock would allow more granular control. In this case, at first the origin would be locked only for the account it is trying to access, yet an origin that is locked for many accounts can be locked globally.

Two-factor authentication is the only solution that can actually make brute-force/dictionary attack ineffective. That is accomplished by requiring a single use code, which being single use won't be guessed by attempting multiple times.

Between retry time and locks, consider that the minimal viable implementation is similar: to lock an account you add a field to the account object/record marking it as locked, and then check that on authentication... to put a retry time, you do the same thing, except what you store is the time at which authentication is valid again.

Finally, two-factor authentications have benefits that surpass the above solutions. Yet it is the most expensive to implement as it requires connection to a third party service (email server, SMS service, dedicated app, dedicated hardware, etc.).

n1 should be an estimate of the number of attempts a person may do if they have problems typing the password. 2 attemps would be the minimun n1 because that accounts for the basic caps error. Note: gmail allows me 20 attempts before using CAPTCHA.

n2 should be an estimate of the number of attempts a person would do before going to access recovery mechanism. There is no hard minimun, in fact it can be applied as soon as you apply CAPTCHA and have increasing time intervals to wait. In my opinion n2 = 3 * n1 is good starting point.

n3 should be an estimate of the number of attempts at which it is more probable an attack is being made. Consider that CATPCHA and retry time should deter any manual attack, so n3 need not to be much higher. In my opinion, n3 = 2 * n2 is a good starting point.

Note about retry time: The interval the user must wait can be increased on each attempt. This allows you use a very small initial interval (for example 1 second) and build up from there until a hard cap (for example 1 day).

Note about counting attempts: You should avoid an overflow in the attempts count. If you are storing the number of attempts in the account object/record, handle the overflow. If you are doing a query on logs to get the number of failed attempts from the last successful one, consider adding a time interval (that will also cap the query time).

The number that is considered "safe" is fairly arbitrary because the risk is based on the value of the data, the level of allowed and enforced complexity, min/max password length and possibly other security measures you may have implemented.

The typical number is anywhere between 3 and 10. If you implement increasing timespans between unsuccessful attempts, you can go towards the higher end but only if you allow/encourage or enforce relatively high password length & complexity.

What you need to remember is that most people don't come up with random passwords. In the UK for example, the most common pin is 1966 and another common one is 1066 - both famous dates from history. There's more to chose from in a word of course but people still often end up with common words. So allowing 4 guesses on a short password is more effective than you might think, especially if your system allows further attempts after a timeout.

The general idea is that it should make the process take long enough that the "bad guy" just gives up and moves on. That being said it's important to not tie attempts to a login, but to an IP and IP range as well.

Also a lot depends on your "restore access" process. Lets say you run an API that allows customers to get shipping status. If locked out, they have to call support and verify. In this case I would probably allow something like 120 attempts every two minuets and something like 400 attempts in a 24 hour period. That may seem high, but with the "restore" policy, your customer business could be down for hours or days, if one of their scripts goes haywire.

I like the 3 limit (per hour. and perhaps 6-9 failures per day, 12-18 per fortnight), but duplicate attempts with the same passcode (in 3 group) should not be counted. If you have actually forgotten your password then you probably do not log in that often, therefore it can wait. Better than having somebody given too many attempts per day to guess it.

But under this, if you happen to be already locked out, you the user will know someone has been trying to guess it, and so we need a strategy on how to deal with that - especially when you want to log in.

This article provides information about resetting FCC Registration Number (FRN) passwords. To reset your FRN password, you will need to create a Username Account by accessing CORES and associate your FRN to the new username account. Once the FRN is associated to the Username Account, your username account password will now be your FRN password. Tutorial videos on new CORES/Username accounts can be found at -databases/fcc-registration-system-cores/commission-registration-system-video-tutorials

c80f0f1006