1) User goes to BAD website and signs up.
2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.”
3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email.
4) GOOD sends a one-time login code email to the user’s email address.
5) The user is very likely to trust this email, because it’s from GOOD, and why would GOOD send it if it’s not a proper login?
6) User enters code into BAD’s website.
7) BAD uses code to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.
This is why “email me a one-time code” is one of the worst authentication flows for phishing. It’s just so hard to stop users from making this mistake.
“Click a link in the email” is a tiny bit better because it takes the user straight to the GOOD website, and passing that link to BAD is more tedious and therefore more suspicious. However, if some popular email service suddenly decides your login emails or the login link within should be blocked, then suddenly many of your users cannot login.
Passkeys is the way to go. Password manager support for passkeys is getting really good. And I assure you, all passkeys being lost when a user loses their phone is far, far better than what’s been happening with passwords. I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.
I set up a passkey for github at some point, and apparently saved it in Chrome. When I try to "use passkey for auth" with github, I get a popup from Chrome asking me to enter my google password manager's pin. I don't know what that pin is. I have no way of resetting that pin - there's nothing about the pin in my google profile, password manager page, security settings, etc.
1) User goes to BAD website and signs up.
2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.”
3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email.
4) GOOD sends a one-time login code email to the user’s email address.
5) The user is very likely to trust this email, because it’s from GOOD, and why would GOOD send it if it’s not a proper login?
6) User enters code into BAD’s website.
7) BAD uses code to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.
This is why “email me a one-time code” is one of the worst authentication flows for phishing. It’s just so hard to stop users from making this mistake.
“Click a link in the email” is a tiny bit better because it takes the user straight to the GOOD website, and passing that link to BAD is more tedious and therefore more suspicious. However, if some popular email service suddenly decides your login emails or the login link within should be blocked, then suddenly many of your users cannot login.
Passkeys is the way to go. Password manager support for passkeys is getting really good. And I assure you, all passkeys being lost when a user loses their phone is far, far better than what’s been happening with passwords. I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.
As long as that remains true, don't see how this bubble will be popped
That's what everybody was saying in February 2000.
Frigate's better than anything else I tried, but not perfect. As mentioned in another thread, it has some issues with codecs from some cameras (playing clips from Amcrests is fine, Hikvisions not so much) and therefore you may need to transcode. Also it has no built in option for sending your recorded clips offsite; theoretically you could mirror its storage directory, but as far as I've found it's not organized in a way that you can separate just important events.
Why are people still installing security cameras that are monitored by them? They increase stress level and felt insecurity. They do not make you feel secure, say psychological studies. You probably think more about burglaries and dead spaces in your setup and actively monitor for these in your daily lives, where for 99.8 % of people this should be a non-topic.
If you want to install them for later police work, that still seems tedious and you might require off-site backup. In public places we often have CCTV of people, but unless you have number signs on vehicles, they seem to not help with conviction rates by much.
Why do the "security" apps ALWAYS have to have this anti-feature? It's especially annoying when employed by the banking apps.
Famously, Schwab had some issues where it didn't properly keep track of orders during highest loads (people ending up selling more shares than they had even in IRA accounts), yet conveniently they prevent users from taking screenshots of their app, so you wouldn't be able to prove that you did cancel or replace the order and did receive the cancel confirmation, before it executed anyways. Of course, if it's an IRA account, selling more shares than you own, is clearly Schwab's bug, but not being able to keep these things locally, is one of the biggest anti-features of modern apps.
a) I cancelled my "intelligent advisor" accounts (which was a pain to do by itself) and had the money xferred back into regular IRA accounts. After this was complete, I was no longer able to see any trade history for the past 12 years of those Intelligent Advisor accounts, *even though they were ostensibly backed by regular Schwab IRAs*, and my historical "wealth" tracking in Schwab made it look like I'd simply never had the $NNN^n that was in those accounts for that period of time, or in other words as if I'd added $NNN^n to my accounts on the day of the transfer. Definitely some hackery there. I had one Schwab rep who acknowledged this as a (rather severe) problem, but the other 3 I spoke to did not even understand why it was an issue.
b) For an example of their approach to data in general, take a look at their historical chart for the WEED ETF around the time of the reverse split in 2023, and compare it to how WEED themselves chart it, and how Fidelity charts it. Schwab's presentation of the price history isn't justifiable, and essentially omits information. (https://www.schwab.com/research/etfs/quotes/summary/weed, https://www.roundhillinvestments.com/etf/weed/, https://digital.fidelity.com/prgw/digital/research/quote/das...). Their support brushed this off.