robbya | 6 years ago | on: Why build this blog, or anything, on IPFS?
robbya's comments
robbya | 6 years ago | on: Barr’s Encryption Push Is Decades in the Making
robbya | 6 years ago | on: Google vs. Oracle: The Supreme Court will decide software development’s future?
On the other hand it's dry, repetitive, and has really poor flow, so I'm struggling to finish it myself.
robbya | 6 years ago | on: Boing Boing Was Hacked
robbya | 6 years ago | on: The “No Code” Delusion
Terraform on the other hand does have a concept of ownership, diff-ing, and applying changes. It takes some work as you now need to track state, but I've been very happy with Terraform.
robbya | 6 years ago | on: Firefox: Homeland security urges all users to update browsers immediately
https://www.mozilla.org/en-US/security/advisories/mfsa2020-0...
robbya | 6 years ago | on: Academic Torrents
robbya | 6 years ago | on: Academic Torrents
Using RSS to allow mirrors to host different subjects is really clever, although some of the categories seem quite large (>5TB). It may be worth breaking up each category (sharding) to keep each to 100GB or less so a volunteer can pick a couple and not worry about running out of disk when a category grows.
Then it would be good to track how many seeds each category-shard has so volunteers can help where it's most needed.
robbya | 6 years ago | on: Google pushed to take action against Android bloatware
robbya | 6 years ago | on: Language Learning with Netflix extension
I wonder how often you get a different joke on the translated audio and yet another different joke in translated sub titles. Kind of wild.
robbya | 6 years ago | on: Language Learning with Netflix extension
Usually I've seen the subtitles shorten the words in the audio. "You must come with me now" -> "Come now" or similar. I've been assuming it's to help the reader keep up with some quick exchanges.
robbya | 6 years ago | on: HTML attributes to improve your users' two factor authentication experience
Depending on how abusive you are thinking, that sounds like rubber hose cryptanalysis. That's a hugely powerful approach and I think all 2FA can be bypassed with that, if not most of modern cryptography.
https://en.m.wikipedia.org/wiki/Rubber-hose_cryptanalysis
> having their phone taken
Keep in mind that other 2FA methods also are phone based, like TOTP / Google Authenticator. Those also fail if your unlocked phone is taken. SMS is even weaker than those, but still better as a second factor versus nothing.
robbya | 6 years ago | on: HTML attributes to improve your users' two factor authentication experience
> The only real defense is to never associate your phone number with personal accounts which even then is often not possible.
Yes that's exactly right. If I don't trust a website to not use my phone number as the sole factor for recovery, then I should not use SMS 2FA on that site and I should not add my phone number to any part of my profile. If I know (how?) that the website won't use SMS for recovery, then SMS 2FA is better than nothing.
As a website owner, if I offer SMS 2FA auth and use SMS in isolation for recovery, then I'd want to stop using SMS for recovery. After that, removing SMS 2FA and not offering any second factor would weaken my security. I.E. SMS 2FA is weak but better than nothing. SMS single factor recovery is terrible, fix that ASAP.
robbya | 6 years ago | on: HTML attributes to improve your users' two factor authentication experience
I agree with everything you said about SMS for account recovery.
Account recovery that uses a phone number is weak. There was a paper on HN this week that detailed this.
However, if we are going to compare SMS 2FA (I.E. password plus code sent over SMS) against just password, SMS 2FA wins. In both cases I need to steal your password, the SMS part is an added challenge although it's easier to bypass than many people want.
Given SMS 2FA and any other 2FA option, SMS 2FA loses.
robbya | 6 years ago | on: HTML attributes to improve your users' two factor authentication experience
Surely SMS 2FA (without a backdoor) is better than nothing. Sites should still offer something better than SMS for 2FA as it has widely documented issues. But as an end user presented with SMS 2FA or no 2FA; SMS 2FA is the safer option.
Is there a reason to assume an arbitrary SMS 2FA implementation would have a back door? That would be news to me.
robbya | 6 years ago | on: SMS is not 2FA-secure
The paper mentions some websites that claim to use SMS 2FA, but actually use SMS as a single factor for password resey. While that's really bad I think the solution is to fix those broken implementations not to stop using SMS 2FA everywhere in favor of using nothing.
robbya | 6 years ago | on: SMS is not 2FA-secure
robbya | 6 years ago | on: SMS is not 2FA-secure
robbya | 6 years ago | on: Ask HN: How many of you are rolling your own auth?
I once collected a $3k bug bounty over this. Python's use of Mersenne Twister in the lib/random module should not be used for token generation. Mersenne twister uses a relatively small state space and is fully deterministic (it never re-seeds or mixes in new entropy). If you get a couple sequential random values you can reconstruct that state space and predict all future values. I.E. request a password reset 10x in a row and examine the tokens in the emails.
Please only use secure random number generators when creating security related tokens.
Example blog post: https://know.bishopfox.com/blog/2014/08/untwisting-mersenne-...
robbya | 6 years ago | on: Always Review Your Dependencies, AGPL Edition
I actually played around with turning it into a GitHub action for further usability improvement, although it needs more work: https://github.com/ralexander-phi/license_approval