https://github.com/apiato/apiato/blob/master/app/Ship/Configs/hashids.php
I am wondering if there is a potential security issue in reusing the APP_KEY for hashing Ids.
Is it not possible for someone to reverse engineer the APP_KEY from a large enough data set of hashids?
I generated a separate salt string for the hashids. I suggest changing the salt to something unique to prevent this potential problem.
Also, what are the consequences of an exposed APP_KEY?
@twcarefoot yes changing the salt string is good idea, if you're worried about the security, I'm gonna add this to the installations steps.
As far as I know the only way to reviser engineer it is by knowing some real ID's, this could be exposed in wired ways. Example, some delete exceptions of non existing ID's, exposes the real ID in the error message "ID xx does not exist.." by getting few ID's it's possible to reveal the APP_KEY.
This is mainly the responsibly of the developer to protect his app and prevent any possible way of exposing any real ID's. Not sure if there's some advanced techniques used by pro hackers.. I'll leave this question open to collect people's opinions on this.
Yes for salt, and lets have an environment var for salt please.
haha, this has been a long time.. but i just added a PR for apiato:master and apiato:7,4 that introduces a new HASH_ID_KEY variable in the .env files. This variable, in turn, is used in Ship/Configs/hashids..
In order to stay backwards-compatible, it falls back to APP_KEY, if no HASH_ID_KEY is found / used..
Most helpful comment
haha, this has been a long time.. but i just added a PR for
apiato:masterandapiato:7,4that introduces a newHASH_ID_KEYvariable in the.envfiles. This variable, in turn, is used inShip/Configs/hashids..In order to stay backwards-compatible, it falls back to
APP_KEY, if noHASH_ID_KEYis found / used..