0

I just came up with this idea that I can store passwords as integers which take up 4 or 8 bytes as opposed to a hash that takes like 150 bytes or something. I wrote this function that converts a string to an integer based on some elementary math

function pass($pass) {
    $value = 0;

    for ($i = 0, $l = strlen($pass); $i < $l; $i++) {
        $value += pow(ord(~$pass[$i]), 1/2);
    }

    return (int)round(pow($value, (int)('1.' . $value)) * 10000000000);
}

var_dump(pass('M'));
var_dump(pass('m'));

int(133416640641)
int(120830459736)

As I see it in order to get hacked first the hacker needs to know the int value stored for the password and the algorithm. They can get the value either if they hack my database or grab an old backup file which is known to be the more common exploit (I guess) but still if they don't know the algorithm they wouldn't be able to crack it?

I don't think it is possible to revert a converted value back to the original string as that would be a problem with complexity of however many characters the string contains, right?

The other possibility is if they accidentally input a value that converts to the same value of the original password, theoretically I suppose there should be an infinite amount of strings that can get converted to the same value but I'm not sure about the real chances of this happening, as well as this problem is also present in hashing algorithms known as collision.

As you probably guessed already I'm very far from a security expert and I suppose this is all garbage that I'm talking right now but I want to know why?

Improve this question
2
  • 6
    Well, done you just invented a non cryptographically secure hashing algorithm with millions of hash collisions. Only good for things like hashmap data structures and offers no security what so ever.
    – ewanm89
    Commented Jun 24, 2016 at 9:23
  • Most hashes are only 16-32 bytes anyway (plus an 8-16 byte salt).
    – grc
    Commented Jun 24, 2016 at 10:45

2 Answers 2

Reset to default
3

This is security through obscurity, and in violation of kerchoffs's principle.

if they don't know the algorithm they wouldn't be able to crack it?

Maybe. And maybe analyzing the entries leads to the revelation of the algorithm.

And once an attacker does get the algorithm - via analysis, by getting access to your server, because you posted it here - they have automatic access to all passwords.

This isn't the case when hashing, because one important property of cryptographic hashing functions is that they are slow.

The other possibility is if they accidentally input a value that converts to the same value of the original password, theoretically I suppose there should be an infinite amount of strings that can get converted to the same value but I'm not sure about the real chances of this happening, as well as this problem is also present in hashing algorithms known as collision.
[...]
integers which take up 4 or 8 bytes as opposed to a hash that takes like 150 bytes or something

If you reduce the size, collisions become more likely, as you still have the same size of the input, but a smaller target area.

As you probably guessed already I'm very far from a security expert

That's why you should never roll your own (but I'm assuming this is more of a theoretical question to learn, not something you want to actually use in practice).

Improve this answer
5
  • And once an attacker does get the algorithm ... they have automatic access to all passwords But that's not true, since theoretically an infinite amount of strings can be converted to the same value, they will never be able to tell which one is the original one, they can just find another one that matches the same result value, right?
    – php_nub_qq
    Commented Jun 24, 2016 at 9:23
  • @php_nub_qq lets say you have 'a' -> 'b' and 'c' -> 'd' it only takes a matter of time until it's cracked if the algorithm is the same. Also, if you didn't has on the server, then they can just pass the hash, ad it wouldn't matter much in this case since you're not using hased passwords it will probably be guessed instantly.
    – XaolingBao
    Commented Jun 24, 2016 at 9:27
  • 1
    @php_nub_qq an attacker doesn't need the original one, just one that matches, and that can be found rather quickly.
    – tim
    Commented Jun 24, 2016 at 9:35
  • @tim There's a merit to it then! If LinkedIn used it, then it wouldn't leak users' passwords reused on other sites ;-)
    – techraf
    Commented Jun 24, 2016 at 9:54
  • Yes, that's true (although it's still likely that a correct password is guessed first, as attackers will likely use wordlists, etc). But if that is the goal, mapping the input to [1...100] would be even better, as it hides even more information, making it even less likely that the original password is found ;) (seriously: if that is the goal, additional hashing / obfuscation on the client side would be a better approach)
    – tim
    Commented Jun 24, 2016 at 10:03
1

If you use 4 or 8 bytes of integers to store your passwords, you are making the brute-forcers' jobs a lot easier. Because, if i understand your situation correctly, an attacker would just need to come up with an string so that its converted value(converted to check with the values in DB) matchs the stored password value.

Considering the computing power in todays computers, one would find a matching string as opposed to your 8 byte password very quickly, im not even talking how easy to check 32-bit(4 byte) value.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .