New answers tagged

1

This is a reasonable idea, but there are some problems with coordinating massive centralized efforts. KOLANICH already suggested SRP, very nifty and even more secure protocol for remote passwords. The main problem is that very few people actually care about security to force whole IT industry to change what's already working. Meanwhile privacy freaks can ...


0

Because of legacy. It is really possible to implement https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol and build it into browsers with some modifications adapting it to the Web. But the industry prefers centralised solutions such as WebAuthn with TEEs because this way it is more harmful for users' privacy and security and more beneficial for ...


3

What are the downsides? None, really, aside from significantly increased complexity1, which is rarely a good thing, as well as high migration costs for literally every website with a password field, which is also not a good thing. But let's consider the implications anyway, to see if they outweigh the costs. There are two ways you could handle this hash: ...


9

First of all, I totally agree with MechMK1 on the proper algorithm to generate cryptographically secure uniformly distributed random number between 0 and 10000. However: there's no reason not to think about the problem with security in mind Lets. Random number between 0 and 10000 contains 13.29 bits of entropy. Random number between 0 and 2^14 % 10000 ...


14

Yes, you need at least 14 bits to generate a number between 0 and 9999. In order to avoid bias, you can generate 14 bits of random data using a good source of randomness. If the result is <= 9999, then you can use it as your PIN. If the result is bigger, throw it away and try again. How much does this waste? In the best possible case, your bits would ...


2

There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling,...


0

Storing credentials in an encrypted Veracrypt container would be a great thing, but you should consider the following: a stronger password for the accessing the container: 16 characters should be a minimum to consider make sure the operating system you access the container from is not compromised: if you have an infected OS stealing your container password ...


0

To avoid username enumeration on the user registration page, an application can allocate username automatically based on the user's email address rather asking the user to choose one of there choice. This way it can be prevented username enumeration or registration page. Also, we should take forgot password functionality into consideration, sometime this ...


0

Don't check against a known list of common passwords as you are decreasing security. If the password has to be short (4 digit PIN) then excluding common PINs can noticeably reduce security. Once you remove repeated digits etc, there are a lot less possible PINs left. If the password is longer, then the chance of clashing with a common password becomes ...


3

When creating a password generator, use a cryptographically secure pseudo-random number generator (CSPRNG) and trust in the random properties of that system. Rather than checking if a randomly generated password contains a substring that humans might recognize as a word, instead check that the entire password has not been part of a data breach. The current ...


0

"Safe" is relative. In general Veracrypt has a good reputation and supports strong crypto. Assuming reasonable use, your weakest link is your stated 8-character password. It may be safe enough depending upon the password and the expected threat, but why limit yourself to an 8-character password? Veracrypt supports "pass phrases" up to 64 characters. You ...


1

8 character is not strong enough to make your Veracrypt volume secure even if it includes symbols. See this answer which is five years, or this article On a supercomputer or botnet, this will take 4 hours. You should use at least 12 even beyond for 16 characters or better and the password must include small and capitals letters, numerals, punctuations, ...


0

The question is exactly where you "draw the line" (to use your own words). I would guess that the example you give is as strong as most 17 character passwords, even though "password" is a substring, but "12345password1234" is perhaps not. It's really hard to implement some rules as there will always be some that think they filter out to much/too little. I ...


1

Diceware(tm) is intended to meet several goal: Security Usability Prescriptivity Security is achieved by random word selection. As others point out, the entropy of any passphrase selected randomly from a list or words is easy to compute: (number of words in passphrase) * log2(number of word in list). Using dice eliminates concern about the quality of ...


2

Having a dictionary password is a norm, not an exception. As for countries other than US, the attacker would simply use password dictionaries for the appropriate locations. Also don’t take term “dictionary attack” too literally: each word is usually passed through some substitutions, so if original word list has the word “Andrew” words like “@ndr3w” or “...


1

Unless I'm mistaken, I understand that both a BIOS password and the BitLocker pre-boot PIN can help to prevent DMA attacks. I'm also guessing that these features are distinct The BIOS password does not have any effect on DMA attacks. The BitLocker pre-boot PIN can assist in mitigating a specific type of DMA attack called "early DMA", which is carried out ...


1

It depends on the strength of your password. Winrar implements proper AES-128 encryption with 262144 iterations of KDF, there's no known bypass for that. You need to estimate the number of possible passwords (what's the length, what characters were used, did it contain words, etc.), and if it is large enough to not be bruteforceble there's nothing you can do,...


-2

Yes, you are right. Just using letters or a combination of letters and numbers is pretty awful for a normal password. Allowing such passwords encourages people to be lazy and use entire words, which is generally a disaster.


2

Yes, that's the goal of password policies. They also seek to expand the required brute-force search space; requiring the presence of numbers and special characters includes those characters in the search space. However, password policies often fail, for a fairly simple reason: The "dictionaries" in question don't need to be English dictionaries, and ...


3

While that is what many password policies attempt to do, moving the user passwords from dictionaries and into a form that can only be brute forced, they're forgetting the most insecure part of the password: The human mind. Human minds are terrible at generating true randomness. They're even worse at memorizing random values. If there's a pattern that they ...


3

If you use multiple password hashing algorithms independent of each other to process the same password, then passwords are protected only as well as the weakest algorithm protects them. PBKDF2 is easier to crack than Argon2. An attacker with only a few bytes of ciphertext can then bruteforce passwords, attacking just PBKDF2 and bypassing Argon2. If you ...


3

To add on to the many good answers here, it's worth noting that even where an attacker is using a brute-force attack (which is rare, given all the better options discussed), good tools don't do a sequential brute-force. For example, the brute-force mode in John the Ripper (which @Tom mentions above) is called Incremental Mode, and although it does cover the ...


4

Thinking out of the box: Correcting for threat model A lot of the existing answers already indicate that there is little to gain by simply avoiding the a, and that it is very easy to apply a 'fix' that actually makes your situation worse. HOWEVER, conceptually it also feels wrong to ignore the attackers way of working completely. Therefore I present this ...


0

This looks like a programmer doesn't understand what makes a password strong. Perhaps thinking: Everyone else requires lowercase, uppercase, at least 2 numbers, and at least 10 characters total. Website admins have trained users to think about password security the wrong way. Between the way websites deny registration based on password rules and the way ...


5

A lot of the other answers are focusing on why a password starting with 'a' would not be less secure than any other starting letter because you're assuming that the attacker is doing it sequentially vs parallel, or because you're assuming they are starting from 'a,' when a skilled attacker might not. Because of these arguments, no starting letter is any less ...


3

If you wanted to do something about it, all you could do (apart from increasing password length) would be to reject passwords beginning with an 'a'. Now you have removed 1/26th of possible passwords, and the attacker can crack the average password 26/25 times quicker. ...and now, the weakest passwords begin with a 'b'. Do we remove these and make 'c' the ...


3

Strictly speaking, yes, if the cracking comes down to brute force, there might be a higher chance that a password starting with "a" will be checked before a password starting with "z". It's not necessarily true, but it may well be. An important thing to understand about password entropy is that you have to calculate it wrt. the model the attacker will ...


4

When you assume a brute-force attack, a password starting in "a" might be weaker. If using "z" gets popular, this would be true for "a" and "z", what would make it more complicated to assess the risk. Lets assume we know a character that is tried before others. Then the attacker only needs to test 1/26 of the search space. The solution is, to make your ...


0

AFAIK Firefox does not encrypt passwords unless you set a master password; instead it uses BASE64 to encode the data. That protects you from seeing the passwords when opening files with an editor, but it's trivial to get the original secrets. Unfortunately Mozilla is not very open regarding the algorithms in use when a master password is set: You'll have to ...


21

After exhausting all other attacks, a cracker would start brute forcing. Says who? There are only two scenarios in which brute-forcing is actually a thing. One is when the attacker has the password hash and the other is when he has control of the software controlling the login because any non-totally-broken software wouldn't allow him to brute-force in ...


81

It would seem that it depends on how exactly the attacker is going to bruteforce your password. However, my opinion is that in the end it doesn't matter. A serious attacker will never start from the beginning in alphanumeric order, from aaaaaaaa to 99999999, unless they know they can do that in a reasonable time. If that's going to take them a thousand ...


27

Entropy Entropy is really the biggest concern, and entropy is determined by the amount of randomness in your password generation process. Let's use an 18 character password as an example. We'll look at alphanumeric characters only (62 possible characters). This gives: log2(62**18) = 107 bits of entropy If you decide to always convert the first 3 ...


0

Although this might not be an answer, for formatting sake I am putting it here. root@PSi:/opt/john-1.8.0/run# ./john crack Loaded 1 password hash (descrypt, traditional crypt(3) [DES 64/64]) Press 'q' or Ctrl-C to abort, almost any other key for status Alfredo3 (?) 1g 0:00:00:00 100% 2/3 8.333g/s 704000p/s 704000c/s 704000C/s Glitter3..Isaiah3 Use ...


-1

As far as I can tell, there should not be any reduction in security to what you're doing as long as this are only applied to the legacy passwords. New passwords and users that have logged in should just use the new hashing system without going through SHA-1 first. Passwords migrated from the legacy system in such a way will be at least as good as the old ...


3

I am not aware of a diagram set but there is veris: veris framework It translates the "Who did what to whom using which attack vector" in a structured JSON Format. It uses a 4 dimensional model for threats to describe any incident. Actors Actions Assets Attributes So the example model from above would be slightly different, you can model every incident ...


2

Here's the thing: If you're not using full-disk encryption, an attacker can boot from a live OS and plant malware in less than ~2 minutes on any account. Even the administrator account! If encryption is not enabled, a strong admin password does nothing. So full-disk encryption should always be used. However, it's good practice in general to always use long ...


-1

Random character sequence is hard to crack, but also hard to remember. Words (or concatenation of words) are easy to remember, but also easy to crack with brute force methods, such as iterating dictionaries of words. An ideal thing is a mapping between intelligible words and (apparent) random sequence of characters. So let us start from a phrase that is ...


2

While there's value in using a "hidden" custom algorithm, there is already a trivial and established way to make custom secure hash algorithms: Pepper* Because the very cheap, very quick, and very safe option of using a Pepper exists, people who instead write a crypto algorithm from scratch to be "more secure" are always novices. So not only is "Dave's ...


1

The problem with multiple fingerprints: The bank application can't store the actual fingerprint nor a mathematical representation of it (like a number or a hash). The only thing that the application receives is something like "true" or "false", meaning "true" if the Touch ID was successful and "false" if it wasn't successful. And for security reasons that is ...


0

Rule of thumb: Do not do home-brew security. Because it often goes wrong. And the person who wrote it can not test it, if someone has some wrong assumption while writing it, he/she still has it when testing. An independent test is surprisingly expensive/time consuming - much more than writing it. You need to include all related changes too. Knowing "there ...


1

I believe most non-programmers feel (consciously or not) that the space character is essentially different from other characters in that it only serves to separate words from each other; being just metadata instead of data. This feeling is strengthend by the fact that there is no sound corresponding to the space character. Most people remember their ...


0

The details have of course changed with time and technology. For many years the final launch code deep inside the ICBM missle sites was "00000000" 20 years Launch Code. The logic was that it was a very difficult assignment for constantly rotating crew in the bunkers and they needed something they could remember. It has been standard policy in the U.S. to ...


4

I learnt a lot more than this question, by reading @Conor Mancone's answer and discussed with @Conor Mancone and @Anders, so I decide to write it down. Correct me if I get wrong again. md5 and sha1 are broken, but not the way I think how it is I was falsely thinking that the hash output of md5 and sha1 can always be easily cracked (get the original input ...


7

TLDR: Insecure crypto isn't even safe if you can't see the encrypted value. The other posts are pretty good about explaining a lot of reasons why you shouldn't write your own crypto, in an environment where the attacker can see the encrypted value, but they miss something really important: you also shouldn't write your own crypto when the attacker can't see ...


4

Known-plaintext / Chosen-plaintext attacks Let's suppose you know a particular user's password, or better still, can sign up and create your own password as many times as you like. And you have read access to the database. Let's further assume that you suspect (or know) that it's a fairly simple homebrew algorithm. At this point you can start brute ...


30

This doesn't answer the question about Dave's protocol specifically, but I wanted to address the more general question, for the Daves around the world who are writing their own hashes. There are a few things, Daves, that you need to realize: You are not a cryptographer. That's not a slight against you; I'm not one, either. But even if you were a ...


10

In the case of a breach of the database and not the source code, Dave might have made things better compared to plain SHA1. But... The source code is likely to be leaked too, as Conor Mancone explains. The homebrew might screw up the hash, making it even less safe than just a plain SHA1. God knows how Daves strange contraption interacts with the internals ...


66

Yes, But.. To make it nice and clear... We're talking about a database-only compromise when an attacker has access to the database but not the application source code. In that case the attacker will get the password hashes but will be unable to crack them and get the original passwords because of Dave's custom algorithm. So in the case of a database-only ...


1

You need to protect against 2 things: theft and trojans/malware. The model you specified is pretty safe from start. It is encrypted by default. You cannot access any data without the password/pin/pattern, if you have either set. If you unlock boot-loader, it will erase everything in the phone, including internal storage. So the anti-theft part is fine. ...


7

The greatest risk is if the site logs login attempts based on the username that a user enters, rather than the account. Your password will then be displayed in cleartext in the logs, which may be leaked at some future time. In most cases, nothing risky will happen. The site already has access to your cleartext password while you're logging on, whether ...


Top 50 recent answers are included