72

A limit is recommended simply to avoid exhausting resources on the server. Without a limit, an attacker could call the login endpoint with an extremely large password, say a gigabyte (let's ignore whether it's practical to send that much at once. You could instead send 10MB at a time, but more quickly). Any work the server needs to do on the password will ...


40

You're looking at it just a little bit wrong. Probability can be tricky, so the best way to make sense of it is to simplify. Rather than looking at an ~8000 word list, let's look at the following word list made up entirely from 10 letter words: california everything aboveboard washington basketball There are exactly 5 words on my list with 10 characters ...


18

You are probably confused by the fact that sometimes you compute entropy using considering all the possible characters, other times you consider words, other times you even consider other different rules. Entropy is just the amount of "randomness", or "noise" that an attacker cannot know in advance, provided that the source of this ...


17

Real-world password strength has very little to do with raw, per-character Shannon entropy (which is about both information and randomness). The insight here is that people compose passwords from "chunks" of information that are much larger than a single character. Per-character entropy only matters when you are doing one of two things: Assessing ...


16

Passwords in general should be stored hashed on the server, no matter if they are transferred within some HTTP POST body as a result of a form submit or if they are transferred in the HTTP header as in Basic authentication.


12

Yes, it should be. The default backend for HTTP Basic Auth is htpasswd, and it encrypts passwords*: htpasswd encrypts passwords using either bcrypt, a version of MD5 modified for Apache, SHA1, or the system's crypt() routine. Files managed by htpasswd may contain a mixture of different encoding types of passwords; some user records may have bcrypt or MD5-...


11

Passwords should be hashed/salted. In addition to possible DoS attack risk from GB-size passwords, OWASP recommends limiting the password length because: Some hashing algorithms such as Bcrypt have a maximum length for the input, which is 72 characters for most implementations (there are some reports that other implementations have lower maximum lengths, ...


9

Entropy is not a property of passwords; it's a property of how they were chosen. If you use N random bits to select a password uniformly at random from a list of 2N candidates, then the password you picked has N bits of entropy by virtue of how it was chosen. It makes no difference how long it is or what characters it uses. When a password strength checker ...


5

I do password cracking for customers from time to time (to know whether their employees use good passwords). Here's how I would attack your passphrase or password. First off, we should assume the key or password is secret, not the method that it was made with (Kerckhoff's principle). I may not know the details, for example which dictionary you used, but I ...


4

I doubt that your account is hacked. I think what you experience here is cognitive bias instead. Such phishing mails are pretty common and one even gets these without having iCloud or Paypal accounts. Usually one simply ignores these mails. But if one suddenly gets such a mail after creating or using such accounts, one is prone to assume a causal link ...


3

If I understand correctly, it sounds like you logged in, then you navigated to the change-password page, then the site populated the disabled password input box with your existing password, then you were able to recover your existing password from this disabled password input box. If that's the case, then the site is storing your plain-text password - ...


3

The bigger problem is not your linkedin account getting hacked, it's Linkedin itself getting hacked and all users emails + passwords becoming avaiable To unlikely? It already happened before. Adobe, eBay, Yahoo, PlayStation Network, the list goes on... all of these companies have had their database hacked and users emails and passwords leaked in the past (...


2

The part after the last $ is base64-encoded, which is a reasonably compact (four characters becomes three bytes) way to represent binary data as common, printable characters (not ASCII control codes or anything requiring the high bit). The second hash is simply hex-encoded, which is less efficient (four characters becomes two bytes) but easier to read, ...


2

The first example looks like a shadow file format: ID (admin) Algorithm (1 = MD5) Salt (none) Hash (oLN1UCc1Y3T30QkMcKMSx0), with the hash in what seems to be Base64 format. The second (5f4dcc3b5aa765d61d8327deb882cf99) appears to be a hex string of 128 bits consistent with being an MD5 hash as well. However, converting both to binary & then back to ...


2

I personally use a very strong password of 35 characters mixed with symbols and keep my DB file on google drive. If You do not keep millions of crypto or something else that you can not get back you should be fine. So even if somebody will steal Your Db and even if somebody will be able to encrypt it ( I highly doubt it) there are other ways how to protect ...


2

The general idea is that any secure process must be able to remain secure even if the process is known. In this scheme, you've just added a step: encryption. But you have to accept that people will know that you've added encryption and what type. This means that you've only made the process of checking passwords just one step more difficult because there is ...


2

If the VNC connection is not encrypted, anyone on its path can capture and inspect the traffic. VNC uses the RFB Protocol (Remote Frame Buffer), and Wireshark, for example, already have dissectors for it, so don't count on it. Some VNC solutions have proprietary plugins that add security (UltraVNC is one of those), but you don't need that. If you use a SSH ...


1

I would consider PIN's in terms of usable security for the end user where there are additional contextual security controls in place to protect access. Some examples could be where an account has been authenticated and authorised and a PIN is used to regain access to the service within a time limited period for the same device. PIN's are typically used in ...


1

The term PIN is commonly used when only a numberpad is available for the user (SIM card, credit card, ...). Today the term seems to be extended to every kind of password of digits only. PIN can be considered as secure when the following conditions are enforced: the authentication is blocked after 3 failed attempts all PINs are equally likely the PIN is used ...


1

It's not clear what you are really asking. From an usability point of view, requiring a single password is preferable. More than "too much hassle" I would describe it as "users being confused". I wouldn't consider users using the same password for both fields as a failure in the schema. Plus, you could always make the app not allow ...


1

If you store all the password history of a user, by mitigating one weakness you end up introducing another. Weakness 1: users might reuse old passwords, possibly invalidating a security control (the security control that was meant to stop attackers from getting persistent access once they have stolen a password). Weakness 2: all the history of passwords is ...


1

Just to be clear, they shouldn't be storing previous passwords, but hashes, preferably salted. Storing a password in plaintext is a no-no. Storing hashes for the last few passwords may be reasonable although debatable. Storing the whole history sounds overkill. You are wasting storage in a vain attempt to protect people from themselves. Too many password ...


1

The entropy (number of possible passwords) you lose to those requirements is trivial compared to the number of people who would otherwise use one of the 100 most common passwords out there. So no, there's nothing wrong with publishing the requirements in detail, not if they're any good. Of course, that last clause matters. Most of the requirements in that ...


1

Provided a proper password hashing is used, hashing and salting alone is sufficiently secure. Additional encryption does not add any relevant security to it.


1

As long as you are very careful about the client-side hashing function, it would seem like there is no reason you couldn't. But wait! You do need to remember that not all passwords are for web-based applications with a single client written and distributed by the author. Instead, it could be an arbitrary API. Adding the requirement that the password must be ...


1

I would suggest using crunch To generate the output first with the following command options: crunch 6 6 -t ,%%%%% -o 6chars.txt Then you can feed that 6chars.txt output to your software you are trying to brute force.


1

You can generate a list of passwords matching the format you want using hashcat: hashcat --stdout -a 3 ?u?d?d?d?d?dhd will generate Udddddhd where U is upper, d is digit, but the last 'hd' is just 'hd'. More information about hashcat mask mode is here. Once you've generated your wordlist, you can use a tool like Hydra or Hatch to feed those passwords into ...


1

I recommend that you take a step back and reconsider the use of bcrypt for your use case. brypt and similar functions are designed to address brute forcing of easy to remember passwords. They are deliberately designed to slow down an attacker so that brute forcing gets too costly.They also include a random salt so that precomputed hashes (rainbow tables) get ...


1

What use case do you have for not having a token ID ? Anyway if you use long random tokens (having sufficient entropy), then both bcrypt and salt become unnecessary and you can speed up operations by using unsalted SHA2. With the same premise your proposed solution is also acceptable, though it seems unnecessarily complex. (edited after comments)


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