Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I don't have the most knowledge on this one but I know someone who does: @PerfectAsshole
-
Is rate limits out of the question? In this case rate limits should be your first line of defense and if the limit is exceded it needs to be flagged. 3600 request in an hour should be an easy limit to set cause if a phone hits more requests than that it has been hacked. I would try to make a lower limit cause one request a second is pretty easy for a hacker to work with
-
@PerfectAsshole I am mostly concerned about fake data being inserted by the attacker cluttering up real reports etc., so the rate limit I could setup, but wouldnt really help much with how to prevent him from spoofing or spamming it. It would surprise me if this actually ever happens, but I would like to have the onsight people atleast trained to that rare scenario, so I dont have to manage it anymore. Like how do people secure their api keys they pay for and use in decompilable binaries? do they just live by the "if it happens" thought? so if it actually does get abused some day, they just push an update with a new key and it basically circles forever that way? it just sounds weird to me.
-
@JoshBent Glad you're thinking about that most people wouldn't and say thats the users problem. In this case you could implement the oauth spec to issue access and refresh tokens, if an access token gets mitm it doesn't matter cause its short lived. if the refresh token is the app would fail to authorise where you could deauthorize the old key and issue another one.
-
@JoshBent oh as for the question people will generate a new set of keys if it happens. Not really the best model but there's not a better way at the moment
When the API is not documented.
Ladies and Gentlemen,
I present you the API I'm working with...
That's a pretty fucking useful error descrip...
(Question/0.5Rant)
So I am working on a mixed API (aka reachable from anywhere, but also only accessible by specific allowed devices) and I am struggling with the security of it, its not managing anything hardcore (this API is "is the coffe ready?" kind of level) or I would have just enforced per device registration for example already, but the app that goes with that API is deployed remotely and has to be "ready to go!!!" out of the box, so I can't add any registration, verifications of devices etc.
The main thing I am afraid of is, that one of those agent retards will get his spaghetti phone blasted from the inside, so all the https calls will be read out by some random attacker, which then will be able to "abuse" the API via read out api-key, is there any way for me to have a rescue plan if one of those retards does get hacked and the system then get spammed or something, like if I log all devices that use the API I could just deny access from that device (until resolved) and issue a new app update via new api key.
What's the best way of handling this and is my idea really the only way to handle this? this shitfest is really causing shit ton of ideas in my head, which then I deny literally 20 seconds later, because there's a way to bypass it or once you have the old api key to get a new one by just monitoring it etc.
undefined
shitfest
question
api