381–390 of 392 posts
Earlier quoted context omitted.
Yeah, assuming that my biometric auth is relatively strong, stays on my device, and is a device-specific hashed representation I have a hard time finding fault. I believe most modern phone's biometrics fit that criteria.
> stays on my device Heh.
Earlier quoted context omitted.
The thing that I find super frustrating about these short sessions is the lack of risk it's mitigating. If it's expiring in a few minutes, presumably you're trying to protect against two things: (1) Session hijacking and (2) Unlocked computer. Session hijacking is somewhat preventable via other means (eg: IP address tracking), but more importantly, in what case can a session be hijacked only 15 minutes later? Someone…
For very short sessions that is likely true. But I think there is a middle ground where devices are lost or stolen, or data is accidentally leaked. If it is a sophisticated targeted attack you have already lost. But maybe someone just threw out an old PC that they haven't used in years and the disk isn't encrypted. For my service I ended up doing something in between. Sessions last for 14 days, but they are automatic…
> someone just threw out an old PC that they haven't used in years and the disk isn't encrypted.
These are scenarios where I think expiration doesn't help at all. I assume your reaction is not just "oh well, the compromised sessions on that device will expire in 70-ish days so we can just ignore it" but instead you immediately consider everything on the device compromised and kill all sessions, rotate all account passwords, etc.
If it takes you a day or two to notice this event happened, expiration doesn't help: long expiration hasn't happened yet, and with a short expiration, you still don't know and can't assume it protected anything. In fact, the safe thing is to assume the session was accessed within minutes of the incident.
> For my service I ended up doing something in between. Sessions last for 14 days, but they are automatically renewed indefinitely.
This is a pretty rational approach, but of course the time frame depends on your users and how they user your system. Auth0 has a good rationale behind their approach[1]:
> You can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout).
> The motivation behind the 100-day idle timeout cap is to cover one quarter plus a few days, which provides wiggle room for people who log in to do end-of-quarter reports.
[1] https://auth0.com/blog/balance-user-experience-and-security-...
> Gileadite soldiers used the word "shibboleth" to detect their enemies, the Ephraimites. The Ephraimites spoke in a different dialect so that they would say "sibboleth" instead. Experience : you just had to say a word. Security : there's a single word to authenticate multiple users and it can be cracked by learning how to spell it. Although that's roughly how the Wikipedia entry[0] summarises it, the actual wording…
In the Finnish civil war in 1918 the White Guard asked captives to say "one" in Finnish ("yksi"). The word starts with the wovel [y]. This is very hard to even learn to pronounce. When the Russian speaking captives tried and failed to utter the [y] they were shot on the spot. Finnish natives got the luxury to starve often to death in concentration camps. In WW2 the sibboleth was changed to "höyryjyrä".
Earlier quoted context omitted.
I love the Apple ecosystem, however I always have a low level of dread that someday I will somehow offend them and be permanently blacklisted. This is the main reason I've drawn the line at using their password manager or email - I use separate email and separate password manager so that in a worst case situation I don't get locked out of everything .
Not to be argumentative, just wondering, has there been a case related to iCloud access that Apple has ever blacklisted someone? Certainly, I've heard of Meta and other companies doing not, but don't recall Apple outside of security confirmation issues people are having.
Earlier quoted context omitted.
I learned French as an adult, and I cannot at all hear the difference between the words "rue" and "roue." People tell me there's a difference and they try to sound it out to me, but each time they do, I just have to trust that they aren't saying the same thing twice.
There are native-English dialect groups which make no distinction between the vowels in 'pin' and 'pen'. For all I rib my wife about falling on the other side of that line, it took my American ear a long time to hear UK-dialect(s) distinctions between 'Mary', 'merry', and 'marry', and still a fair bit of concentration to reproduce them!
A friend of mine recently got caught in a loop where he wanted to interact with an account that he hadn't used in a long time, which was registered under an email he hadn't used in a long time, which had a recovery email set which he also hadn't used in a long time. He had the passwords written down for all three, but account A refused to let him in without an email verification (but would let him in without a password, if only he could access the email), and email A wouldn't let him in without proving he had access to email B, which wouldn't let him in without proving he had access to email A. A person who wandered into a logged-in computer with access to email B could theoretically have done anything they wanted to all 3 accounts, password or not, but the rightful owner was forbidden from using any of them, despite knowing all the passwords.
I miss the days of, "You have a password, and we'll assume anyone with that password is you. Don't get phished." It's actually pretty easy not to get phished, and sometimes downright impossible to go through the hoops that all of these new anti-phishing measures require.
A service I stumbled into recently which I think does it right is Mullvad. They've taken it a step further and done away with usernames, too. They just give you a long numerical code and tell you that if you lose it, you're screwed. It feels much more respectful to the user.
Earlier quoted context omitted.
Dominos has the best checkout experience I ever experienced online. Nothing can beat it IMO, at least nothing I came across. Now they only sell (arguable mid) pizza, but when I order there it’s delightful (to use an overused 2023 marketing buzzword)
In my city they used to have a 25 minute (!) click to door delivery guarantee. Extremely impressive.
Earlier quoted context omitted.
Seems like parsing semantics. "Pre-given them" - are you giving it directly to apple.com? No. You're putting in your hardware, true. And... somehow... it makes it to all your other apple devices.
Apple Pay is one of the (few) things where that is not the case. New phone = manually re-adding cards to Apple Pay. Get an Apple Watch? It does not get your Apple Pay info until you manually add them to the watch.
We are going way over the top with 2FA. Why do I need to activate mandatory 2FA in services like GitHub repositories for hobby projects? It's a lot of extra effort for a questionable security improvement, and anyway, if someone impersonates me there, it's not the end of the world. If they care about end users (which my projects mostly don't even have) mark me as "unverified" or something, but let me avoid the hassle.…
Not that long time ago there was a discussion about 23andMe data leak through user accounts that reused emails/passwords on some other compromised site. I was surprised how many people here argued that 23andMe should be responsible for this data breach because it's common knowledge that people reuse passwords all the time and yet 23ndMe didn't make 2FA mandatory until after the leak.
Personally I prefer to have a choice on whether 2FA should be enabled or not but I also understand companies that don't want to be blamed for something that is entirely user's fault so it's much easier for them to make 2FA mandatory, even though with phone apps it's not really 2FA since it's the same device.