Tag Info

Hot answers tagged

43

This recommendation makes no sense: The JavaScript code used to hash or encrypt the password has to be transferred to the client too. If the attacker is able to mount a man-in-the-middle attack he will be able to inspect the JavaScript code used for encryption too or might even replace it with something else (like no encryption). Hashing instead of ...


37

As for anything attached to public networks: Reduce your attack surface - can you remove the NAS from the Internet? Can you limit the IPs that are allowed to connect? Increase cost of attack - lockouts are great, but also make sure that you have a complex password and that you change it regularly Monitor access - keep your eye on who successfully logs in ...


33

For starters you rolled your own piece of password hashing algorithm. There are currently but three password hashing algorithms which are considered secure: PBKDF2 scrypt bcrypt You are iterating and you are appending a salt. You also seem to add the username within the algorithm, which does not add any benefit as you are already using a salt. What I ...


25

There are two main arguments for enforcing requirements/restrictions on username choices. The first is that making usernames more difficult for attackers to predict helps resist online guessing attacks. While usernames aren't necessarily considered to be as secret as passwords they are one of at least two pieces of information that must be stolen to ...


18

Is the random salt saved somewhere to be used for each encryption? Yes Seems less secure to me if the salt is saved right alongside the hashed password, rather than using some kind of computed salt an attacker would not inherently know if they got a hold of your data. It's not, because the only thing a salt does and was invented to do is, as you ...


18

Assuming that some-salt is in fact never repeated, this is an acceptable password hashing method. It combines the three essential elements: no recovery of the hash from the passwords (thanks to the use of SHA-512), intrinsic slowness (due to the high number of SHA-512 iterations), and a unique salt. The salt needs to be globally unique: it must not be used ...


16

Your algorithm is better by miles than many "homebrew" ones. The reason why I'd still switch to a standardised one is you get the benefit of all the scrutiny that these standards have received which your own construction has not. Is there definitely no mistake in your construction that allows a trivial break? If not, are you sure your algorithm isn't ...


15

As always, you have to consider the value of the asset you're attempting to protect in order to properly assess if a security procedure is adequate or not. Typically, you'll be willing to accept lower usability when the value of your asset is high. This means that it's impossible for anyone than yourself to estimate whether a given solution is secure ...


10

To verify the hashed password without salt, you compute MD5(privided_password) and compares with the data stored on the database. It makes a trivial search on a hash table to decode lots of your passwords. If you use salt, you must compute MD5(provided_password + salt) and compare with the database. As the salt is part of the hash, you store the salt on the ...


9

These user names requirement can cause user names to be less predictable. I don't think that this provides a substantial security improvement, but I can think of a couple of scenarios where they help a little. I doubt that it offsets the loss of usability, but I lack concrete evidence to conclude. As usual, security at the expense of usability, comes at the ...


8

I don't see the security of a single use password reset link like you describe it. Most single use links are only invalid if the password is changed, not if the page is loaded for the first time. An accidental press on reload or F5 will make the request invalid? This is some kind of a very bad user experience. So let's think about this: A user orders a ...


8

I would suggest implementing HTTP Strict Transport Security instead, which prevents the user from accepting the spoofed certificate in the first place.


8

One drawback to including the username as part of the salt is it means you cannot rename a user (e.g. administratively) without generating a new password hash (which means you'd have to pick a new password and tell the user, or ask the user for their current password).


7

I generally dislike security questions in general; they usually ask for information that is more or less public. Mother's maiden name? Ancestry.com will tell you that. Your high school? Facebook, LinkedIn, any of a number of social media sites that use the info to suggest potential friends will not only have it, they'll advertise it if you aren't careful ...


6

SHA-256 is a hash function. That means it cannot be decrypted. If the original data that was hashed is relatively small (and not salted), you could try rainbowtables. Also see "Difference between hashing a password and encrypting it"


6

Probably the most comprehensive database of searchable compromised accounts is haveibeenpwned.com. If you've reused the password in multiple places then yes you should assume that password has been compromised. I also recommend enabling two-factor authentication wherever possible as this will reduce the risk of one account being compromised leading to other ...


6

From what you describe it is possible that you have been targeted from bots which are searching IP with specific ports and trying to brutal force them with default passwords of all kind of FTPs, NAS:s or just from a specific wordlist. My advice to you: close the NAS port in your router for now.There are several methods to avoid those attacks. A method is to ...


6

The security of your randomly generated 15 characters password depends very much on how it is stored on the system that is being breached. If the system stored it in clear text, your password would be stolen in 0s. Assuming the next worse case scenario of your password being stored as an MD5 character that is being hashed just once, without salt, if there ...


4

The term you're looking for is "hash rate", and a quick Google search indicates that a GPU-based password cracker can try on the order of 10^10 passwords per second when cracking MD5 hashes. Generating hashes is an example of an "embarrassingly parallel" process, so doubling the available computing resources will double your hash rate.


4

lowercase + numbers Incremental actually has a predefined mode for lowercase + numbers: [Incremental:LowerNum] File = $JOHN/lowernum.chr MinLen = 1 MaxLen = 13 CharCount = 36 From the documentation: "LowerNum" (lowercase letters plus digits, for 36 total) Just adjust MinLen and MaxLen. Create new incremental mode with certain characters If you ...


4

To make user IDs less predictable. To conform to other systems. The reasons for less predictable user IDs might be: An application limits a number of password guesses (a typical thing for internet banking) per a user ID. Then an attacker can mount an attack "try password 123456 for all known user IDs". If the attacker does not know the large amount of ...


4

The risk posed by a weak user password is generally rather low, unless you're being attacked by someone really determined to get in to your wife's system (perhaps to gain access to other computers on the network?). This is for two primary reasons: It's easy to defend against the password's use over a network: While I don't generally work with Macs, it is my ...


4

I agree with the other answers that the "security questions" really don't do much good. The theory behind them is that only you will know the answers to those questions, and they will be used to let you back in to your account should you have forgotten your password. Unfortunately, the answers to most security questions can be found online if the attacker ...


4

I don't think this is a great idea, especially as an alternative to a password (rather than in addition to a password): A 4 digit pin by itself could be brute forced in ~100 days even if you had a 15 minute lockout for incorrect password attempts. Entering 4 digits via your mouse on a screen is probably slower for most people than entering their password ...


3

If you want ignore that the attacker could easily replace the Javascript code during a active MITM attack: You could generate some asymmetric encryption key, provide the client with that public key to use it to encrypt the password client side. If you use a new key for every login nobody should be able to replay the password.


3

If you are looking for something you can do by hand, you can use a Vigenère cipher and memorize a fairly short key. This won't stop anyone who understands cryptography, but it should stop nosy family members. http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher You don't even have to do the enciphering by hand: http://sharkysoft.com/vigenere/ (Do inspect ...


3

I agree that forcing a weird username will make breaking the account sligthly harder (as it works as a kind of second password) as opposed to having the same username as in the XYZ account whose password they are reusing. (But imposing some requirements also makes easier that the user forgets his own username!) The main reason I see for setting a minimum ...


3

It is all a matter of trust and/or accountability. If your internal environment is completely secure/separated from the internet you can, but it is not generally a good idea. Example: What happens if an employee is let go? Can you trust that person then? If attached to the internet that is very bad and I have seen it happen in companies I have worked for ...


3

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption. bcrypt(cost, salt, input) state ...


3

Bcrypt is not reversible. You can use it client-side as well as server-side. The key is not static but rather dependent on the password, generated by the function call EksBlowfishSetup(cost, salt, input). The plaintext is known and public, its "OrpheanBeholderScryDoubt". If you wanted to retrieve the key, you would need to mount a known-plaintext attack on ...



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