31 items tagged “passwords”
2024
How some of the world’s most brilliant computer scientists got password policies so wrong (via) Stuart Schechter blames Robert Morris and Ken Thompson for the dire state of passwords today:
The story of why password rules were recommended and enforced without scientific evidence since their invention in 1979 is a story of brilliant people, at the very top of their field, whose well-intentioned recommendations led to decades of ignorance.
As Stuart describes it, their first mistake was inventing password policies (the ones about having at least one special character in a password) without testing that these would genuinely help the average user create a more secure password. Their second mistake was introducing one-way password hashing, which made the terrible password choices of users invisible to administrators of these systems!
As a result of Morris and Thompson’s recommendations, and those who believed their assumptions without evidence, it was not until well into the 21st century that the scientific community learned just how ineffective password policies were. This period of ignorance finally came to an end, in part, because hackers started stealing password databases from large websites and publishing them.
Stuart suggests using public-private key cryptography for passwords instead, which would allow passwords to be securely stored while still allowing researchers holding the private key the ability to analyze the passwords. He notes that this is a tough proposal to pitch today:
Alas, to my knowledge, nobody has ever used this approach, because after Morris and Thompson’s paper storing passwords in any form that can be reversed became taboo.
I really dislike the practice of replacing passwords with email “magic links”. Autofilling a password from my keychain happens instantly; getting a magic link from email can take minutes sometimes, and even in the fastest case, it’s nowhere near instantaneous. Replacing something very fast — password autofill — with something slower is just a terrible idea.
[Passkeys are] something truly unique, because baked into their design is the requirement that they be unphishable. And the only way you can have something that’s completely resistant to phishing is to make it impossible for a person to provide that data to someone else (via copying and pasting, uploading, etc.). That you can’t export a passkey in a way that another tool or system can import and use it is a feature, not a bug or design flaw. And it’s a critical feature, if we’re going to put an end to security threats associated with phishing and data breaches.
How researchers cracked an 11-year-old password to a crypto wallet. If you used the RoboForm password manager to generate a password prior to their 2015 bug fix that password was generated using a pseudo-random number generator based on your device’s current time—which means an attacker may be able to brute-force the password from a shorter list of options if they can derive the rough date when it was created.
(In this case the password cracking was consensual, to recover a lost wallet, but this still serves as a warning to any RoboForm users with passwords from that era.)
2022
Consistent with the practices outlined in SP 800-63B, agencies must remove password policies that require special characters and regular password rotation from all systems within one year of the issuance of this memorandum. These requirements have long been known to lead to weaker passwords in real-world use and should not be employed by the Federal Government.
— Memo: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
2020
Weeknotes: datasette-auth-passwords, a Datasette logo and a whole lot more
All sorts of project updates this week.
[... 913 words]datasette-auth-passwords. My latest plugin: datasette-auth-passwords provides a mechanism for signing into Datasette using a username and password (which is verified in order to set a ds_actor authentication cookie). So far it only supports passwords that are hard-coded into Datasette’s configuration via environment variables, but I plan to add database-backed user accounts in the future.
Apple password-manager-resources (via) Apple maintain on open source repository full of heuristics for implementing smart password managers. It lists password rules for different sites (e.g. min/max length, special characters required), change password URLs for different services and sites that share credential backends—like icloud.com and apple.com. They accept pull requests!
2018
Most administrators will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user (who is likely to choose new passwords that are only minor variations of the old) and carries no real benefits as stolen passwords are generally exploited immediately. [...] Regular password changing harms rather than improves security, so avoid placing this burden on users. However, users must change their passwords on indication or suspicion of compromise.
Password Tips From a Pen Tester: Common Patterns Exposed (via) Pipal is a tool for analyzing common patterns in passwords. It turns out if you make people change their password every three months and force at least one uppercase letter plus a number they pick “Winter2018”.
I’ve Just Launched “Pwned Passwords” V2 With Half a Billion Passwords for Download (via) Troy Hunt has collected 501,636,842 passwords from a wide collection of major breaches. He suggests using the to build a password strength checker that can say “your password has been used by 53,274 other people”. The full collection is available as a list of SHA1 codes (brute-force reversible but at least slightly obfuscated) in an 8GB file or as an API. Where things get really clever is the API design: you send just the first 5 characters of the SHA1 hash of the user’s password and the API responds with the full list of several hundred hashes that match that prefix. This lets you build a checking feature without sharing full passwords with a remote service, if you don’t want to host the full 8GB of data yourself.
2013
How could GitHub improve the password security of its users?
By doing exactly what they’re doing already: adding more sophisticated rate limiting, and preventing users from using common weak passwords.
[... 80 words]2010
apache.org incident report for 04/09/2010. An issue was posted to the Apache JIRA containing an XSS attack (disguised using TinyURL), which stole the user’s session cookie. Several admin users clicked the link, so JIRA admin credentials were compromised. The attackers then changed the JIRA attachment upload path setting to point to an executable directory, and uploaded JSPs that gave them backdoor access to the file system. They modified JIRA to collect entered passwords, then sent password reset e-mails to team members and captured the new passwords that they set through the online form. One of those passwords happened to be the same as the user’s shell account with sudo access, leading to a full root compromise of the machine.
2009
For those who haven't heard the story the details were pulled from a Christian dating site db.singles.org which had a query parameter injection vulnerability. The vulnerability allowed you to navigate to a person's profile by entering the user id and skipping authentication. Once you got there the change password form had the passwords in plain text. Someone wrote a scraper and now the entire database is on Mediafire and contains thousands of email/password combinations.
Facebook Hacked By 4chan, Accounts Compromised. It wasn’t Facebook that got hacked: 4chan members got hold of a list of usernames and passwords from an insecure Christian dating site and started using them to raise complete hell. Yet another demonstration that storing your user’s passwords in the clear is extremely irresponsible, and also a handy reminder that regular users who “don’t have anything worth securing” actually have a great deal to lose if their password gets out.
The Anatomy Of The Twitter Attack. Long-winded explanation of the recent Twitter break-in, but you can scroll to the bottom for a numbered list summary. The attacker first broke in to a Twitter employee’s personal Gmail account by “recovering” it against an expired Hotmail account (which the attacker could hence register themselves). They gained access to more passwords by searching for e-mails from badly implemented sites that send you your password in the clear.
Weak Password Brings “Happiness” to Twitter Hacker. The full story on the Twitter admin account hack. I bet there are a LOT of web applications out there that don’t track and rate-limit failed password attempts.
Antipatterns for sale. Twply collected over 800 Twitter usernames and passwords (OAuth can’t arrive soon enough) and was promptly auctioned off on SitePoint to the highest bidder.
2008
Facebook’s new signup process. It looks like they’ve dropped the “enter your password twice” pattern. Is this really a good idea? I suppose if people mis-type it they can always use forgotten password to set a new one.
.. yet another ridiculous data breach: this time, people's passwords to the Government Gateway on a memory stick dropped in the road. Perhaps it is uncouth to point this out, but... if the system had been designed by people with any security clue whatsoever there would have been no passwords to put on a memory stick in the first place.
The Palin hack didn't require any real skill. Instead, the hacker simply reset Palin's password using her birthdate, ZIP code and information about where she met her spouse - the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search.
— Kim Zetter, Wired
OAuth came out of my worry that if the Twitter API became popular, we'd be spreading passwords all around the web. OAuth took longer to finish than it took for the Twitter API to become popular, and as a result many Twitter users' passwords are scattered pretty carelessly around the web. This is a terrible situation, and one we as responsible web developers should work to prevent.
Facebook Security Advice: Never Ever Enter Your Passwords On Another Site, Unless We Ask You To. Nice to see TechCrunch highlighting the hypocrisy of Facebook advising their users to never enter their Facebook credentials on another site, then asking them for their webmail provider password so they can scrape their address book.
Changeset 8162. “Implemented a secure password reset form that uses a token and prompts user for new password”—also sneaks base36 encoding and decoding in to Django.
2007
Historically, Internet companies have rarely encrypted passwords to aid customer service.
The password anti-pattern. What I don’t understand is why Google / Yahoo! / other webmail providers haven’t just deployed a simple OAuth-style API for accessing the address book. Sites have been scraping them for years anyway; surely it’s better to offer an official API than continue to see users hand out their passwords?
Choosing Secure Passwords. Bruce Schneier describes the state of the art in password cracking software.
ephemeral profiles (cuz losing passwords is common amongst teens). Lost your password? Create a new profile; you had too many friends you didn’t know anyway.
2006
Real-World Passwords. Random passwords phished from MySpace are surprisingly decent.
2004
Will Trade Passwords For Chocolate (via) I’m not at all surprised. Most people see passwords as more of an annoyance than a security measure.