Safari Password Generation
twitter.com
twitter.com
For this, they wanted to accurately capture the exact rules each site uses, which makes sense to do out-of-band -- ahead of time, and validated by humans -- than to try to discover from the site dynamically, especially because the latter solution, in a world without sites making their own requirements available in a programmatically readable format, would have been complex and brittle.
In a program, this sort of data may be hard-coded directly in the code, or dynamically loaded from config files. That's largely an implementation detail.
About that, is there a standardised way to do it?
The following, for example, creates a password field that requires exactly six ASCII letters, including at least one uppercase and one lowercase letter, and forbidding having the same character twice in a row:
<input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">(Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.)
Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)
1) have a minimal password length 2) check all passwords against a set of known bad passwords
I don't see a decent way to do 2) based on a backtracking RE engine.
(?!password$)(?!123(?:4(?:56?)?)?$).*Ouch, are you looking at me? I just chopped out a fragile "general case" implementation of something today and replaced it with something that robustly gets the job done for the small number of cases we have. I was the writer of that fragle cruft a couple of months ago.
Office365 doesn't support passwords > 16 characters in length. WTF.
Also Paypal doesn't support any form of secure OTP.
Also, Paypal forces security questions on the user.
In other news, my Hearthstone account has better security than my money.
Be between 8 and 10 characters long (with no spaces)
Contain only numbers and letters (no characters like @*? etc).
Start with a letter.
Not contain 3 numbers in a row.
That is a requirement in a ton of places. Try creating an Oracle database user, and have the password start with a number. To be fair it's documented that it won't work, but Oracle won't stop you from doing it, so you end up with an unusable account.
So for example, a bcrypt output might look like: $2a$12$2zuYZPvIlfC.L84k0oWZR.8yGd62dPkhoyg4aEC6TzGl7aASTw5F.
But still...
https://github.com/jleclanche/python-bna
See the README for usage :)
This should help you to have a backup next time you get locked out!
The official authenticator also displays a backup code which it tells you to keep a copy of somewhere safe...
You can bypass the limit with ADFS.
Humans are bad at remembering most things. The more entropy there is, the more difficult it tends to be for us to remember.
The way for increasing password entropy, whilst lowering the human bound, tends to be by utilising things humans find easy to remember, but computers find difficult to randomly/brute-force solve.
That usually requires a longer password.
You can sort-of bypass the human memory problem by using password managers, but they have their own set of problems (mostly usability), and assuming people actually use them is an assumption too far in most cases.
Is that really secure? I mean, 6 numbers is not exactly a very strong secret.
Until then, this way works.
If you don’t know what you’re doing, you probably wouldn’t know how to put information in a manifest anyway…
Does that seem like the kind of site that will take action to help users with password managers? Personally, I wouldn't expect that kind of site to be quite up-to-date with the newest security practices.
Recently, saw strange thing -- I was allowed to have password with lengths between 16 and 128 characters, but my password manager 1Password supports only... 60 or 64 characters. Oh well, wish that this would be a problem, not other way around. Still kills me that my health records are behind 12 characters password, and my bank think 16 character password is enough.
I’ve always liked the idea of using a predefined sentence structure and having lots of choices to increase entropy, e.g. The magic butterfly flapped faithfully. Article adjective noun verb adverb. No one does this of course.
In FastMail, it’s much the same but without emailed codes as an option, because it is your email account that you’re trying to log in to.
I think we support almost arbitrary lengths and arbitrary Unicode in both now. (And note that due to how the fancier password hashing algorithms like bcrypt work, supporting beyond ~72 characters without loss of entropy actually tends to take deliberate design; and if you get it wrong, it can be a DoS vector—Django had such a problem a few years back, where you could feed it a 1MB password and keep it occupied hashing it for ages.)
I have wondered before how secure a single astral plane Unicode code point would be as a password. I haven’t investigated the question at all.
Not sure what else is expected in this case, you'd get the same behavior from most other password managers.
The latest iOS versions have also included a "five clicks on the power button" emergency option, which disables both TouchID and FaceID. It's not perfect, but if you're going into a questionable situation, it's a good way to avoid being coerced into using those to unlock your phone.
It's not clear what the best solution is here, or if the best way to have the conversation about it follows hyperbole like "the most disturbing thing".
I think password managers are on the whole a good thing because people are using more (stronger) passwords.
I also think the password manager could (at least on trusted hardware like an iPhone) provide some protection from the attacks you're alluding to, such as a tarpit that slows access to the password database, but they certainly won't offer any protection on a desktop machine without specialised hardware and it might be difficult to get right -- difficult enough that new security vulnerabilities are introduced instead.
What exactly do you propose?
Firefox works similarly: Once you unlock it, you see all the passwords. On an iPhone or Google Chrome, you have to click each password you want to see.
Edit: I see you are worried about devices already linked
Hmmmm.
(I mean HN doesn't impose any restrictions, as I remember it.)
But by and large, people have been trained into terrible habits concerning passwords, and they have no idea how to make a halfway decent password. I tend to think a good baseline for most sites is to use zxcvbn and reject passwords with score 0 (which means, guessing is expected to take less than 1,000 attempts). That way you’re not being particularly onerous, but you are at least blocking useless passwords.
Still, there’s a space in some services for allowing no password. NewsBlur allows a zero-character password, for example, and that’s fine. I’d much prefer a thing to allow no password if possible, deny useless passwords and allow anything else (with hints about weaknesses), than have rules about character classes and mandatory inclusions.
I've posted its contents here - https://pastebin.com/iPY6gLSC
There's a separately named WBSFormAutoFillKeywords.plist.
It's located at /System/Library/PrivateFrameworks/SafariShared.framework/Resources/WBSAutoFillQuirks.plist on the iOS base system image.
Googling the filename of course returns no results.
I am VERY curious how 1Password were confident they'd be able to get anywhere with getting a copy of this. I have no info suggesting they'd have a problem with it, of course, and time will tell if it works out.
Learn more about passwords and your Apple ID When you create a new password, keep the following in mind:
Your new Apple ID password must contain at least eight characters, a number, an uppercase letter, and a lowercase letter. You can't use spaces, the same character three times in a row, your Apple ID, or a password you've used in the last year. Learn more about password requirements and how to keep your Apple ID secure.
FaceTime is not available in all countries or regions.
Published Date: Oct 20, 2017
That only works if you presume his password was generated as a string of random bits though. If the password was generated as a dice-ware password [1] with 5 characters this reveals roughly 2 bits of entropy. For we know he doesn't use -, _ or nothing as his word-separator. Those 2 bits aren't included in the calculation that states his diceware password has about 65 bits of entropy though. (5 words from a list of 8000) 65 bits feels like plenty to me.