Tag Info

Hot answers tagged

25

End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched vulnerable systems, you may have to: Change passwords Login again (because all session keys and cookies need to be invalidated) Help senior management evaluate the actual content handled by the vulnerable servers that ...


25

Short answer: Yes, all passwords. Long answer: At first sight, you only need to change the secret key of the certificate. But due to several reasons, all passwords are affected. Here's why: Reason 1: Chained attack Someone captured the secret key of the certificate. From that time on, he could decrypt all the traffic to that site. If you logged on for ...


23

No. You do not have to change all your passwords due to heartbleed. You have to change all your passwords because everybody seems to have become a huge herd of panicking sheep; changing your passwords will give you a warm feeling of doing something useful while you are running to your ultimate destination, which may well be off the nearest cliff. Such is the ...


12

Changing passwords on a site that is/was vulnerable to Heartbleed is only effective after: The site has been patched to a non-vulnerable version of OpenSSL, or switched to use a different SSL implementation. A new SSL certificate has been issued and applied to the site. Old SSL certificates for the site have been revoked. All of the above being beyond ...


9

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database. The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes. You may be ...


9

Actually quantum computers are not that much a threat for symmetric encryption. To put it in simple (and somewhat simplistic) terms: A quantum computer, if it ever exists, will totally break the most used asymmetric encryption and key exchange algorithms (RSA, ElGamal, Diffie-Hellman...) but not all asymmetric algorithms (QC does not break the concept of ...


8

No, I don't think this is true. News coverage gets this wrong all of the time, probably because its not an easy topic for an outsider. It all starts with the term encryption. If you are really encrypting a password, you are most probably doing something wrong. Passwords in the context we are talking about are used for authentication. There is absolutely no ...


6

The attacker is in your head. By this I mean that the attacker knows you and knows your password generation strategies. If you systematically use passwords beginning with a 'Z', then he will start his search with such passwords. (Especially since you have described this very method on a publicly readable Web site.) You might have an edge if you choose your ...


4

Password meters are no good. Well, that's a bit simplistic, so let me say it in more details: a "password meter" application like the one you used is mindless and generic; what it measures is the effort of breaking your password, using the mindless and generic strategy that the password meter author thought of. In particular, that password meter system has ...


4

For n-character passwords without two identical adjacent characters, @Stephen gives the solution: that's 94*93n-1 passwords. Reasoning is simple: you are free to use any of the 94 characters for the first character, then for each subsequent character you may use any of the 94 except the one which you just used, so 93. For n = 16, you may see that you keep ...


4

Don't roll your own crypto. Generally, if you are directly calling (as opposed to specifying the name of) some crypto primitive (SHA-512, AES, etc), then you are violating this rule. If you think crypto implementation bugs are not hard to avoid, I suggest you give Matasano's crypto challenges a try. Fewer lines of your code. This means fewer chances of you ...


4

Ideally, we should do most (but not all !) of the hashing on the client side. The overall need for password hashing, with all the involved iterations and salts (see this answer), is to make sure that the value which is stored (the "password verification token") cannot easily be used for an offline dictionary attack (the attacker tries potential password, ...


4

The password is padded with null bytes: extra bytes of value 0x00 are appended so that the total length is exactly 14 bytes. See this, item 4. Of course, LM hash is a very poor password hashing algorithm. Don't use it (if you have the choice).


4

Yes, you should always change all of your passwords. You never know when someone might have compromised your password. And really without any certainty that it the worst hasn't happened today, the only sensible action is to take any and all measures possible to protect yourself. The same goes for tomorrow.


3

The salt is stored with the hash, for example in a separate database field or it is tagged onto the end of the hash or the username is used as the salt. The purpose is so that even if two users have the same password, their salts will be different and therefor their hashes will not be the same. This is useful if someone manages to steal the database, they ...


3

What is the best method for securing PHP scripts that contain database passwords? One common approach is to put these sort of details into an own file, which is not directly accessible through the webserver, e.g. something like a config directory outside the webserver's document root. You can always include this file whereever it is needed. If for ...


3

Most antivirus will try to protect processes from code injection. However, this is ultimately heuristic: the only clear distinction between malicious code injection, and normal process behaviour, is at the human level: did the human user actually wanted that to happen, or not. Software in general, AV in particular, cannot fathom the intricate psychological ...


3

As @CodesInChaos comments, an encrypted database, if done properly, will be at least as strong against brute-force attacks as a hash value. From that point of view, the hash-based method is not more secure. There are details, though, depending on the attack model: With the local database of passwords, you can use random site-specific passwords. If one site ...


3

I have used a similar method in the past: I had a plain-text file containing my credentials and encrypted this with the Blowfish cipher. Now I use KeePass, an offline password manager. I strongly recommend it, as it is Much more user friendly than an encrypted text file, and Much more secure than a text file encrypted just once (N = 1, see below). KeePass ...


3

Chinese (Mandarin) is a very phonologically restrictive language with a limited amount of possible syllables. Hence, you can make a table consisting of every possible syllable in the Chinese language as exemplified here: a ai au an aŋ e ə əi əu ən əŋ i ia iai iau ian ...


2

Passwords should be hashed at least once on the server, to prevent pass-the-hash style attacks where a malicious attacker can simply inject the hash he sniffed from the network to authenticate. This doesn't however mean that you shouldn't hash the password locally as well. A fairly paranoid strategy is to have the user submit an iterated hash of a password, ...


2

There some things in that linked article that are true and useful. But identifying those parts from the things that are erroneous and misleading is something that can only be done by someone who doesn't need the advice in the first place. As @user1201232 correctly pointed out, there are some (ancient) systems that only use the first eight bytes of a ...


2

This claim is nonsensical. The most common practice by far is to take an MD5 hash (or, increasingly, something else like a SHA hash), with a salt. The salt is a random string added to the plaintext password before it is hashed, and stored with the lot; it serves to make it hard to compute tables of all possible hashed passwords since this must then be done ...


2

I have seen sites that allows long passwords, but only uses the first X characthers, then create a hash with a salt from those X characters... leaving the last Y characters not used, and efectively could be anything. for example your passwor would be mylongandboringpassword with the X set to 8 the actually stored password (and all you would need to ...


2

The user always submits the actual password to the server and the server stores the salt and hash values. The point of a salt is simply to make sure that if the DB is compromised, an attacker can't try brute forcing all the passwords at once. It also prevents identifying reused passwords. It doesn't matter if the salt becomes public knowledge because it ...


2

Measuring entropy of a passphrase is often tricky. For example, if you follow NIST guidelines for measuring entropy of human-generated password (see e.g. http://en.wikipedia.org/wiki/Password_strength#NIST_Special_Publication_800-63) then entropy of your both passwords will be ~33 bits. I would say even at 33 bits this is OK for intended purposes, however, ...


2

If you do not have access to the source code, you will have to make multiple attempts to see if there are any patterns in the token generation. If it is a basic incrementor, this may be easy to defeat. You can take the length of the token into account as well. Here are some OWASP guides on the topic, which may be of use: Testing for weak password change ...


2

I guess the only thing users can do is: Use a different, strong, randomized password for each account (aiming for ~128 bits of password entropy is a good strategy, as explained in this answer); Change the password when a website implements the OpenSSL security patch. Using a password manager makes sense. I find KeePass Password Safe pretty good.


2

Short answer: this is the link you're probably looking for (-s specifies SSID). Longer answer: Precomputed 'hash' files are used to accelerate password bruteforce when cracking WPA. They do this by eliminating the need to perform costly transformation of a password into an encryption key; instead somebody already computed such keys for common SSIDs and ...


2

The answer depends a lot on your use case. Are you using a biometric to authenticate yourself to a remote HTTP server? Then if someone steals a binary representation of your biometric, they will be able to log in as you. This is why we like moving to 2-factor authentication instead of a single factor. An example would be something you are (your fingerprint, ...



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