rtev

16 ms·

1. 151.▲
   by rtev 4y ago

   Isn’t that just the illusion of security?
2. 152.▲
   by rtev 4y ago

   I would imagine they would be fired too.
3. 153.▲
   by rtev 4y ago

   A pretty good ROI, if I had to guess?
4. 154.▲
   by rtev 4y ago

   That’s interesting. From what I have seen, SWE is about 30% higher salaries on average. What field did you work in prior?
5. 155.▲
   by rtev 4y ago

   What happens when another dev takes over and loads the module? This sounds similar to using a vulnerable library without invoking the vulnerable function - it still could unwittingly be used in the future.
6. 156.▲
   by rtev 4y ago

   It’s easy to ignore what’s impossible to morally justify.
7. 157.▲
   by rtev 4y ago

   It’s already possible to do this in real-time
8. 158.▲
   by rtev 4y ago

   I may be misunderstanding you, but I do want to reiterate: if it’s in localstorage, I will hijack user sessions on your pentest. If there’s a use case to keep session tokens in localstorage, it’s insecure design that’s inherently vulnerable
9. 159.▲
   by rtev 4y ago

   I’ve always liked the way Apple does it. For iCloud, the ‘Forgot Password’ page requires a first and last name. I imagine you could do something similar for registration: if the user email already exists and the first and last name is the s
10. 160.▲
    by rtev 4y ago

    In your “should I..”s, you mention implementing multiple insecure approaches. If you’re implementing sessions tied to localstorage, your application has a medium severity vulnerability. If you’re improperly invalidating, that’s yet another