-1

Is it safe to have my passwords for my website stored in my database hashed with my own code? The hash code is written in php and here's some examples:

a - ìbnÿ&%A‘T«•t‰ãšÀ

a. - mf‡=ä^ö™b­±kª©

a! - ž’6èŤ7õp¼Y +

123456 - Š-ÃËzUo‚ñQÈÇûÌ8

stackoverflow - ‹°>¨0µ±Ò¡^Ö—œ”

The hased value is always 16 characters. According to me, it can hash up to 10^96 different hashes and would take somewhat forever to crack. Could I possibly use this for my website?

user1768788
  • 1,265
  • 1
  • 10
  • 29
  • 1
    What do you mean by "hashed with my own code"? If you mean you've written your own hashing algorthm: don't do it. Use one of the standard ones. Unless you're an *expert* in the maths of this, chances are it's not nearly as secure as you think it is. – Jon Skeet Jul 04 '13 at 14:06
  • Why not use `sha1()` or `sha512()` – chrislondon Jul 04 '13 at 14:21
  • possible duplicate of http://stackoverflow.com/q/401656/2200766 – chrislondon Jul 04 '13 at 14:28
  • But if it is as secure as you claim, you should be happy to show us the code (or have you decided to patent it) – Mark Baker Jul 04 '13 at 14:37
  • How did you come up with the numbers of "forever"? How long does one hashing pass take? How long does one hashing pass on a really fast, specialized machine take? How long does it take with that specialized machine to iterate over all possible permutations and build a rainbow table? – deceze Jul 04 '13 at 14:53
  • 4
    This question appears to be off-topic because it's impossible to assess the security of a hash by looking at the output of a few sample values. – deceze Jul 04 '13 at 14:59
  • 2
    I quote Bruce Schneier: "Anyone, from beginner to expert, can invent a crypto-system that they themselves can't break."... [Schneier's Law](http://www.schneier.com/blog/archives/2011/04/schneiers_law.html) – ircmaxell Jul 04 '13 at 15:03
  • You are so funny everyone =3, I'm planning to use this as a private thing, meaning noone will actually be able to build a rainbow table unless they somehow grab the php file (except for the examples I showed here). The numbers I used was, in the unicode character set there are about 1,1 million characters so, 1000000^16 = ruffly combinations and I assumed that a potential hacker/cracker would be able to do 4 billion calculations per second? – user1768788 Jul 04 '13 at 15:15
  • While I agree with Jon Skeet wholeheartedly, I would say that @deceze makes a good point. For the sake of improving Stack Overflow it would make sense to actually post the code -- I imagine someone here will be able to demonstrate just *why* you shouldn't write your own crypto, and we'll all learn a thing or two. – Zach Snow Jul 04 '13 at 15:21
  • 2
    So you're relying on security through obscurity - believeing that nobody will be able to break your algorithm because they can't see it: but if we can't see your algorithm, we can't assess whether you should use it for your website or not, only recommend not on the basis that homebrew crypto is rarely secure (you may be the exception but we don't know) and that your unwillingness to share your algorithm is suspicious of insecurity – Mark Baker Jul 04 '13 at 15:24
  • 1
    It doesn't matter how many possible hash-values you can generate, what matters is, how many passwords you can hash per second. With an algorithm like MD5 you can calculate about 8 Giga hashes per second with a common GPU, so to brute-force a whole english dictionary you would need only a fraction of a milli second. – martinstoeckli Jul 04 '13 at 15:50

1 Answers1

1

To sum up what's generally mentioned in the comments:

  • Security through obscurity is not protection. For one, if your hash database leaks, chances are your source code may be accessible as well. If it's not, people can experiment and may be able to reverse engineer the algorithm. If you could think it up, so can anybody else.
  • A hash must have a large enough key space to avoid collisions as much as possible. You've got that covered apparently judging from the size of the alphabet, but how collision resistant your algorithm is we don't know.
  • A hash must be expensive enough to make it infeasible to hash a large number of values quickly. We have no idea about that in your case, but since you didn't explicitly highlight that as a feature, I expect it's fast. That means an attacker will try to hash all possible passwords as fast as he can. Notice that it's irrelevant here how large the alphabet of your hash values is; only the number of values to be hashed times the time it takes to hash one value is relevant.
  • A hash must not have vulnerabilities that allow shortcuts that further reduce the hash time or even allow targeted reverse-engineering of values. We have no idea about this from the information you provide about the hash.

Having said that, if your site is very low profile, it's probably enough to be okay simply by the fact that it's obscure (oops, security by obscurity) and nobody cares. If one day a sufficiently skilled attacker takes an interest in your particular site and hashing algorithm though, you're probably screwed.

deceze
  • 510,633
  • 85
  • 743
  • 889