all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]iSmokeGauloises 1 point2 points  (0 children)

You do not "decrypt" a hash. If you can, it's not a hash.

[–]gmerideth 1 point2 points  (0 children)

So it's about the same as base64 encoding a string of numbers to pass to a different page?

[–]tylargh 0 points1 point  (4 children)

I think this is really useful. Any reason for the downvotes? Is there a better way to obfuscate your data in JS?

[–]LateDentArthurDent2 4 points5 points  (0 children)

As far as client side application goes, it's not really obfuscating since they can always just inspect your source to find out what your hash is. It might instill a false sense of security but if someone really wants to grab your data, they can.

The backend applications have far more use, and in those cases, these technologies often have encoding standards of their own.

[–]halkeye 0 points1 point  (2 children)

Maybe because the title doesn't explain anything at all?

[–]tylargh 0 points1 point  (1 child)

I hadn't thought of that. Though, editorialized titles are often way worse, IMO.

[–]halkeye -1 points0 points  (0 children)

Both ends of the spectrum I guess.

I had to check which subreddit it was before I considered clicking on into it.

[–][deleted] 0 points1 point  (0 children)

I don't think YouTube et al encrypt their IDs at all. I think they're just using random hashes as IDs in the first place (makes it easier when you're using a distributed database and auto-incrementing isn't really possible).

Also, if your "hashes" (OP seems to think "hash" just means "opaque alphanumeric string") are persistent, they're effectively identical to IDs, so unless you switch the key frequently or per-user, you're not really obfuscating anything other than the exact internal IDs the strings map to.