120

The keyfile will have a different header if it is password protected. Here's the top of a key without a passphrase: -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEA3qKD/4PAc6PMb1yCckTduFl5fA1OpURLR5Z+T4xY1JQt3eTM And here's the top of a key which is passphrase-protected: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,...


77

It is not always so easy as described in the other answers. It works only with the old PEM keys. New openssh format of the keys (generated with -o option, more secure, since openssh-6.5) looks the same if you check the headers: $ head rsa_enc -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCYdi7MhY $ head ...


49

Just to play the devil advocate... You are as likely to be compromised as if you were using the same password on both site*. As most people have pointed, you probably don't have to worry. Not so much because a website cannot make the difference between a good or wrong password but rather because most websites that you will visit will likely not log your ...


44

In most password-protected systems it usually is possible, but very unlikely. Behind many password validation mechanisms is the use of salted hash functions. For the sake of simplicity, let's forget about salt for a moment. When a user sets its password, hash(password) is stored in the database When the user logs in presenting password', hash(password') ...


44

The whole point of having a passphrase is to lock out anyone who does not know it. Allowing it to be recovered would defy the principle and allow hackers who get access to your certificate to recover your keys. So no, there is no such thing. What you should do is declare the keys as lost to the issuer so that they revoke your certificate. Then, you have to ...


41

I don't understand why you don't want a password manager that works on both? Your non-tech friends that don't use a password manager yet are too limited by your requirements. You seem to be running in paranoid mode. Your friends want something that is convenient. If you can get them to move to Lastpass, that will be a huge improvement over their current ...


39

Knowing how long a password is doesn't really make much difference to how easy it is to guess or crack it. If the password is something easily guessable or in a dictionary, then the length is irrelevant. If the password is random and you're trying to brute-force (having somehow obtained the hash), then knowing the length makes very little difference, because ...


37

You're probably fine - there is no particular distinction between a wrong password for the right site and a right password for the wrong site. Even if there was, the site which received the wrong password wouldn't know what site it was supposed to be used on. And that is before considering that it would be uncommon to log passwords for failed login attempts....


28

It does not decrease the security. What is actually happening is that your "entropy calculator" is giving you a false measure of entropy. It can only give an approximate estimate, after all. There's actually interesting proofs that show that one can never actually know the amount of entropy in a particular string of text unless you know something about ...


26

While I imagine most sane web developers wouldn't log cleartext versions of failed password attempts, it's still possible. If you want to be on the safe side you can consider it compromised and reset that password; however, I personally wouldn't really consider it an issue unless I felt beyond reasonable doubt that the first site could potentially present a ...


23

$ man ssh-keygen [...] It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 128-bit AES. So this passphrase just encrypts the key locally. An attacker with access to your system will not be able to read the private key, because it's encrypted. (They could install a ...


22

As with any password guessability/strength question, likely the most important factor is "who's the attacker". For online password guessing attacks, by an attacker who doesn't know you, the most important factor is ensuring that your password won't be guessed before the account lockout kicks in. For that as long as your password isn't in the top couple of ...


22

The reason why you need a strong password for an online service is in case their database is compromised, and the attacker gets hold of the password hashes. Then the attacker can indeed make a trillion attempts per second (if the hashing algorithm is weak and the attacker has good hardware) against your hash. A database compromise won’t necessarily also give ...


19

The only case in which I would change this password is if the site it secures is substantially more important to you than the site you typed it into. For an example, there are people in the world who have access to systems that nation-state actors would be interested in. If those people were to type their important password into some other site, they ...


19

Sorry, but you're not the first person to think of this so you can bet that this technique will be automated in some password cracking software. It's always best to assume that the hacker knows your generation scheme when evaluating these sorts of schemes. So how secure is this? Well a quick googling of "number of songs on spotify" threw up the number 30 ...


18

Likely the best option in this kind of scenario is to record the password/passphrase in a physically secure location (e.g. bank vault, safe deposit box). Relying on human memory to record this kind of information for 10+ years is an extremely bad idea. For example the person who knows the passphrase leaves the comapny/gets hit by a bus/forgets it. Writing ...


17

The "RSA key" is actually a set of values stored as an ASN.1 structure in the standardized DER binary format, then encoded in base-64 to get the final PEM file. A very easy way to determine whether a key is encoded or not is simply to check whether the ASN.1 header is present, and this is usually as simple as checking if the "key" begins with the letters ...


16

A common word of the English language has approximately 11 bits of entropy. That means a 256bit passphrase (passtext?) would require 24 words. How could one make up a text of that length which is still easy to memorize? You could write a poem. The art of writing poetry and memorizing poems is not hard to learn. It doesn't even has to rhyme. In fact, not ...


16

From your description, it sounds like the server is currently using the key, which means the server "knows" the pass phrase. If this is correct and you have appropriate access to the server, you should be able to extract it. How you'd do that depends on what the server software is and how it's set up. Just as an example, if you were running Apache, and it ...


15

If you protect your private key with a passphrase, then Apache is unable to use it unless you supply Apache with the passphrase each time it restarts or you reboot. And since keeping that passphrase stored in the filesystem would defeat the point of the passphrase, that means having some sort of method to pass the passphrase to Apache from externally, each ...


13

While the Diceware passphrase generation system is sound, you aren't the first person to express concerns about the default wordlist. The nice thing is that you can create your own wordlist that works with Arnold's system. That gives you flexibility in eliminating offensive words and replacing words deemed too short or obscure. In fact, several ...


13

UIs with this behavior do exist. I've seen several that do not offer any visual feedback. I've also seen a few that do random feedback. Is it a security issue? Well, consider how long passwords tend to be. I think 8-15 characters is a reasonable expectation from users (there are users who will break the bank with longer passwords, but we'll skip them for ...


12

Reasonable Defaults for s2k You can tune multiple parameters. The s2k-mode should generally stay on it's default value, 3: this uses both a salt and repeats salt and passphrase during application of the digest function. Further parameters are the symmetric encryption algorithm (s2k-cipher-algo), the digest algorithm (s2k-digest-algo) and (if mode 3 is used) ...


11

This is a very interesting topic. One that has been answered before on Stack Exchange. Bruce Schneier is an acknowledged and accomplished expert on cryptography. You can find an article on the subject of brute force attacks here: Why not use larger cipher keys? The most interesting passages are reproduced here: Longer key lengths are better, but only up ...


11

Under some circumstances it may be possible to recover the private key with a new password. It would require the issuing CA to have created the certificate with support for private key recovery. This is normally not done, except where the key is used to encrypt information, e.g. when used for email or file encryption. The issuing CA should be able to tell ...


10

I think the easiest way to convince yourself of the security of Diceware is not to get hung up on the dictionary and instead focus on the dice rolls. The idea of Diceware, seen from this angle, is the following: If you have an algorithm that can crack an n-word Diceware passphrase, then the same algorithm can be trivially adapted to guess the results of ...


10

Simple answer, no. SSH keys are simple cryptographic keys, if you want to add a validity period to it, you end up in PKI territory. There is an answer on the Ubuntu Stack Exchange site, asking how to make SSH keys expire automatically, but this is to do with using the ssh-agent tool. Alternatively, you can use a third party app installed on your server to ...


10

First, by mathematical theory - yes (though in practice you can totally disregard this for modern hash functions and numbers achievable by computation in this universe). If the system doesn't store your password in plain-text or via reversible encryption, but instead hashes it (as is best practice) there are an infinity of potential passwords that will ...


10

This might get better responses in crypto.stackexchange.com or math.stackexchange.com, but I think I can give you the gist of it. If we step away from words and take a look at some numbers it might help to illustrate. Take for example a four-digit code for a lock. There are 10 possible digits (0-9) and four spaces where they can be entered, so there are 10 * ...


10

Private keys should be secured, trying to set the password just declares if it is yet password protected. With ssh-keygen on the protected key: ~/.ssh$ ssh-keygen -p -f id_rsa_password_protected Enter old passphrase: And with not protected: ~/.ssh$ ssh-keygen -p -f id_rsa_not_protected Enter new passphrase (empty for no passphrase): So if it is not ...


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