331–340 of 474 posts
Earlier quoted context omitted.
I stay away from everything crypto but I don't see the difference. In both cases if they didn't make it right you'd go to the courts and make your case that they are at fault and owe you compensation.
In the first case, bank deposits are insured. In the second case, safe deposit boxes are not insured.
Earlier quoted context omitted.
What do you use for the base password? The website name? So if someone finds out your password for a certain site is `Facebook1234ABCD` they have a fair guess at every other password? Same applies for `MyPasswordFB` using the reverse method.
My base password is secret but it is an alpha numeric string with mixed caps. An example would be “p45Sw0rD-Apple+” something in that vain. So in the end the password contains numbers, letters both capped and lower case and special characters.
Earlier quoted context omitted.
> If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans. This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.…
Maybe instead of a crypto brokerage holding your wallet, there can be a "key bank" which uses those more expensive methods of attestation and you can use it for recovery if you lose your key up to once per year or something. It would be like having your key written down in a safety deposit box at a local or regional bank.
By geographically distributing your signing devices you improve both security and reliability. One of those keys can be hosted by a third party to be used for recovery, without providing them any ability to touch your funds without your involvement.
Earlier quoted context omitted.
My base password is secret but it is an alpha numeric string with mixed caps. An example would be “p45Sw0rD-Apple+” something in that vain. So in the end the password contains numbers, letters both capped and lower case and special characters.
I think their point is that no matter how secure your base password is, once one site leaks it, the bad guy basically knows your password to every site.
For most people, doing stuff on computers is a matter of brute forcing it until kinda does what it's supposed to. Software is made by people who have an intricate understanding of how the underlying system works, but it's made for people who don't. When users get to a pattern that works, they stick with it. It's becoming even more common now that many schools are using tablets for education - they don't get a good fe…
Maybe 10% of software developers actually have an intricate understanding of what they do, in fact it is because developers don’t really understand what they are doing is why regular people brute force horrible software.
Earlier quoted context omitted.
They're just different things. The FDIC insurance is for if the bank itself goes insolvent and they literally don't have enough money to cover their depositors' balances anymore. There's no reason a safe deposit box would be affected.
A fire, a flood, a robbery...
The idea that someone is going to invent and remember a password for every dumb service is not real, and when you build another password based authentication system, you are doing a kind of LARP. Passwords are used in one of two ways: 1. a password manager guarded by a single actual password 2. the same password repeated between services Practically every service offers e-mail recovery, so, in practice, your e-mail i…
I'd also add that forgot password features at least notify the address owner of every attempt. Password based logins don't always email on every login from a new location.
Email accounts are the highest common denominator in online authentication. Phones are competitive, but people lose phones. Phone numbers are more common and durable, but the security of phone numbers is leagues below that of a flagship provider email account. It makes sense that so many authentication flows work this way. When designing a "fantasy football" alternate authentication system for the Internet, start wit…
It's an interesting design problem to have panel of peers attest an individual's identity. It could be made fairly seamless if there was a common system in which a suitably distributed authentication secret could be recombined under instruction from the relevant party. Can it be made to work for normal humans? I daresay we have the ingenuity to design something...
However the utility is probably nil if there're no social features to begin with.
1. User enters email
2. We send a verification code to their email
3. User enters code, is signed in "indefinitely" (very, very long cookie)
Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.
There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.
Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.
Earlier quoted context omitted.
Doesn't your browser remember your passwords?
my wife chooses not to let chrome remember her passwords because she thinks it's lazy and insecure: everyone uses chrome, how will chrome know not to give her password to someone else?