Unicode domain names, Google OAuth phishing...changing my passwords every 30 days is looking less and less important.
It's sad we can't seem to provide good, usable secure software.
It's sad we can't seem to provide good, usable secure software.
Sidenote: I don't think that was ever a good idea, unless you think you were likely to type your password into phishing sites in the last month.
The requirement should depend on password and hash strength, not some arbitrary decision.
PCI does not recommend employing password entropy checkers either.
90 day password can be weak while passing all the requirements.
Making people reset their password every 90 days probably causes more problems than it solves and incentivizes more easily guessable passwords.
However, as many people are already thinking, Complexity reduces Security and Stability. Therefore, it seems that the more we try to fight the "hackers", the more likely we will add some insecurity which they can exploit.
Complexity can both improve and reduce security depending on specifics, and thus generalizes to "no correlation" demonstrating that generalizations are often misleading.
Using some non-English Unicode text as password will make the password really strong. I sometimes include Malayalam text for passwords as it's my native language.
In 10s, why would Google docs ask for an oAuth prompt with big permissions?
People click through security dialogs, it is a known fact.
(Of course, this is a different situation and all, and there is a lot of sense in your comment that mine doesn't at all invalidate.)
Lastpass.
(For those who may have missed it in this HN crowd, let me momentarily invoke a veil of joke-explainer and offer this http://knowyourmeme.com/memes/hunter2 of the joke.)
Here's an article: https://medium.com/@ninjudd/passwords-are-obsolete-9ed56d483...
So although I do agree with you (and have created sites in the past that do passwordless login), the general password problem doesn't really get solved with this approach.
Probably not anymore secure--and a nightmare to manage. But look to consensus algorithms for authentication ideas.
Every Unix system has a mail daemon as a core function. If you've ever seen "This incident will be reported." because your user is not in the sudoers group, the incident gets reported via the local mail system. Mail servers today (outside of Microsoft's Exchange servers) are still overwhelmingly Unix-like systems. A mail user just needs a Unix host, a username and ssh + mutt/pine to access their mail in this way. Then an attacker needs to identify the unix host, the username and the ssh credentials. The first two bits are likely to be trivial - the Unix host is probably published in DNS MX records, and the username is probably the local part of the email address. The last part does not necessarily need to be a password. Good security practices will have it be an ssh keypair. ssh keypairs are provably computationally secure (until quantum computing comes along) and ssh private keys often also have passphrases. Other measures - like U2F security keys - can also be required as part of ssh authentication.
So this is probably the gold standard when it comes to security for an email inbox. Is there any way we can make this more usable so that a GUI mail client can be used? One answer is to run the mail client on the Unix host and use ssh X forwarding to display it on the client machine. Another answer is to run a POP or IMAP server on the Unix host, force TLS and use normal plaintext passwords over the TLS tunnel.
Both the ssh and the IMAPS solutions require some way to authenticate the server side of the connection. The ssh mechanism typically defaults to trust on first use, but since one is publishing DNS records anyways, a SSHFP (ssh fingerprint) record seems like a good additional step. The IMAPS solution requires re-authentication of the certificate for each session. I am not sure what the current state of the art is for this for IMAPS servers. I personally believe that the CA model used for HTTPS is severely flawed.
All of this to say that for the truly dedicated user of a certain minimum (but high!) level of technical sophistication, passwordless login everywhere is possible (ssh keys; or having the email client securely store the password for use with IMAPS).
Software bugs should be no less than product defects, with possible fines in place.