Tag Info

New answers tagged

5

Cryptographic hash functions must have several properties: Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x. Resistance to second-preimages: given m, it should be infeasible to find m' such that h(m) = h(m'). Resistance to collisions: it should be infeasible to find m and m' such that m ≠ m' and h(m) = h(m'). These ...


2

The OP asks: "which one can be considered better secure (theoretically/practically) than the other, and why? Or they are just the same level?" Both are implementations of out-of-band two-factor authentication. Note however the above example seems to be of some IN-LINE communication. If the secret key is passed along the same channel (e.g., web-site), it is ...


7

I personally prefer Google Authenticator which is basically an elegant implementation of Time-Based One-Time Password Algorithm but I would not feel comfortable saying it “is more secure”. To use one of my favourite buzzwords… it all comes down to Threat Modelling. What exactly are you trying to protect against? Is it a technical attacker who might be able ...


3

The assessment of any strong 256 bit cryptographic hash as having a security level of either 128 or 256 bit depends entirely on how it is used. In an application where an attacker can succeed simply by finding any hash collision, the security level cannot exceed 128 bit since a simple birthday attack will (probabilitiscally) succeed after 2^128 random ...


3

I assume your question is: Can an attacker find pass15 more easily if they know both hasha and hashb than if they know only hashb? If that hash function is truly good it should have a good uniformity. That means that any input given to the function will be mapped to an output irrespective of how similar input is mapped. This means that knowing how ...


0

Now, lets say that salta, saltb, hash(), and hasha are all public. Is hashb any more at risk of being cracked than if hasha was not known? Putting aside for a minute that the password is 15 characters of high entropy (which is good), and that sha256 is a fast hashing algorithm (which is bad)... Giving GashA to the world is disclosing information that ...


3

No. In the context of a hash, "bits of security" is a measure of how many possible outputs a hash function has, and thus, how hard it is to find an input with a given output. It's on a logarithmic scale, so each additional bit doubles the security. You can't compare the security of SHA-256, AES-128, and ECC-256. They're totally different things: SHA-256 ...


1

You're missing a threat model I see two obvious threat, both involving being able to query your database. There surely are others (suggestions welcome): A - An attacker stole your DB (and server salt) and wants to infer the Facebook IDs of all your users B - An attacker knows the Facebook information of a specific user and wants to figure out if they ...


0

Analogy: As a locksmith, I may (with the customers' permission) keep records of what I've done for them, including the details of their keys. But that puts me at risk of having my own shop broken into and the list stolen (or an Evil Employee doing so) -- in which case the crook could make keys for many houses, and I'd be liable for not having protected this ...


1

stackexchange. This question can't be answered by security experts; you need to contact the person who generated the encrypted file and/or learn how to use Kruptos 2. This site isn't for supporting how to use specific applications like Kruptos 2. The extension of .~enc tells little by itself. enc is a common extension for encrypted files, but ~enc ...


0

For hashing functions, no ready analogy finds itself in the sphere of football or automobiles. The best we can do is to spill the actual facts. Dear Boss, In a perfect world, users would be security conscious, and never use the same (or even a similar) password for two or more different sites or services. In that perfect world, a password would have little ...


0

You should NOT be able to determine if any user have the same passwords given the information in your database. It's just a security risk by design. If you really want to do something like that, at the very least please never tell the user the actual reason, just say something like "Your password is not complex enough" coupled with the generic ...


2

As @aviv pointed out, revealing to a user that some other user also has the same password is a problem. If you really intend to maintain such statistics, then you have another inherent problem: the "statistics engine" can only help any attacker, since it outputs a list of passwords that are in use. Even a reduced form which merely says "this password is ...


2

I dont think you want to do that at all... you will be giving hints about other user's passwords. If I get the message that 1 other user is using my password - now I have valuable information. I might even know or guess who that user is if I have some prior knowledge on him


2

I would highly recommend you look at redesigning your solution to be able to use a hash, rather than either work with anything other than a one-way hash. If you absolutely need to work with the cleartext password, it should be encrypted using a a high level library like NaCl (http://nacl.cr.yp.to/). Symmetric vs. public-key encryption will be a function ...


2

A shared password is a poor design for managing access to a private communication channel. For example, you can't kick a user out without closing the channel: you can't cause them to forget the password. You can't prevent a user from sharing the password with other users (voluntarily or involuntarily) — if a user's password is exposed, you can invalidate it, ...


0

Analogy time: Storing plaintext passwords is like leaving your house unlocked. Encrypting the password database is like storing the key under the doormat. Hashing passwords is like using a 3-digit number lock shared by all users. Salting the password hashes gives each user their own number lock. PBKDF gives those number locks more digits. No one should ...


-2

The technical importance of hashing is vastly overstated. The practical reason you need to hash is because everyone else does it; it is considered "best practice". If you have a breach, it is much easier to defend a position where you are doing the same as your peers. Doing something different, even if it's the right thing, is much harder to defend. So I ...


-1

Keep in mind from a security standpoint, hash functions like SHA-X, MD5, and other "fast" hashes are prone to rainbow tables [1]. Although it's difficult to compute 160 bits of entropy, if a hash function can be run in parallel across a very large domain of inputs then a hacker could store this precomputation and with ease be able to reverse any weak ...


0

Your logic isn't sound. "The password doesn't need to be hashed because many people will need the password." The second part of your statement is true and you've decided that that dictates that the first statement should be true. They're actually unrelated. Should the people that need the password get it from your server? Feels like they should get it ...


1

Let's say your database with passwords is leaked or stolen: If passwords are in plain-text, all your password are belong to us. If passwords are hashed, all passwords are still in a shared bank-vault that must be cracked. If passwords are hashed and salted, each password is in its own private bank-vault.


2

It depends on your situation it's good practise to hash your passwords encase your database get compromised or your client's network thus allowing the attacker to gain access to any password he/she managed to gain. Advantages of hashing your password: Attacker will have much more to perform to gain access to private chat groups as he/she will require to ...


25

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it. Then why bother storing the password at all, just let anyone in! ;) If you are storing a secret, it's because this secret identifies a subset of your total users. Not all your potential ...


1

I'm pretty certain that's a classic DES-based crypt() hash. It's the right length (13 characters), the right character set ([A-Za-z0-9/.]), and the absence of a hash indicator at the beginning ($1$, etc.) would point to this style of hash. John the Ripper is capable of attacking it, either via brute force or dictionary attacks, and it's worth noting that ...


1

Assuming that the vendors documentation hasn't turned up anything (which is where I'd start looking), you could use a tool like Hash Identifier to give you an idea of what this might be. Once you've identified the algorithm then it's a question of finding a tool which supports cracking that. Likely candidates are John or hashcat


5

Explain it in terms of lines of defense. Obviously, you're going to be doing everything you can to make sure that your code is secure. But the fact is, your server will not only run code that you wrote, and you have no control over the code written by other people. Even if all of the other code on the machine is open-source, you would need to hire another ...


4

The most fundamental answer, which I haven't seen anyone state directly yet, is that the actions of anyone who would be in a position to discover a password cannot be reliably distinguished from the actions of its rightful owner. If one wants to be able to prove that the rightful owner either performed an action or by his own action exposed the password to ...


36

This thread is a bit short on analogies, so here goes: An unhashed password is like a transparent lock, anyone who gets a proper look at it can design the matching key.


2

Hashes are not meant to be reversed, and so there is no way you use a hash algorithm to protect a password and see the plain-text later. What you can do is use a proper encryption algorithms or public and private keys to encrypt and decrypt the passwords, for example PGP.


0

(This may be a dupe; I have a vague memory of a similar question, but I can't find it now, so either my memory or my search-fu is defective, or it's been deleted.) Salt only works if you can tie the protected value to a public value (i.e. salt for hashing a password is stored with the corresponding userid). The only obvious match to an IPaddress is the ...


-5

What to tell the boss: "Here's the problem. I'm an experienced software developer and I'm telling you that storing unencrypted password is risky on a level of absolute inexcusable stupidity. Even storing unsalted passwords is risky on the level of gross incompetence. And I have just told you this. You can order me to store unencrypted passwords, and I will ...


1

Don't put too much faith in such anonymizing. Indeed, MAC addresses fit on 48 bits, out of which two are used for administrative reasons, leaving only 46 bits (at most) unknown to someone eager to recover the MAC addresses (indeed, the attacker can assume that the MAC address from a physical user machine will be "unicast" and "globally unique", so the two ...


0

The average MD5 checksum expressed as a hexadecimal string (like you're doing) has 20 digits and 12 letters. Stripping the letters means your modified MD5 has approximately 10^20 or 2^66 bits of output. The odds of a collision is the square root of the output space, or about 2^33 -- you need, on average, 8.5 billion MAC addresses to generate a collision. ...


3

Imagine you're Scrooge McDuck. You've been keeping your piles of money in one giant vault for a while now, but there's a problem with that: if a thief ever gains access to the vault, all your money will be lost in one go! That's no good. So, clever duck that you are, you decide to split your money up into lots of smaller piles and put each one in its own ...


4

Explain that passwords get stolen all the time, and when it happens the companies are REALLY embarrassed and open to lawsuits if the passwords are in clear text. Explain that hashing is really easy to do today. Now for the analogy: The best analogy of a one-way hash function to non-techies is just to just use a number look-up analogy - forget the complex ...


7

Imagine you're the bouncer at a club. To know whether to let people in, you have a codebook of people's names/aliases (some people prefer to be discreet, and are only known by an alias) and their own private passwords; you can't recognize that people are or aren't who they say they are by their voice or appearance (there are too many people, and due to the ...


12

Using analogies can be powerful, but in this case, I think it would be much easier to just explain in simple language what is going on. Something like this should be effective, but probably should include powerpoint slides with illustrations and large corporate fonts. As you know, we require people to use passwords so that we know who they are when they are ...


0

This depends on the strength of your password. Using Anti-weakpasswords data above, a password of 15 random characters has 62^15 = 768909704948766668552634368 possible passwords. At 40 billion tries per second, this is 768909704948766668552634368 / 40000000000 = 19222742623719166 seconds = 609549169 years = 6E8 years. This is basically unbreakable using ...


182

The Short Answer The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper. But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more. Why you need to do ...


8

All explanations so far are a bit long, here is a short one: Some people who can't remember their bank pin, keep a note in their wallet. If a thief or aquaintence would get to look inside the wallet they'd have a problem, UNLESS the pin is written in a way that they can't read it. Hashing is basically writing text in a way that nobody else can read it.


14

I like analogy as a way to explain technology, however in this case it's probably not workable as the analogy would be too complex. Most managers are more motivated to avoid personal risk to their position than doing the right thing, so rather than an analogy I'd use examples where storing passwords in plain text has reflected badly on a company. I'd just ...


4

How to explain. Humans are humans, it doesn't matter how modernized they are; there passwords will be something like Birth date or Name of the Girlfriend/Boyfriend/Pet animals etc etc. So, it is a threat to save password in clear text. Anyone can read it. Hashing helps to make them unreadable to humans (including loyal system administrator). Once a ...


30

To start off, I'll provide one to start with: Imagine you manage a bank. You don't want to allow your customers direct access to the money. So you have a teller who has just a computer and a small amount of money to deal with everyday withdrawals and deposits. He cannot access everything, nor can he pass secrets to the customer, because he doesn't have ...


0

If you're going to do it, then add some kind of obfuscation. I just guaranteed myself downvotes, but obfuscation is not without value like some will insist. If you assume the system is known, then there is no value. But if the system isn't known, there is absolutely value. An IV used to 'pepper', as Xander put it, would be a form of obfuscation, while not ...


17

I cannot comment on how Stripe does this but I can tell you exactly how Braintree does it (because that is where I work). If I had to guess, Stripe probably uses a similar method. In the Braintree API, we offer a unique number identifier for a credit card. This identifier is a random opaque token that will always be the same for card number stored in our ...


3

tl;dr: It is not possible to do such a thing in a truly secure manner, but it can be done in a "probably good enough" way for being usable and acceptable. Your options are basically some form of encrypted storage (with the risk of encryption keys being stolen, as they need to be present for decryption), or something involving hashing, with the well-known ...


1

When an application store your password it do so on your personal computer. This means that unless an attacker has physical access to your computer or unless your computer is compromised by a virus, your password is safe residing on your local machine. Browser are also programs that can store your password. Let's take chrome for example. If you go in the ...


1

As far as I know, Empathy is using the system's password storage capabilities (GNOME Keyring, KWallet etc.) to store the passwords for your accounts, so you may have to look into specifically how these tools operate. Which of them is actually used depends on what operating system and desktop environment you're running on.


7

The answer will disappoint you: if a service/oracle/hash can tell you if an input number is on file, it can be broken by a very small amount of brute force. Consider that in much of the country, credit cards are issued by relatively few banks in their geographical region. You can learn the BIN numbers for the most popular of these banks quite easily. Let's ...


26

Ok, so if this is a business requirement that you must meet (check to see if a card already exists in the system) this is how I would do it. First, PCI-DSS does allow for a PAN (the primary account number, or credit card number) to be stored in hashed form using "strong cryptography" and they recommend (but do not require) that a salt be used as well. ...



Top 50 recent answers are included