At the risk of seeming confrontational (i'm trying not to be). I'm curious to understand your reasoning to discount the concerns raised in points 2 & 3.
Short passwords with little to no complexity are useless. check this link to see how quickly a short password can be guessed.
Allowing continued login attempts simply ties up resources and allows the attacker to eventually guess their way in. So, at the least your service will run slower than it should and at the worst the attacker can eventually get in. Rate limiting logins can go along way to securing resources by deterring brute force and rainbow dictionary attacks.
Of course context is key for this type of concern. Is the API accessible via public ip address? If not, it's probably ok to not worry so much about rate limiting, but password complexity is a must regardless (in my opinion).
As for Item 1, I too have thought that HTTPS alone is not enough to secure certain types of data in transit. Although the profession at large doesn't comment on it, i wonder if there's something to that question. This SO Question seems to negate the concern.
I'm looking forward to reading your findings in future posts.
Respectfully,
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
thanks for your feedback. We'll get to the password part soon when I finish my next post. ;) Spoiler alerts - it was a misunderstanding what the password length check in that context means and what is it used for.
Stay tuned!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Slavius,
At the risk of seeming confrontational (i'm trying not to be). I'm curious to understand your reasoning to discount the concerns raised in points 2 & 3.
Short passwords with little to no complexity are useless.
check this link to see how quickly a short password can be guessed.
Allowing continued login attempts simply ties up resources and allows the attacker to eventually guess their way in. So, at the least your service will run slower than it should and at the worst the attacker can eventually get in. Rate limiting logins can go along way to securing resources by deterring brute force and rainbow dictionary attacks.
Of course context is key for this type of concern. Is the API accessible via public ip address? If not, it's probably ok to not worry so much about rate limiting, but password complexity is a must regardless (in my opinion).
As for Item 1, I too have thought that HTTPS alone is not enough to secure certain types of data in transit. Although the profession at large doesn't comment on it, i wonder if there's something to that question. This SO Question seems to negate the concern.
I'm looking forward to reading your findings in future posts.
Respectfully,
Hi,
thanks for your feedback. We'll get to the password part soon when I finish my next post. ;) Spoiler alerts - it was a misunderstanding what the password length check in that context means and what is it used for.
Stay tuned!