71–74 of 74 posts
Two words are shown for reCaptcha, one that is "by definition" ocr easy and one that is hard. You don't need to "solve" the one that is hard. In-fact, you can put anything for the hard one. You only need to solve the part that is "by definition" ocr easy.
Earlier quoted context omitted.
You're now outsourcing your users security to their cell phone provider. Was it Twitter who had their domain hijacked by someone ringing up the right telco and saying something like "my cell pone is out of action temporarily, can you please forward all calls/messages to this other number?" in a sufficiently convincing fashion to some minimum wage telco support staff, then getting a two factor auth token sent to an at…
Thanks for the feedback! You brought up a valid point. It's something that will become more of an issue as the website increases it's user base and we'll think of ways to address it.
http://www.itnews.com.au/News/322194,telcos-declare-sms-unsa...
"The lobby group for Australian telcos has declared that SMS technology should no longer be considered a safe means of verifying the identity of an individual during a banking transaction."
Earlier quoted context omitted.
To provide a counterpoint, the section about the "Remember Me"-cookie is rather terrible (I stopped reading after that). It's not fundamentally flawed but rather inelegant (and potentially expensive) to store a magic number server-side for each session. You can implement the same thing more easily by handing out tamper-proof (HMAC) cookies containing the start- and end-time, and storing only the last_logout-timestamp…
The problem for most mere mortals with the HMAC scheme is that there is a very real possibility of the server being compromised and the secret key being stolen. In this case an adversary could generate valid cookies for any user. However, with the magic number scheme as long as only the hash of the random number is stored (we should add a per-user salt too) then the entire session database could be compromised, but a…
Replay-attacks work the exact same whether you use this scheme or store a magic number server-side. There's no difference whatsoever.
For a password-change you update the last_logout timestamp and hand the user a new cookie (since his current one was just invalidated).