Tag Info

New answers tagged

2

I'd be happy to explain my comments further :-) Unfortunately it's not a simple explanation. For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified? Quantifying this will be hard since guessing at the runtime of an algorithm is tough, especially if the attacker is allowed to make specialized chips ...


0

I know I'm late on this one, but might benefit someone else facing this problem now. You could do the following: - Put a master key in the database - Checkin the actual key in code repo, but encrypted by the master key. This checked in key could be in a password protected file. A few months ago AWS has come up with a new service called KMS (key management ...


5

The ZIP format supports several variants of password-protection of a file. The early password protection system in ZIP is known to be seriously flawed. However, later versions of the format provide far better protection, including support for stock encryption algorithms like AES to which no known attacks exist. The author of the video appears to be using ...


3

The short answer is no. Sure you can make your email very legitimate looking, that isn't the problem. The problem is you are conditioning your users to click on links in emails and email is a 100% insecure medium. Links in emails are an anti-pattern. "Official looking" isn't secure. Almost everything in your email can be replicated by a dedicated ...


2

1) You can digitally sign the email, so it will look more trustworthy (if the mail app supports it and do not show it just as attachment). 2) It is not the best idea to include links in the email. It is better to give them instructions how to do the change and where. Also, the password change tool should be on your company URL that they know and trust it. ...


0

This is bad password policy by most standards, but here is the oldest issue (or excuse) in the book (at least for Canadian banks): Security vs Convenience The banks do not see the lost a important as user convenience. The fact is that they are not losing enough money due to hacking (at least yet) to consider hindering the user experience. ...


2

In bash you can generate all the combinations of the format [a-z][a-z][a-z][a-z][0-9][0-9] like this: echo {a..z}{a..z}{a..z}{a..z}{0..9}{0..9} If you want them one per line then try this: printf "%s\n" {a..z}{a..z}{a..z}{a..z}{0..9}{0..9}


0

After 5 month without answer, only comments, I like to sum up: From a discussion in sci.crypt it seems that scrypt is demonstrably secure. Most people on SO trusts scrypt. I have seen no one claimed to have a problem with the algorithm itself. Regardless there might be issues with the implementation. A straight forward implementation of scrypt is ...


-1

It depends on the parameters of what you like. Say you prefer a password that you can type on your mobile device without switching keyboards. You can compute the entropy of passwords composed of only the characters on your main keyboard. If what you like is more subjective, the question becomes much harder to answer.


0

I believe the randomness would be reduced to lean to the human intuition that makes the password you chose "better". Linguistic, phonetic, logical, and other patterns can be used to seed such an attack dictionary. If a dictionary can be created, then it's not "perfect entropy", so choosing a password will reduce it somewhat.. but given the constraint of 8 ...


1

Your assumption is reasonable. If we repeatedly generate truely random passwords and pick the one we like most then a good assumption is that it is the simplest among the generated list. For simplicity of the argument, let us assume that the passwords are numbers between 1 and N, inclusive, with small numbers being "simpler", that is: the attacker will ...


3

In order for user rejection of specific random word selections to have an meaningful impact on passphrase security those rejections would need to be predictable. Otherwise there's no way for an attacker to eliminate certain words or word pairings and save time in their attempts to guess the passphrase, which is the primary way this practice would benefit ...


5

Your rejection/acceptance of a truly randomly generated password, and how many times you reject until you accept, will not affect the entropy as the entropy is determined in isolation from generation to generation (just like each toss of a coin doesn't affect the entropy of the next toss). All strings have the same entropy, it's only the context of ...


1

I think the most important component to trying to analyze this quantitatively is "a "strength meter" such as zxcvbn gives the entropy as 39.6 (including the full stop). However, nobody knows that I generated the way zxcvbn breaks it down." So with that in mind, the permutations of password generation algorithms need to be included as bits of ...


1

The problem with entropy as a measure of password strength is it really does have to be applied to the input not the output. If I base64 encode the word "password" I get something that looks strong, but really isn't. So measuring entropy bits is really a best case. If you look at purely random generation the per symbol entropy for even relatively small ...


1

Sure Snowden's password "algorithm" is now known and that reduce the potential keyspace to an attackable range. Now Snowden is smart enough to know this and I would presume would not use a password based on the same algorithm or even one similar in the future. There are however two issues to consider. The first is information leakage when sharing derived ...


5

As tylerl noted, entropy isn't really a measure of password strength, but it is the best that we've got: The purpose of password complexity is to stand up against a brute-force attack. The size of the smallest available dictionary that contains your password determines the amount of time required to crack your password. We can guess at what ...


0

While extending the character set used in your password makes it stronger, it also makes it hard to type and doesn't provide 100% garantee against attacks. More importantly, using rare characters exposes you to situations where you know the password but cannot use it. Imagine not being able to use a recovery tool because it is not compatible with your ...


0

I hope I'm understanding the question correctly, but why not hash the passphrase with SHA-256 and store the result in a db. There is no encryption key so you can't reverse it and if somebody gets there hands on the hash and submit it it will be hashed again and rendered invalid.


-1

Yes. It is VERY crucial. A program called Crunch generates wordlists for you. Ranges like 1-17 characters will take up 15610 petabytes! However, if a hacker know your password is exactly 17 characters, it will take a lot less. That is why it is crucial.


3

As with any question of "is X secure" the answer will, to some extent, be "that depends on your exact requirements from a security standpoint, the threats you face, the type of application and the environment that you'll deploy in" However with that caveat out of the way, I'd say that the scheme outlined above sounds relatively reasonable from a security ...


0

Anything that reduces the entropy of your password reduces its strength. It might be that even when you disclose the password length, the remaining possible password's pool is still large enough. Regarding a concrete example, the set of all passwords of length 17 is surely strong enough against almost all attacks. Provided you did not reveal other details ...


0

In shorter passwords, no. But if you have long passwords it will.


2

I disagree with the accepted answer. Let's look at 2 scenarios, one is we have 10'000'000 passwords and want to crack as many as possible, the other is one password and we want to crack it. In both scenarios the difference turns out to be significant. As usual, all information can be abused in an attack, even if it doesn't seem so at first sight. Scenario ...


5

This is usually a combination of luck, technology and hand waving. You may see that your database server was hacked (via unusual activity for instance, gigabytes being transferred to Internet, a fact detected by, say, your network provider). You may then have logs which trace activity on the database (ranging from "someone accessed the DB" to actual ...


4

Yes there is a security issue. You stand the risk of inadvertently leaking the length of the passwords using this approach. An attacker could abuse this to determine the length of a password using a form of timing attack. Since calculating the hash is computationally more expensive than comparing the length of the provided password with the stored length ...


2

In addition to the answers which give a good overview of your question, there is one more thing to take into account: when making your risk assessment you must assume that the attacker knows everything about the methodology you use to build your password. In other words, if your password is composed of four average English words glued together, all ...


2

I think you are missing something -- for the OPM break in, the problem was that they stole a live credential. That is very useful. Having said that, note that no password should be useful. In theory, every worker is issued a smartcard that hosts an e-auth level 4 authentication mechanism in their Personal Identity Verification card. (This is the FIPS 201 ...


19

What's the point of stealing hashed passwords? Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password. For example, assume that under some hash function we get the following hash table: "cat" --> AA "dog" --> AB "elephant" --> AC ... If I steal a ...


7

The login credentials were found in password dumps from other sites. They were credentials where the username was a .gov email address. The concern is that people tend to reuse passwords and the passwords used on these sites are the password for their government login credentials. Either the passwords were stored in plaintext or the hashed passwords were ...


4

Yes, it's possible. The WCE product you reference works by scraping passwords directly out of memory. That method also works in Linux; a rootkit which has unfettered access to memory and can hook system calls can extract passwords from there - consider this example, which can steal username and password pairs Both solutions are limited in that they can ...


-1

With or without bruteforcing, When you logIn in the account in 5x tentatives with false password, the account Will blocked by WAF (Web Application Firewall) Google Security. So if you change your IP or not, is the owner account only can re-activate it.


5

Great question. In bash, when you use "read" to get a password from standard input, the password is of course stored in plain text in memory. However, this is often the case for passwords in general -- something has to be storing them in plain text to use them. If it was encrypted, a way to decrypt it would have to also exist in memory -- thus the ...


-1

Never use the same password for multiple sites. Never. It is as simple as that. IMHO, the best solution would be to use some kind of password manager. Create master password for the password vault and generate all your passwords for all sites randomly. This solution really works and using this system, you can forget about your password worries for good.


1

An attacker will not use a brute force attack, trying every possible password, but try more likely passwords first. A totally random eight letter password may be harder to crack than a simple-to-guess seventeen letter password. As a result, the attacker will not try all short passwords first, but will try passwords of various lengths throughout the attack. ...


0

If the security is based only on a belief/assumption that an attacker will not use technique X, this is a pretty security. It should be assumed that an attacker knows it. This is like in the chess, make the strongest move as if your opponent knows your intentions.


5

Revealing the length of the password does influence. If your password is weak (short password), an attacker may focus on cracking it. If the password is strong (long password), an attacker might explore other vectors of attack. So the knowledge of the length of password allows a hacker to choose a better strategy while saving time.


1

Deliberately disclosing the password length, provided you only use very long passwords will, as Steve Sether points out in his answer, make it less likely that hackers will try to guess it. So, you actually enhance security by deliberately leaking that information about your password.


3

Generally, reuse of passwords across different sites is a bad idea for this reason; you never know whether they are taking measures to secure your password from view of staff or hackers who might grab the database. Of course, once one of these sites is compromised, hackers will try the same password combination for other common accounts like Facebook, ...


11

Revealing your password length reveals something about the strength of your password. So you're in essence giving someone a hint about how hard it might be to guess. So if your password is very long (17 characters in your example) it's largely useless information. If the password is short, (6 characters), it tells an attacker that you might be worth ...


40

Apart from the maths detailed by @Mike, consider also that the password length leaks all over the place: When it is typed, a sneaky bystander can learn it, either by counting the '*' on the screen, or listening to the keystrokes (in the latter case, he can record the sound with his smartphone and play it as his leisure). In a classic "Web browser" ...


114

Well, let's start with math: If we assume that your password consists of lowers, uppers, and numbers, that's 62 characters to choose from (just to keep the math easy, real passwords use symbols too). A password of length 1 has 62 possibilities, a password of length 2 has 62^2 possibilities, ..., a password of length n has 62^n possibilities. So that means ...


0

Bcrypt as stated in the Link is limited to 72 Characters. SHA256 may have an OUTPUT size of only 32 Bytes, It's Message input is ((2^64)-1)\8 or roughly 2305843009213693952 Bytes (assuming a char is 8 bits) To Bcrypt it's receiving a 32 Byte passphrase to encrypt, To SHA256 that could be a 400 Char data stream (IE password). So no, you're not losing ...


4

This sequence: a b a b a b a b H1 E3 B8 W6 Z4 S0 X1 K4 b b b b b b b b S8 E3 O2 W6 G6 S0 C0 K4 a a a a a a a a H1 L3 B8 H5 Z4 D7 X1 Z8 tells that there is a key being used to scramble the input password, much like XOR, except most uses of XOR would output in hex while this output is base36? This sequence A B A B A B A B B0 ...


3

Many of the tips I'm about to suggest require excessive use of the scrambler. They're not dictionary attacks, but they do include a lot of password scrambling for the purpose of collecting data. If your goal is to do this without too many test probes against the function, or you are not able to do it, i don't really have many tips. Integers Integers are ...


0

Like most password generation algorithms, this one relies on security through obscurity. As long as nobody suspects that you use this method, nobody will use a cracking tool which tries passwords based on trivial patterns on a QWERTY keyboard. But as soon as someone suspects that you might be using it, this would change. As soon as someone feels compelled ...


1

Some wordlists such as rockyou have these sequences in them, so it won't be that safe against a dictionary attack; since dictionary attacks often don't just include normal English words anymore. Furthermore some tools (autocrack, keywalker, ...) exist that specifically test for these, and as Chriss Murray pointed out, it lowers your entropy.


0

If they always use the 3rd and 7th character for this, they might save only hases of the password and this excerpt. Essentially, this would split your full-length password abcdefghijklm into two shorter passwords cg and abdefhijklm. Of these, the two character password offers practically no security. Additionally, the remaining password is not only shortened ...


1

When attempting a login and entering the wrong password, I would state that there is no reasonable reason to keep the password entered - the user can't see the characters, and thus can't see any mistake they may have made, nor correct it, so they'd have to start over anyway. Additionally, there is a reasonable reason to not store invalid passwords for any ...


3

When the credentials are wrong, the server sends you back a page containing the filled username and perhaps also the password. That should be done with https, and caching headers asking not to store it, but there's the possibility that the error page that was sent with the provided password in the source is stored somewhere (browser cache, an intermediate ...



Top 50 recent answers are included