Tag Info

New answers tagged

0

I think your real question is at the end there, "How long is it going to take to break my encryption?" And that tool that you are asking about is mathematics. For symmetric-key ciphers, you can calculate the number of possible keys by using 2^x where x is the number of bits in your key. In AES-256 for example, the key is 256 bits long, which gives us 2^256 ...


2

Existence of a tool that can guarantee security of some encryption system would entail proving a number of hard scientific problems, up to and including the famous P vs NP. Right now, no cryptographer has succeeded in proving that secure encryption or hashing can actually exist, let alone designed a tool that could test a given system. All we have are ...


0

A salt is just a random string of characters added in front and/or behind a person's password before running it through the hash function. Say Sally creates an account on your website. Part of the account creation process is for her to choose a password. Say the password she chooses is "superman". Naturally, we're assuming your website follows security ...


0

This is similar in functionality to using an algorithm to generate password information. Since you provided an example site: http://hash.tknetwork.de/, we can describe how you might generate a new password when you are required to change it. You can add an integer, date, or other value to the 'parameter' to iterate it You can have multiple master keys ...


3

This basically looks like something along the lines of PBKDF2 or sha512crypt, only with a bunch of "cryptographic voodoo" applied. Salts have a very specific cryptographic purpose: to tie an password-guessing attempt to a single password instance. Having company-specific salts, user-specific salts, per-iteration salts, and (to steal a snark) hand-harvested, ...


0

Just to be clear, there is something else called password hashing that is completely different to what you describe, so that is a terminology collision, which is unfortunate. To handle "exceptions", you must have some storage. One method could be to store (e.g. in a local file) a map from server name to some string, e.g. an integer. The scheme would be: ...


1

The browser checks both fingerprints. The idea behind that is if it is possible to create a fake certificate with the same MD5 or SHA-1 hash, there is a much lower (almost zero) probability the same certificate second hash also matches. This could be called: Dual Hash Fingerprinting. Both MD5 and SHA-1 are considered vulnerable in theory (MD5 also in ...


2

If you picked one of the three weak passwords "love", "dog" and "cow", and a password database was lost: Without salts, I can try these three passwords and find immediately everybody in the whole database using these three weak password. With salting, I have to try love+your salt, dog+your salt, cow+your salt to crack your password if it was ridiculously ...


31

You have to consider two attack vectors: Online attack Offline attack Limiting login guessing helps against Online attacks. Let's say it's three times, this means that an attacker can test ALL accounts for the three most common passwords that fit your password policy (how about "password", "12345678" and "12345"?). Salting helps against Offline attacks ...


1

In theory: If the attacker has not built a rainbow table, if a password of some strength can be hacked in 1 unit of time, then N passwords of that strength can be hacked in O(1) time without salt and O(N) time with salt. That's what salt does. No advantage on a fixed password; shows advantage over multiple passwords. If the attacker has a rainbow table, ...


1

Generally, the most important thing is password length. But it is true that an easy password could be broken down easier than a random one. For example, when you are trying to guess a hash using rainbow tables. If it is a normally used word like "cat" it is more likely that you can have it in this table than "07OFmy3HOY3l9e1gCNww7nNpd5lQ8I9an" ;D


5

Salting/hashing is great if your database gets stolen, but it has nothing to do with dictionary attacks that might take place through the normal login procedure. As you mentioned limiting the number login attempts and using CAPTCHA can make dictionary attacks that take place through the normal login procedure ineffective, but salting (or not) won't have ...


73

Salted hashes are designed to protect against attackers being able to attack multiple hashes simultaneously or build rainbow tables of pre-calculated hash values. That is all. They do nothing to improve the underlying strength of the password itself, weak or strong. This also means that they're not designed to defend against online attacks, so they ...


3

No, one point of salted hashing is to get good randomness in the hash regardless of the starting material. However, this does not free us to use bad passwords. Good hashing only protects against one attack vector: that where the intruder steals the file with the hashes. So many other attack vectors on passwords exist... shoulder surfing, brute forcing, ...


0

No, generally not. Iterating hashes does increase the collision risk, since iterating from H(000...128...000) to H(111...128...111) - assuming H does have 128 bit output, is not guranteed to output 000...128...000 to 111...128...111. Instead, by using such thing, you actually decrease the collision resistance. Iterating hash functions should only be done as ...


4

HTTPS is more than security enough to send and receive information, don't start implementing your own security as HTTPS will take care of it for you. It provides: Confidentiality Integrity Authenticity The biggest caveat when writing mobile applications is to verify the the behavior of your application when it receives a certificate exception. With ...


5

My answer is going to differ than everyone else. Tom Leek, and Xander provided good insight, so here goes my response to your initial question, expanding from this comment of yours: "I don't want to store the salt in a database that could be compromised - that defeats the purpose of salting, doesn't it?" Yes, and no. If someone compromised your ...


2

No, don't do that. First: salts are not secret. They are used to make sure that reversing the hash for one password does not reveals all the copies of that password on your database. It is used to make reversing the hash more difficult. Second: it will increase latency. Your authentication system will have to get the username and the password from the ...


28

It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password). If you think of your salt as something that may be shared between ...


4

It would add complexity without adding much value. It does not defeat the purpose of salting, as you feat, because a salt is not intended to be secret, just unique. The goal is not to make it impossible to figure out the password from the hash, but to make it impossible to pre-compute hashes that can then be directly compared with yours to see if any ...


3

It's not necessary. Think about it this way... If your server has access to the salts and an attacker gets root on your server, he would get access to your "remotely stored salts" wherever they were located as well. Since you're using PHP, check out the password_hash and password_verify functions.


0

I can't comment yet, so I will post an answer. I can think of two things that they could do: Run a list of bad passwords through their hashes and see how many correspond to their database of password hashes, then count and rank them. Reverse engineer a sample set of their password hashes(why devote too much time to this?) and aggregate data on the brute ...


2

Your first link says what the source is: This list is from files containing stolen passwords posted online during the previous year. In a perfect world this would not happen. Not only would everyone salt and hash their passwords with an expensive algorithm, security would also be good enough that password lists won't get stolen. Unfortunately the world ...


1

While "reputable" websites may do this, there are just as many that do not securely store them and get compromised. Compromised password databases are available, and if you acquire them, you can construct such a list as the one that SplashData has constructed.


2

This is not a hash. You always have a base64 encoded data (the one that ends with '==') and the hex value of the decoded data. I am not sure what type of data this is, but I am almost sure that it is binary data. AAAAAATOM2KIII+kbR/Dqw3TLTw4PHsGPZft2c+b93rImFIuAQ== 0000000004CE336288208FA46D1FC3AB0DD32D3C383C7B063D97EDD9CF9BF77AC898522E01 ...


1

Truncating a well designed cryptographic hash digest should not result any security weaknesses other than a reduction in the collision space. As these hash algorithms have a key design requirement of being uniformly distributed across the hash space. All other things equal, using a more modern hash algorithm (SHA) and truncating it is safer than using an ...


0

Should he use one secret string as salt No. One hard-coded side wide salt does prevent pre-calculated rainbow table attacks, but those are not really a major concern nowadays. The main advantage of using a random salt for each hashed password is that an attacker when bruteforcing has to hash each password with each salt, instead of just hashing once ...


1

"Pass the Hash" is a combined weakness of windows and NTLM, which can be exploited in a corporate environment if one administrator account with the same password is used for multiple computers, to gain access to all of those computers. From the Wikipedia NTLM article: The NTLM protocol uses one or both of two hashed password values, both of which are ...


2

I'm slightly confused by the construction of your question, but should still be able to shed some light on the subject in any case. First, I'm going to assume that when you say P+B you intended to mean that P and B are going to be concatenated, rather than that addition in some form is being preformed, and I'll denoted this below with the || notation ...


3

Extra information can only help the attacker; but that extra help might be negligible. If we model the hash function as a random oracle, then showing h(P+B) for a given non-empty string B does not yield extra information useful for the attacker (I take "+" to mean here string concatenation, not numerical addition). A "random oracle" is (in rough terms) a ...


3

The primary characteristic of a salt is that it should be globally unique for each user's password hash. It need not be secret, and a username will certainly not meet the required criteria of uniqueness. A shared secret string (used for all users) is not a salt, but a pepper, and has not been demonstrated to add any security over unsalted passwords, and so ...


5

Even if he was using a salt, it would still be a terrible plan. SHA-512 is a fast hash, so you don't need rainbow tables in order to find passwords, simply testing inputs along with the salt can be done at the rate of hundreds of millions to billions of candidate passwords tested per second. What your friend should do, is read the answers to How to ...


0

He may be technically correct, but it is still bad design. His approach will mean that duplicate passwords will generate the same hash, which can reduce an attacker's cost (if he finds out a plain text password from one user and is also able to get the password hashes, he can see which accounts use the same password). His approach is also dependent on ...


7

How about you take his challenge? Go make a quick rainbow table of common passwords and run it over his database. You're bound to hit something (especially if he doesn't have a password policy). However, this may not work if he has a small database.


1

Collision resistance is about the infeasibility of finding two distinct inputs m and m' such that h(m) = h(m'). The attacker gets to choose m and m' arbitrarily, as long as he ends up with two distinct messages that hash to the same value. Second-preimage resistance is very similar except that the attacker does not get to choose m. Instead, we give him m, ...


0

Second pre-image resistance simply has more constraints than collision resistance. In your examples, x1 and x2 are the inputs, and h(x1) and h(x2) are the outputs. For second pre-image resistance, you are given x1, and must find an input (x2) that hashes to the same output value. You do not get to choose x1 in this attack. There is no such ...


1

We are talking about the database of a bank, and that's not your average database. It's a special kind of database, when every step is audited, every alteration is logged. So a database leak is very, very unlikely. If someone can get access to the bank database, why bother with PIN or password for any user? They can go direct to the money. The reason to ...


0

You can basically turn any block cipher into a hash function using Merkle-Damgard-construction and you can basically turn any hash function into a block cipher using Feistel-networks if you define the Feistel function F in the following way. F(half_block, round_key) = hash(concatenate(half_block, round_key)) But it's quite inefficient (takes long to ...


-1

One example of using AES in a hashing application is CMAC-AES, a Cipher-Based MAC, a message authentication code or hash, that relies on the AES-128 cipher. It is standardized by NIST in Special Publication 800-38B. It is considered a mode of AES (or TDEA for which it is also approved). The decryption function is not used and cannot be used to restore the ...


3

Currently windows uses NTLMv2 to store the password, but for backward compatibility some system uses LM hashes. Now it is recommended by the Microsoft to not to use LM method to store the password because of its weakness towards brute force attacks. If you want to see currently which method is used then you have to navigate to ...


3

No. MD5 and SHA1 are largely unrelated. Knowledge about one does not confer any knowledge about the other.


5

If someone were to get a hold of this database and try cracking the passwords, would allowing these additional combinations significantly reduce password strength? I would argue that it would not in this specific situation. I highly doubt that they are storing three forms of the hashed password in the database, but rather hashing three different ...


0

The simple answer is not really. The easiest way to achieve this would be to use a .ToLower() before salting and hashing, and the same when password checking. However it is worth spending some time thinking about why you would bother. It isn't the browser doing the capitalisation after all, it is the user. It is no different from using @ instead of A or 3 ...


2

The answer to this question depends on two factors: the attack vector the implementation of allowing different passwords Websites should store passwords not in plain-text or any other form allowing to get the password from the saved value. Therefore usually a irreversible hash-function is used, so that only the hashes of the passwords are compared. Now ...


0

Maybe they are using an HSM for password storage. Password are (maybe) encrypted and stored in a specific unit in the server farm so they can actually decrypt them and "read" the plaintext. The difference is that with hash+salt you can't decrypt a password (hashing functions are one way functions). With an encryption algorithm you can actually decrypt the ...


5

Well, we will probably never be completely sure as we don't have the code. But we can discuss some possibilities. But first, Why the change, actually? What could be a reason for this change anyway? A possibility is that intelligence agencies had something to do with this, like is assumed to have happened with an older version of A5/1, Comp128v2, where the ...



Top 50 recent answers are included