Tag Info

The mistake here would be to believe that extra password rules increase security. They do not. They increase user annoyance; and they make users choose passwords that are harder to memorize. For some weird psychological reason, most people believe that a password with non-letter symbols is "more secure" in some ontological way than a password with only ...

There is added noise to the channel if you send them separately, assuming there is a delay in sending the second email the attacker would have to listen for a longer period of time and filter more content. It is simply a little bit safer than sending everything in the same package, think of ordering a safe box and shipping the keys along with it, its ...

The question was clarified in the comments to my other answer (which I'm leaving since it may still be helpful). It's really just asking about whether or not to allow leetspeak. Two factor authentication is already in use for high security areas.
An index of entropy values:
EQUIV MD5 ...

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time ...

It certainly doesn't hurt your security to send two separate emails, but I agree that it's not a silver bullet.
The better practice is to send the password "out of band", meaning that you send the file and the password by different communication channels; one on the internet, and one not. If you send the file by email, send the password by SMS, if the file ...

From your initial understandings:
A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate.
As ...

Additional password rules should always be tempered with the following rule:
"The more difficult it is to get a valid password and keep it current,
the more likely people will write write them down in their day
planners."
Accordingly, your question is a social one. How much education regarding good password management can you provide versus how ...

One problem with this kind of solution where a predictable algorithm is used to generate a secret from a master password/phrase, is that if your master password is compromised directly (e.g. keylogger) or indirectly (e.g. an attacker with a password of yours generated through this system who can carry out a brute-force attack on it), the attacker has ...

At some point the user needs to be authenticated. The approach that you are detailing will shift this process to the authentication of the email account. Technically it could shift it elsewhere too, but at some point there will need to be a form of authentication.
The problem with delegating the process to a third party is that you place too much trust in ...

The most common format for hashes on Unix-like systems has the form $ALG$SALT$OUTPUT where ALG is a small number identifying the algorithm, SALT is a salt for the hash and OUTPUT is the output of the hash function. SALT and OUTPUT are encoded in base64.
Algorithm 1 is “MD5 crypt”, a construct based on iterating the MD5 hash function. This algorithm was not ...

Assuming the router follows the glibc standard for password hashes, the second field ($1$$N76hdwGfg11g0KdKbtyh21) is the password, and is encoded as follows:
$1$: iterated MD5 hash
$: No salt
N76hdwGfg11g0KdKbtyh21: the hashed password, in base64 encoding. In hex encoding, it would be 37bea177019f835d60d0a74a6edca1db

In my experience, most people who recommend this have previously worked in similar situations with snail mail, such as sending out the ATM card and the PIN separately.
It makes sense with snail mail, as in most cases it's not usually practical for a compromised node to intercept all traffic, and correlate cards to PINs. Or if it is practical, it's generally ...

If you aren't afraid of anyone stealing and brute forcing your passwords, then your most likely case of a password being discovered is a phishing attack. Password complexity requirements won't protect you from phishing attacks.
If you use very complex passwords, users will find a password that works and stick with it, when it expires, they will make the ...

The attack against HBGary is a famous example of an attack made easier by password reuse:
Neither Aaron nor Ted followed best practices. Instead, they used the same password in a whole bunch of different places, including e-mail, Twitter accounts, and LinkedIn. For both men, the passwords allowed retrieval of e-mail. However, that was not all they ...

Secure Communication
The communication protocol must be secure. If the communication channel is insecure then the authentication is insecure. TLS/SSL is one way to secure the communication protocol. If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link. If done properly ...

In short, this method provides no additional security over a regular password manager, and makes it impossible to change your password for a single, specific service.
For instance, you mentioned the example of malware using a keylogger to get your master password and then compromising all the passwords in your password file. Your proposed scheme provides no ...

Simple version : Salts don't stop brute force attacks against a single user's password. What they stop is is you being able to do a brute force attack against all of the users' passwords at the same time.

For password-based encryption, you need to:
transform the password into a key suitable for the encryption algorithm (a process called key derivation);
use that key to encrypt the file.
Assuming that everything about the encryption phase was done properly, and the used algorithm is not weak, then the most direct attack route is the password: the attacker ...

It is more secure than a password in some ways, but as you describe, it also makes accounts more vulnerable to other attack vectors.
As a best practice, properly implemented two-factor authentication offers much superior security to a single factor, regardless if that single factor is a memorized password or an "on demand" password.
Reduced Vulnerability ...

Rfc2898DeriveBytes implements the standard algorithm known as PBKDF2 and defined in RFC 2898 (hence the name). That algorithm uses a configurable underlying pseudorandom function, which is usually HMAC, and HMAC itself relies on a configurable underlying hash function, usually SHA-1. While all of this is configurable, a given implementation might not be as ...

It depends on who manages the OpenVPN server.
A VPN allows you to connect your computer to a remote network in a secure way: the traffic between your computer and that network is encrypted. This protects you from the intermediate networks (including the local one, on which you plugged in your computer) from seeing your traffic (they see a stream of ...

The first rule of 10 Immutable Laws of Security Administration written by Scott Culp, is a good law regarding your situation:
Law #1: Nobody believes anything bad can happen to them, until it does.
Even though your server is only accessible from within your local network, try to think of how many computers or servers are connected to that internal ...

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 ...

I'd say 8 is too low, even 9 is a order of magnitude more secure (literally) for something like this. You certainly want to consider 2-factor authentication given what this content is.
Also, consider how people approach mandated things like capital letters (almost always the first character) and numbers (almost always the last character). These actually ...

Because that's only a single factor. Sure, it can certainly work, but it also has weaknesses.
First, if someone acquires access to the user's email, then they have automatic access to the site. This is not seen as a big deal for some people (if my email is compromised, then everything else isn't as important), but it is still an inherent weakness.
...

I would store the password only in memory at runtime, but this has one drawback. You need to type in the password every time you start/restart the server. This is the most secure way to managed plaintext passwords.
Plus I would followed the advice to r00t, create two users on the MySQL server, one with read permission and one with write permission. Just in ...

What you're thinking of has been done quite a few times already.
Here's an example: http://plevyak.com/dpg.html
It's called a Deterministic Password Generator, meaning it creates passwords based on other information that you enter. Just like you said, using your master password, some other information, and the name of the site.

I understand this as security by obscurity, which doesn't really "work" and is certainly not considered best practice. The information will be in two separate places however, making it harder for an attacker to collate the information.
I would avoid sending the password in a separate E-mail. Especially not in plain-text. Use another communication method ...

What you are proposing is certainly better than putting a userid and a password in the same email, but it is still not a great solution. Consider some other options:
Services like LastPass offer secure messaging.
You can transmit passwords using text message or other non-email methods.
Services like privnote.com allow you to send a one-time link, which ...

A traditional delay would mitigate web browser based attacks, for example if someone uses phantomjs to automate login attempts the normal delay (in your case "more than one second") would be enough to stop anyone from trying to brute force a password, it just takes too long.
However, most brute force attacks are not ran in web browsers but in scripted ...