I highly recommend Troy's HIBP service, hiding your e-mail from showing up in public searches (important for opsec), and donating whatever you can to Troy. He's doing excellent work. This is the first time it's notified me and it was great, because I completely forgot I signed up. I appreciate a service that low maintenance.
HIBP is a truly essential service and I'd be happy to pay more. Even with good password discipline it's useful knowledge on your exposure and I cannot recommend it enough. He mentions it near the end but this is one of those no brainers that should be repeated very loudly.
There's a world of difference between a well-designed pubkey interface like ssh-agent and what you get in today's browsers.
I don't know how feasible it would be to replace passwords for the general public, but if browser vendors were actually serious about security, they could go a very long way towards making client certs feasible just by giving up on their current strategy of putting their fingers in their ears and pretending it doesn't exist.
Something similar in Spain, your mandatory ID card is a smart card, and you can also ask for free personal certificates from the Royal Mint. Works really great to do paperwork from home, but only a minority uses it.
I'd love it if every time I wanted to log in, I entered my username/email, saw a two factor-auth, and had an email sent with a time sensitive link containing my session credentials. But this would be a pain in the ass if I had a slow connection or used an old email address. And worse, it be totally unsafe if I could (easily?) change the email address attached to the account.
To generate random, strong passwords. Also not to be locked into a browser. Better actual password management (e.g. last changed). Tags.
A canary of chrome did have the ability to generate random passwords, but password management in chrome is still a pain IMO. Not sure about FF, but a quick google suggests it doesn't generate random passwords automatically.
People use other managers for many reasons: storing passwords (and other secrets) which aren't used on a site, using them on different browsers (say, Safari on the desktop and Chrome on mobile) and lack of trust on the browser's password manager.
Also, for a long time, browsers didn't save passwords with forms marked with autocomplete=off.
I don't, but would the extension in-effect need to have all your passwords too? Since I don't know of any battle tested (multiple very bad vulnerabilities exposed in public) password managers that offer this other than LastPass, I say check out the public opinion of that extension.
Yes I did (I didn't want to say it, disappointing most HNers).
I works for most of the major websites (Google, Amazon, etc. I think you can look them up). And also handles multiple google accounts pretty well, even when an google account is logged in, without logging it out. And it definitely doesn't works for the majority of the websites.
(And now for the skeptical ones)
I'd say use it for websites you use 2FA since any bug (or intentional backdoor) won't be successful.
PSA: If you're using LastPass for managing passwords, DONOT use their 2FA authenticator app, since now it offers an option to autofill option. Now that is the point where you're crossing into al eggs in one basket territory.
If you use a YubiKey then you can move tokens between devices without needing to trust a third party, nor worry about them somehow being exfiltrated from your phone.
I just have two, if you're doing strictly u2f they are less than $20. I have a nano4 and a neo that I use for u2f, oath tokens, and rsa keys for sign/encrypt/auth. It's not the cheapest setup but it's highly functional and about the best account security I could put together. I lost a gmail account for 45 minutes once and decided that would be much worse then the cost of the keys.
When I ran a CA, half of my root key to unlock the more sensitive keys was stored on an older Yubikey on a necklace and it never left my neck. That includes the shower and rolling over on it in bed. I couldn't make that thing fail, and arguably I wanted to based on how I treated it. (Back it up, though.)
2FA is a major inconvenience. The login process goes from 1-2 sec to 30sec. Sometimes a lot longer (some 2FA do not seem to think it is critical to send the email or txt msg right away, and even when they do, email servers do not really work real time, and then you have the time it takes to find your phone, unlock, decline twice the iOS update prompt, go to the right app, find the right msg, copy the code, check it is correct, etc etc).
Yeah if it is really a critical service and rarely used, we should. But if I have to wait 30sec in front of a login box every time I go on netfix or on amazon, you can bet their sales will go down the drain.
I have my 2FA in Notification Center and consider this fine given that it's second factor. With that, it's about eight seconds for me involving one slide of my finger. I'm also mystified that you think support for 2FA and mandatory 2FA are the same thing, particularly for something like Netflix.
I am not arguing about support vs mandatory. Just that I am not convinced 2FA is a compeling alternative. At least the way I see it implemented.
I like the idea behind SQRL, which still requires another device, so still inconvenient, but at least it does not rely on the server sending a message through a slow protocol. The website displays a QR code, you launch an app, scan the QR code, this app connects to the server and authenticate you through cryptography. No login or password to type, no message to wait for or to copy manually. No privacy concern since it does not rely on a third party. I could live with that.
2FA doesn't have to be done over email/SMS. Nearly all websites these days support Google Authenticator protocol enabling use of a wide race of app/devices (for example my Garmin watch) to produce the code. No need to wait for an email/SMS.
Most services have the option of remembering your 2FA authentication on a certain device. For example, I have to enter my LastPass password in my computer to login, but I only have to use 2FA if I'm logging in from a new device.
> some 2FA do not seem to think it is critical to send the email or txt msg right away, and even when they do, email servers do not really work real time
SMS isn't real time either, it's best effort. Mostly (~99,9%) it gets through within seconds, but delays of a few minutes are perfectly acceptable to telcos. As service provider you can't do much about it, either pay through the nose for "priority" delivery (which maybe halves the amount of delayed messages in our experience) or tell your customers to switch mobile providers (yeah, good luck with that).
As a service provider there is something you can do about it: Use well known out-of-band 2FA specs such as TOTP. Those are compatible with Google Authenticator and don't require a phone number, which is a massive inconvenience (not always available, not available in every country, SMS not reliable, requires an ID, not free, leaks personal information to the service provider, ...)
Well, yeah. We're not using SMS for 2FA, just for delivering monitoring alerts. With those reliability statistics (and the impossibility to improve it) I wouldn't do SMS-based 2FA at all.
We've found other interesting behavior in email-to-SMS services using it for alerts (this is in the US):
Verizon: will deliver all messages typically with low latency.
AT&T: Variable delivery latency and they have some sort of rate-limiting where if your system generates 10 alert messages within a short period, they queue them up for a couple of hours!
Inmarsat: Fast consistent delivery but they have an undocumented rate cap that when reached results in all (all!) messages being black-holed for 30 days. There is no way to reset this state. The cap is something 150 messages per month or 5 per 10 minute period.
> 2FA is a major inconvenience. The login process goes from 1-2 sec to 30sec.
That's definitely true, and it's definitely annoying. But one is not logging in every day (or even, I hope, every month: 90-day cookies are safe enough).
This does sound perfect to me. However I worry about losing a token without a established way to replace it.
For me I don't like staying logged into most services, I find it very uncomfortable that my computer "remembers" me for some reason. I use a browser plugin to delete cookies on tab close and don't save any history. I'm not so much RMS, just like my browser to "start fresh" most of the time. I also use a VPN 90% of the time.
So I value quick login more than account security, I guess.
I have to disagree with the Authy recommendation. I switched to Authy a few years ago, but it was nothing but painful and I have recently migrated away from it. For a long time the "TouchID Prompt" was slow and buggy, but that does appear to be fixed now.
The real pain point is that it managed to corrupt one of my keys (how??) and the app tries to get me to backup my keys to their servers with multiple popups (which I cannot disable) prompting me to backup every time I use the app. I don't know why they are so determined to get hold of my OTP keys, but it isn't happening.
I'm currently using an app called "OTP Auth" and it seems quite nice, and is quick to use.
a major advantage is if I throw my phone into the ocean(not a theoretical attack!) I can still recover my OTP on another machine. Authy offers this pretty nicely
I would recommend testing theories of :
- losing phone
- losing computer
- losing both
and have reasonable backup strategies for these scenarios.
I use Google's authenticator on my phone and a 50-line python script on my desktop PC. I store the OTPs in a JSON file and the python script runs them through the TOTP algorithm and spits out my 6-digit code on the console.
I'm less worried about losing my "computer" since I don't own a laptop, plus the secrets are backed up using my normal backup process.
Isn't that the point of having backup codes for Google, etc.? I can use those to restore my account, and secure them however I like.
Backing up the secrets to a third party makes them vulnerable to anyone who can hack your Authy account. I'm not sure what that requires, possibly hacking a phone number. Of course, there's also a backup password, but then you're just replacing the "physical" factor in 2FA with another password.
Without Authy, to compromise my account, you need physical access to my phone, my backup codes, or another backup mechanism I've specified. Authy just provides an additional way to compromise my account, and I don't think it provides any real benefit in exchange for that risk.
I also recommend authy. Makes 2fa slightly less painful.
Not a fault of authy, but namecheap and paypal both don't offer support.
I'm especially angry at namecheap because their homegrown 2fa solution is unreliable. Especially when travelling. I'm considering leaving them agter 4 years of promises to support authy but nothing!
Ugh, tell me about it. I check this page every now and then and just notice new comments and a response from Evgenia S. that the team is working on it:
FWIW, Gandi.net supports TOTP, but their prices are a bit higher. However if you only own a handful of domains, the $20/year difference won't really matter.
50% of the leaked hashes were bcrypt and the other 50% were salted sha1.
So, asking the HNers who crack passwords or follow the tech closely and have a good feel:
Salted sha1 can be brute forced much quicker, but in practical terms what kind of complexity of password is vulnerable today if it was stored salted sha1 vs bcrypt?
And how can this be projected to change in the next couple of years?
Mostly what Troy says is that the sha1 were salted with a salt not available in the files he was provided. That doesn't mean the salt wasn't leaked. But if it wasn't, and the salt was a 128bit, unique to each password, cryptographic random salt, I'd say they are not really vulnerable. So it depends on the strength, randomness and availability of the salt.
Uh oh. You might be on to something. Salts are pretty much always stored right next to the hash, right? If the hack doesn't contain them, maybe they were doing something "clever" like that.
I actually googled before asking my question, and couldn't come up with a good feel for just how crackable these are with hashcat... I guess I don't know the terms or the prices.
Is anyone able to make any sense of the GPU hashcat benchmarks that are posted? Something distilled down to "if you spend $xxx, then you can crack any salted sha1 under 12 letters+digits+punctuation in n hours if you knew the salt; if its bcrypt, that would take x hours". Something like that ;)
Added: I'm a bit confused how the attackers know the hash and not the salt though; normally they are stored side-by-side. Or were dropbox using a site-wide salt?
(I've seen systems with a site-wide salt hardcoded into the codebase and a per-user salt in the db with the hash; This means attackers have to compromise both sourcecode and db to get far.)
Hash can be stored somewhere else. I also saw systems where some kind of constant for the user was used as a salt. For example first 5 characters of username or timestamp of registration.
A rough estimate for using spot instances on EC2 says you can get maybe 40 trillion SHA1 hashes per dollar. (700MH/s and just under $.07/hour) So one dollar will crack a password 7 characters long. A million dollars will crack a password 10 characters long.
Switch to bcrypt and you're now at 25 million hashes per dollar on those same instances. Now you can barely crack passwords that are 4 characters long, or for a million dollars you get 7 characters.
That's if you know the salt, of course. Otherwise that gets added on to the length you're cracking.
None of this is very exact but it gets you in the right ballpark. And you can compare it to a password manager spitting out 20 character passwords that are completely immune to brute forcing.
Pro tip: Build your own GPU cluster out of consumer gear. It's orders of magnitude cheaper because GPUs for the data center are expensive and/or slow. Our commercial cracker is consumer gear in a custom built chassis in colocation. Cloud GPU just isn't there yet.
It depends how many rounds of sha1 were used and what was the load setting on bcrypt. You can make either one harder to break by playing with those parameters.
> My wife uses a password manager. If your significant other doesn't (and I'm assuming you do by virtue of being here and being interested in security), go and get them one now! 1Password now has a subscription service for $3 a month and you get the first 6 months for free.
How about...not? There are tiny open source tools for every OS. You can do it locally, save it on a stick or on your damn phone...why taking more risks especially facing this massive fail here?
It's not clear to me whether the grandparent is referring to self-hosting password management or file synchronisation. However, one obvious security advantage of self-hosting is that you can use end-to-end encryption (which most cloud sync services don't support).
E.g., I use Resilio Sync (formerly Bittorrent Sync) for file sync with encryption-only keys on my cloud peer. The cloud peer participates in the mesh, providing bandwidth, but if it gets hacked, no one can read the data.
(Of course, I would prefer an open source solution. SyncThing does not have the right sharing model for me. So I was thrilled to hear about LibreVault on HN, which provides functionality similar to BTSync 1.x: https://librevault.com)
Good job they changed their name. Couldn't get the product adopted in a corporate environment because of all the cries of "Witch! Witch!" when the suits saw the word Bittorrent in there.
Arguably, this leak seems to have been the result of password reuse. If you store your data with millions of people and 200 employees have a way to access it, your are exposed to
1. An interesting phishing target for a hacker
2. Lots of employees who can fuck up, a hacker only needs one, one time
I'd say the probability you will be hacked is probably less if you use like a Synology with a reasonably strong password and automatic system updates.
For me, that would be most probably both if I were serious. Less of a target of course (I'm only one dude), but also much less attack surface. Basically install a trusty GNU/Linux or Open BSD, set up automatic updates, and block everything but SSH. Oh, and disable password based logins —use a public/private key pair of appropriate strength.
Or better yet, ask actual security experts about that setup, they're likely to come up with something better (just as simple and more secure).
Exactly my thoughts and I'm not alone here. There is a growing attitude against cloud infrastructure which together with the industries hype for it will lead to a interesting clash at some point.
I hope this will bring out even more cloudless solutions in the future.
They are a company focussing on just one commercial product.
Also I find there's some kind of pride in quality amongst mac-developers.
Plus the lastpass vulnerability that was disclosed a couple of month ago seemed pretty basic and I haven't heard from serious vulnerabilities in 1password for a while.
There have been some articles about automatic KeePass updates being vulnerable. This section clarifies the situation and its resolution.
First of all, we would like to note that KeePass cannot update itself. KeePass does support checking for updates (optional; by downloading a version information file, comparing the available with the installed version number, and displaying a notification if necessary). However, it neither downloads nor installs any new version automatically. Users have to do this manually.
KeePass can be downloaded from many servers (SourceForge with its many mirror servers, FossHub, etc.). In order to make sure that the downloaded file is official, users should check whether the file is digitally signed (Authenticode; all KeePass binaries are signed, including the installer, KeePass.exe and all other EXE and DLL files). The digital signature can be checked using Windows Explorer by right-clicking the file -> 'Properties' -> tab 'Digital Signatures' (the expected signer name is 'Open Source Developer, Dominik Reichl'). When running the installer, the UAC dialog displays the digital signature information, i.e. users who carefully read the UAC dialog do not have to inspect the file properties separately. This is recommended for all users, independent of where you download KeePass from.
The KeePass website links to SourceForge for downloading KeePass. However, even if SourceForge (or the KeePass website) is compromised and serves a malicious download, users who check the digital signature will notice the attack and will not run the malware. Note that HTTPS cannot prevent an attack via a compromise of the download server; checking the digital signature does.
The version information file is downloaded from the KeePass website over HTTP. Thus a man in the middle (someone who can intercept your connection to the KeePass website) could have returned an incorrect version information file, possibly making KeePass display a notification that a new KeePass version is available. However, the next steps (downloading and installing the new version) must be carried out by the user manually, and here users who check the digital signature will notice the attack.
Resolution. In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-4096 and SHA-512). KeePass 2.34 and higher only accept such a digitally signed version information file. Furthermore, the version information file is now downloaded over HTTPS.
> They depend on selling their product to security-savy users
No they don't. They just need some good advertising and they can sell to people who didn't even know they need it (fear works very well here). Really tech savy users will just move on if they don't like something or won't even come in because it's not open source or because of data thrift. The untechy customer will stick to what he has.
On the other side: if there is just one company better then them, with better advertising they'll have to see how they can get money with just this product. There are many creative solutions out there. A sheer endless horizon of possibilities I don't even want to think about.
For me, it's that 1Password runs locally and doesn't need to phone home, whereas LastPass is "cloud". Also, LastPass being owned by LogMeIn doesn't sit right with me, but that's definitely personal.
No idea about Keepass(x), although I found that ecosystem to be confusing, with different apps for different platforms you might accidentally download a rouge one on e.g. your phone. I know, paranoia.
My mother is able to run keepass and she still has a problem with double clicking.
But sure. Looking for yourself is not easy. You have to do something for yourself and not just throw money on some company that is depending on this one product.
Not sure if your paranoia is directed the right way here though.
LastPass is only "cloud" in the sense that it takes the AES encrypted files your browser encrypts locally, then allows you to access them from multiple locations if you have the right pw (and 2 factor auth if you use it).
There have been some articles about automatic KeePass updates being vulnerable. This section clarifies the situation and its resolution.
First of all, we would like to note that KeePass cannot update itself. KeePass does support checking for updates (optional; by downloading a version information file, comparing the available with the installed version number, and displaying a notification if necessary). However, it neither downloads nor installs any new version automatically. Users have to do this manually.
KeePass can be downloaded from many servers (SourceForge with its many mirror servers, FossHub, etc.). In order to make sure that the downloaded file is official, users should check whether the file is digitally signed (Authenticode; all KeePass binaries are signed, including the installer, KeePass.exe and all other EXE and DLL files). The digital signature can be checked using Windows Explorer by right-clicking the file -> 'Properties' -> tab 'Digital Signatures' (the expected signer name is 'Open Source Developer, Dominik Reichl'). When running the installer, the UAC dialog displays the digital signature information, i.e. users who carefully read the UAC dialog do not have to inspect the file properties separately. This is recommended for all users, independent of where you download KeePass from.
The KeePass website links to SourceForge for downloading KeePass. However, even if SourceForge (or the KeePass website) is compromised and serves a malicious download, users who check the digital signature will notice the attack and will not run the malware. Note that HTTPS cannot prevent an attack via a compromise of the download server; checking the digital signature does.
The version information file is downloaded from the KeePass website over HTTP. Thus a man in the middle (someone who can intercept your connection to the KeePass website) could have returned an incorrect version information file, possibly making KeePass display a notification that a new KeePass version is available. However, the next steps (downloading and installing the new version) must be carried out by the user manually, and here users who check the digital signature will notice the attack.
Resolution. In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-4096 and SHA-512). KeePass 2.34 and higher only accept such a digitally signed version information file. Furthermore, the version information file is now downloaded over HTTPS.
I use them too, and like how they operate. They have the best update notes of any company I've seen (on Apple's App store) - enthusiastic, entertaining, detailed, consistent. None of this guarantees quality, but it certainly paints a picture of a committed team.
that's true, but 1p is far better than the open source options. it also has wifi sync between devices, so your fault never leaves your devices via anything but trusted, local connections if that's what you want
How is this "far better"? It's just some additional feature you've described here. I wouldn't need it. So it does nothing better for me as far as I can see it.
Dropbox is about the only service I use a memorable password for, as it has my 1Password file in it, which has my Google one-time-auth codes in it. If I lose my phone while on the road, only remembering my Dropbox password is going to get me out of the mess. Any sensible other solutions here? It's still ~14 characters, but other than making it more random, what are my options?
or a few extra characters you need to add. As much as people say this is a bad idea, most of the people you would be trying to keep out, don't have access to your wallet.
I did this for a few months for a master password and set everything to forget the password so I used it several times a day. After a little while I can get rid of the paper and have a LONG random password that is committed to memory.
And the average mugger most likely wouldn't know what to do with a long random string (or multiple). The bank notes next to them are much more interesting.
Though by now, I find this a little tedious. I'm thinking of using an encrypted password database, protected with a diceware generated password. That way I will be able to copy&paste my passwords instead of typing them by hand.
Use 2 factor authentication and rotate both passwords. I have the opposite setup - Dropbox password is random and the password manager (stored inside) is memorized. It would be harsh to lose access, but not unrecoverable.
All of my passwords are based on the website name that I'm logging in to. I have a small algorithm in my head about how to generate a password from the site name that looks at stuff like first and last letter, number of letters, some kind of prefix/suffix, etc. And I end up with a unique password around 20 characters that I don't need to remember for every website.
This way I don't ever remember a password, I just remember the system.
What can be better alternative? IMO using something like 1Password/Lastpass is less secure because it then only takes someone to get my master password to get all my other passwords.
Your master password shouldn't really be something that's going to be in either a dictionary, or brute forcible. Nobody is going to "get" it unless you make it insecure. If you're using their sync services, however (especially LastPass), you're more vulnerable to phishing attacks, and the vault can potentially be stolen and crack attempts run offline. However, both services use a heavy level of encryption that requires the passphrase to unlock, so as long as that's not dictionary based or brute forcible, you're totally fine.
In order to determine the algo have_faith is using, an attacker would probably need a sample size of at least 4 passwords from different sites (at least, my algo definitely would).
If an attacker has access to 4 of your passwords in plaintext, you have bigger fish to fry.
This is true. I don't think the system is obvious unless you had multiple passwords, on top of that it's not immediately obvious that there is a system in the first place from looking at the plaintext password.
When one of the sites you use gets breached, you'll want/need to change your password and won't be able to use the same single algorithm. This will throw things of as you won't be able to use a single algorithm. Sure you could not use two. But you'll need to remember what sites use which one.
How do you deal with websites that won't let you use >8char or certain characters?
I use this same method, but my method will often generate special characters, and AWS as an example, and several others (apparently following AWS' lead) won't let you use those. (Any punctuation not on the shift-numbers row of USA keyboards are not considered legit for password use)
I still mostly use this system, and given my lucky memory I can memorise the exceptions, but I doubt a vast majority of the population could follow my example.
I basically just have a system for altering the generated passwords based on the specific site requirements. For instance if it requires a max num of chars then I will just chop off the password at that amount. And similar systems for other requirements.
You can keep 1pass on an iOS device, and auth using fingerprint. Ultimately you're still going to need/want to know the actual underlying passwords to both iOS and 1pass, however.
Are 1Password's files not encrypted? Store it publicly on your web site, email it to your friends, print it out in base64 in a machine-readable font and keep copies pinned on the wall of your cube. You still have to remember one password but at least you're depending on crypto instead of Dropbox's security.
It was pretty obvious the dropbox hack was real several years ago, because lots of spam mail started arriving at my dropbox-unique email almost immediately after the breach. I changed my email to another unique address quickly back then. Unique-per-service email addresses work pretty well as a canary for breaches. Just make sure there is more uniqueness than just the service name to such addresses, or someone could see your pattern and start spamming by guessing popular services.
Except that the merchant still gets to see my credit card numbers (both sides). But it's how paypal works. The merchant only get an authorization code from paypal, and this code is useless to a hacker.
In the UK the numbers are printed on the receipt - part obfuscated on the customers copy, fully shown on retailer copy. So whilst the retailer may not touch the card they still get everything except the magic 3 digits.
Where I work you need the 3 digit security code and some address numbers (which you can make up) to properly process a transaction without the card.
Chip and PIN cards can support tokenization, which prevents the merchant (or anyone who has hacked the merchant) from seeing the card number, but they are not required to do so. I haven't seen any numbers on what fraction of cards use tokenization.
Something to keep in mind is that when chip and PIN was developed to combat credit card fraud it was card present fraud that was the big problem, either by someone using the stolen card itself at a brick and mortar merchant or making a counterfeit cart by writing the stolen number onto a blank card and using that at a brick and mortar merchant. Card not present fraud, where the number is used but not a card such as at an online merchant or a mail order merchant or telephone order merchant, was much less common.
Chip and pin made card present fraud much harder because it was much harder to obtain blank chip cards and the equipment to write a stolen number to them, and it made using an actual stolen card harder because of the PIN.
Chip and pin is not for online transactions, but in-store transactions. The merchant can see your credit card and would often manipulate it themselves.
I also use a Unique-per-service email address with Paypal, and I noticed that Paypal actually passes on that email address to the retailer when I pay with Paypal.
I receive order confirmation emails (from those retailers) and quite a few unwanted newsletters to my unique paypal address now.
I have no idea what Paypal is trying to achieve by passing on this fairly personal piece of data. I always have to enter a separate email address with the retailer anyway, and because of this scheme, those two of course never match.
>>>I have no idea what Paypal is trying to achieve by passing on this fairly personal piece of data.
For years the Paypal API sucked, and even today their are many companies that do not have full integration with paypal, so this is a way to match payment records as for 99% of shoppers the email address for the order/account will match the paypal email address.
Paypal is great at that kind of unintentional disclosure. Six or eight years back, because I liked what she had to say, I used it to donate to someone who was then speaking under a pseudonym as a result of some fairly credible threats. Imagine my surprise when, in the process of transferring funds, Paypal showed me her full legal name and domicile address in the UI!
Of course I let her know about it, and I seem to recall her saying she'd addressed it successfully, but if she described how, I no longer remember. It quite astonished me that this was even a thing that could happen, though. One hopes it no longer does.
It's been a while, so that might be true and I just don't remember, but it would be a surprising mistake to make for someone with a great deal of professional experience in operational security.
The fact that they publicize their 32-bit PGP fingerprint on their "security" page does not lend confidence in their security practices. Granted, there's also a link to the full PGP key, but the use of short fingerprints for any purpose should be verboten.
geez, privacy.com, I wonder how much that domain cost.
I'm using a card from getfinal.com, which appears to be the same idea. So far so good, though it's not 100% disposable, I still have a plastic card who's number is no easier to change than a chase card.
Hey! I work at privacy.com - would love to get your thoughts on our product. Hit me up at bo@privacy.com for an invite if you're up for it. I'll tell you how we got the domain :).
A Small Orange does this cheerfully, even for the smallest shared hosting plan. You can then go into cPanel to configure a catch-all account for the domain you're using.
Biggest downside to ASO: you have to pay $7/yr extra on domain registrations to make them private. So I register with Hover and host with ASO.
I use Google Apps for Work on my domain, which lets me forward all email to any address on that domain to my inbox. That way I can use adobe@ryanplant.net, github@ryanplant.net, fitbit@ryanplant.net, etc.
I do this exact same trick and have been using it for years. It led to a couple of brief and somewhat awkward phone calls with local business owners when I asked them rather pointedly about them sharing my information with third parties.
I also take this one step further and have inbox rules to automatically send all promotional email (from sites I'm interested in) to the trash folder. If I want a coupon for a website I frequent, I'll just search my trash for the latest offers from that company. Google conveniently purges messages from the trash folder every 30 days or so, and I don't have to worry about a massive backlog of promos.
Fastmail has a really nice subdomains feature - I have an alias in fastmail of 'shop@mydomain.com'. Any email for XXX@shop.mydomain.com gets delivered to shop+XXX@mydomain.com. Better than catchall, because all the spam gets sent to JohnSmith@mydomain.com, which is dropped.
The benefit it has is that the 'shop.' subdomain can't be guessed from the DNS records. I get a lot of spam to <randomname>@mydomain.com.
Of course, if someone sees my email address, they could certainly infer a new one. But I'll deal with that if and when I get singled out. I don't think the spammers often actually look at the millions of addresses they use.
If I start getting spam on a particular alias, I can set up filtering rules to delete them.
mailhero.io lets you set a username, then anything sent to *.username@mailhero.io is forwarded to an e-mail you choose. It's only somewhat an e-mail host at the moment (added a few weeks ago), and it has stated that the hosting is only temporarily free, but if you already have a host this can give the feature without requiring any form of migration.
Re: credit cards, unless you insist on using debit cards for some reason, who cares if they are compromised.
If someone steals my credit card, AMEX has a problem. I'll take reasonable care, but I'm not going to generate transaction specific numbers or whatever unless there is a strong incentive to do so.
I wish that it was much easier to generate temporary credit card numbers for all transactions. Like upon entering real number it would generate one and swap it for you.
Correct. My android pay says "a virtual number ending in xxxx was used to make this purchase." It would be nice if it was a token instead of an actual credit card number. I have no idea how is implemented.
Many had this feature (and Paypal for a while) but dropped it for some reason. My guess is they want to encourage subscription/repeat billing or some kind of fraud was rampant generating temporary numbers.
how so? when a card is fraudulently used to make purchases, AmEx is not refunding you from their own pockets. they take back the money from the merchant it was fraudulently spent with (a chargeback). no loss at all on their side.
not really, prices are based on market demand. the market does not care about fraud issues and such.
whatever the theoretical rise in price would be (due to the fraud), don't you think the merchant would price things at that level in the first place to make extra profit, if they could?
Because it's annoying to constantly get new credit card numbers. You have to update all your autopays. You can't get a new credit card instantly. Being denied due to fraud is embarrassing. You may be out of the country and stuck with a non working credit card. It's another thing to deal with.
Fine, "not traceable by arbitrary people on the Internet".
I know the credit card company and everyone they share your data with can see your transactions, and that's a problem some may wish to avoid, but that is still a much smaller number of people who can see your transactions than Bitcoin. Bitcoin does not inherently include privacy.
> Unique-per-service email addresses work pretty well as a canary for breaches
I do this too, but it taught me everything is breached - the local ambulance service, the local computer store, the local car share, small businesses overseas that I've placed orders with.
Some of the big names don't seem to be, which is lucky because otherwise I'd be wondering if it was the ISPs that had been breached. Either large chunks of SMTP routes are breached and picking up confirmation emails, or there's a giant iceberg of pwnage floating beneath the surface out of view.
I used to use unique middle addresses for magazine subscriptions, back when magazines were physical. I'd get credit offers with middle name "Byte". Consumer Reports used to include a false advertising hall of shame; I loved sending them an example sent to middle name "CR". They didn't use it, or even answer.
More likely, sold. Every service that collects user data will get offers, and many can't resist the temptation.
Doesn't matter however, businesses that will sell you to the highest bidder (and in many cases, outside the US, illegally) can't be trusted to ever seriously invest in security. So if they aren't breached, they sooner or later will be.
That has been my experience as well. Only one alias in about 10 years ever got undeniably sold, and that was because the company went out of business and probably sold their entire portfolio.
My experience also is that there is pretty limited sharing, even among business partners. The worst was when the idiots at Aweber, the email marketing service, were hacked, and I had waves of spam coming in on many per domain emails. Six months later, Aweber was hacked again. Another wave.
I don't have any fancy script to check these addresses - I have to go into my spam headers manually, and I've not done that for a long time. Perhaps there was a common issue a while ago that got patched. I'll have to check whether modern addresses are being spammed.
I got many Russian visas in my life in Europe and not once did i not use an intermediary. In Austria if you want to go thrrough the consulate you need to go through VHS first. In London VFS does it etc.
It's often called plus addressing. Quite a common feature in mail servers and mail services. MyName+<any-random-text> at gmail.com ends up in MyName's mailbox.
Doesn't that defeat the purpose? Surely anyone savvy enough to be dealing in black-market e-mail address lists is savvy enough to just remove everything after the + sign?
Probably yes. The software I'm using supports configuring the character per domain, so I can use say . instead of +, so I could use myname.service@example.com which I assume would solve that.
But not every website out there allows you to enter this as a valid email address.
My earlier hypothesis was that this was on purpose, to make sure you don't use a filter on any email they might send. But these days I'm tending to think it's just a bad regexp on their side.
Even worse, some sites let you enter a plus address initially but that address will not work in some account management pages. I had an instance where I signed up to a pizza place with such an address and I could not unsubscribe or edit my mail preferences because of it.
If you are just starting to do this...it's very easy to forget you did it for a particular site.
"I can't log in and to boot your site says there is no account matching first.last@gmail.com. What kind of Mickey Mouse operation are you running here?"
That's a solid point. I've generally avoided password managers because not knowing my (unique-per-service, strong) passwords makes me nervous in exactly the same way as not actually knowing the phone numbers of the most important N people in my life.
You'll get over that little hurdle once you realize that you can dump the anxiety of remembering a hundred password variants for different sites. And realistically speaking, you're probably not even using a hundred variants...or possibly even 10. If you're memorizing passwords, chances are your re-use frequency is nonzero.
What's important is to keep a backup of your password database in a few places. I use KeePass because I have no desire to keep passwords, encrypted or not, in a cloud service. I also don't find value in browser integration (possible attack vector?). I'm generally very DIY-inclined anyway. Your preferences may vary.
I guess you aren't familiar with KeePass. If your KeePass database is pwnd, that means your box has been pwnd since the database is stored locally and not any cloud provider (unless YOU put it there). This means you have much bigger problems and is not a shortcoming of KeePass, itself.
As a full disclaimer, there are some issues with KeePass [1], but known issues are detailed in full by the project and are available for review.
I use a catch-all (*@mydomain.tld), and forward everything to the same place. Really simple and I can just make up email addresses on the fly when I need to, no config necessary, and harder to reverse than the +addresses trick.
I have a wildcard redirect so that <anything>@mydomain.com is forwarded to me. That way whenever I sign up for a service I just use, e.g., dropbox@mydomain.com.
I used that practice, and ended up selling the domain. Updating everything was an absolute nightmare as a result, and I couldn't make a simple request like, "please forward my one primary email address to me for the next few years." YMMV :)
Personally, I worry much more about ad-hoc stalkers or angry people doing semi-manual digging. Such a scheme wouldn't help much. Does anyone know a convenient pipeline for managing (receiving, creating, disposing of etc) 3-rd party email accounts?
I use Fastmail, which provides very nice wildcard aliasing under a domain. *@mydomain goes to a single inbox. I can also create specific aliases such as foo@mydomain.
I also do unique aliases for each account I have. Few of them have been a source of spam.
I also have expiring subdomains. So I'm not using domain.com, but something like b2.domain.com. The rationale is that if I start receiving a lot of spam, I go through all the accounts I have, change all emails to use another subdomain like b3.domain.com, and then invalidate the old subdomain entirely. I haven't had to do that yet and my domain is several years old.
With two big exceptions: the email address I leave on my website and the email address I publish on my GitHub profile. These 2 have dedicated throwaway domains like throwaway283728@domain.com. Because you wouldn't believe how much spam I get from that GitHub profile, not just recruiters, but also get rich offers from princes in Nigeria and Viagra pills.
Back when I ran a mail server for a small business, I would see the spammers literally going through all the permutations of email addresses for a domain. In the logs you'd see:
That's a much smaller list than I expected. I don't differentiate between those that sold and those that ignore unsubscribe (and a few that just have very contrived unsubscribe systems), but I have over a hundred per-service emails attached to disabled accounts (as aliases) to block them forever.
One that stands out in my head is Cadillac. I had requested a brochure for a CTS, and I got random unrelated spam just days later!
Same here. I have (at the last count) over 200 website/service specific email aliases. I very rarely use an alias for more than one service. However when I do start getting spam on that alias, and I contact the website concerned they always state it's my fault. My response? If I can, I stop using that website or service.
My dropbox alias email started getting loads of spam about 2 years ago, I immediately junked that account, and set-up a new dropbox account (friends insist on sharing stuff over it...) - my old spammy dropbox alias is in the Dropbox leaked dump, my new current one isn't, which proves that this dump of credentials is from at least before 2015.
Is it necessarily service's fault? Could the e-mail address have been intercepted when some confirmation e-mail was being delivered? Not likely, I agree, but still...
I do the same, but some companies don't seem to be interested. I've had two different emails linked to a magazine's website and had spam to both.
When I've contacted them about it, they've been absolutely adamant that the spammer must have (twice) guessed the exact email address that I've had there.
You should report them to their country's data protection body. They are either maliciously selling your data against your explicit wishes or they've been hacked and are ignoring it.
I've had the same response. When I ask how come the spammer managed to successfully guess exactly the particular unique email address (including unique hashes appended to the service name as part of the username side of the address) on the first and only attempt (verified by looking at mail server logs), they just shrug.
unique-per-service email addresses sound indeed interesting. How did you set it up?
I am a google apps customer and already have a few 20 aliases in there but having to go through their UI every time I sign up seems very tiresome.
Can I create a wildcard email in the terms of service-*@bar.com being a alias of email foo@bar.com?
Do you know of a non-selfhosted provider that is able to do that?
/EDIT: Looks like fastmail, a service many on HN recommended is able to do something similar [0], though if one email gets added into a spam list, it seems to be not possible to remove one particular one.
/EDIT2: Fastmail just confirmed to be on Twitter that it is possible to set individual emails to rejected. Though this requires effectively creating a new alias and setting it to bounce which falls under the account limitations [1], so 600 for a single person account.
With Google Mail (and Apps) anything after a + in the first part of the address is ignored, so foo+dropbox@gmail.com would be routed to foo@gmail.com. That's the easiest way to do it that I know of. No need for managing separate aliases.
Whilst great info, unfortunately most of the sites that one would actually try to use this on don't accept addresses containing a "+" as valid.
Another Google Mail trick is to use periods. Not as useful as the +, but for those sites that don't accept +, one can usually add in a few extra periods to place sites into buckets (multiple adjacent periods don't work).
I don't think spammers look at individual email addresses. They're interested in 50 million emails, not you. I suspect the number of people using subaddressing is too small to notice. If it became popular enough that even computer illiterate people began using it, that's when it would be noticed.
Unfortunately vendor sites such as apple.com don't realize xy@g and x.y@g are equivalent and will let people register both. If you accidentally click approve on the confirmation email then good luck getting Apple to remove the second account. Which is how my wife gets tons of email from Apple about a stranger's iTunes purchases along with other random items.
If you control the email address that the stranger registered to their Apple account, you could initiate a password reset, change the password, then login and change the email address to something that's not yours.
You probably just locked the stranger out of accessing their account though, so you probably shouldn't do this, unless said stranger is signing up for all kinds of services using your email address, in which case maybe they deserve it. :p
For gmail, if you have someone@gmail.com, you can just append +anything to your address like this: someone+anything@gmail.com. It will still end up in your mailbox without having to set up anything. See https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-mo...
I would assume that google apps version of gmail offers something similar.
My email is handled by Google Apps for Business, and I just use e.g. dropbox@hemsley.cc or facebook@hemsley.cc - and have everything come to my real mailbox. Nothing to set up when I want to sign up for a new site. LastPass stores the different email addresses.
This works better than something+realaddress@gmail.com because many sites fail to handle/allow that 'format'.
I do this too. You get more spam with a catchall address, but Google get most of it. And there is no setup time lost with a new service - just use newservicename@yourdomain.com when signing up and you're away.
I used to use https://spamgourmet.com and was quite happy. You can create email addresses on the fly without doing anything in their UI: alias.number.account@spam gourmet.com. Alias is the per-site value, number is the count of emails you want to allow through before automatically routing the rest to /dev/null. I seem to recall an option to remove the numerical limit, too - once you trust the place you gave your address to.
Same here. It's free, it's incredibly easy to create new addresses, and so far (on the order of a decade) it's been trouble free for me. If you start getting spam any an address you just log in to spamgourmet, switch off the address and you're done. No send-this-plus-address filters to set up at your mail host, no subdomain tricks to fuss over, no need to create spam aliases on your Fastmail account. The only feature that I wish it had is the ability to view a log of where the spam was coming from for each address.
Yes but at the time, there was only evidence of password reuse leading to some comprised email lists... Not that password hashes themselves had been stolen. Sigh.
> Unique-per-service email addresses work pretty well
and they're so easy with Gmail - anything following a '+' character after your username (or alias, if using your own/company domain) will go to the same box, but keep the distinct address.
Unfortunately, depressingly many sites validate email fields, and get it wrong - thinking '+' is not allowed.
IMO it's not even worth trying to get an email regex (or other validation) right - you're probably going to send out an activation email anyway!
The trouble is that no one actually implements the email standard from the IETF RFC documents. In fact, some people[0] even actively discourage doing so, despite there being little in the way of good reason to not. The argument essentially goes "well, users aren't going to be likely to use those characters, unless they're doing something bad, and they make it difficult to insert the email into the database." I feel like that's a kind of laziness - we can fairly effectively remove that risk, and there are well tested tools to do so. But I do suspect that forbidding '+' is explicitly to avoid people using tagged emails. To be honest, the inconsistency in services allowing me to use '+' has caused me to just create a separate email for services that I don't have high trust for. Now no one gets my personal email, and I only check that one if I'm expecting something important.
Email RFC is weird. Did you know email addresses are supposed to be case sensitive? Like bob@ and Bob@ are two different addresses? Some services treat them this way, most don't. That intersection (oauth2 for example from Google can return Bob.Smith@domain.com if Bob has a GA4W account, which causes trouble when the oauth handler inconsistently lower-casifies input.
Really? By my reading RFC-5321 & RFC-5322 leaves interpretation of the local-part up to the software running on the host where the mail is delivered, but since that interpretation is up to those servers, intermediate servers must treat them as case sensitive and not make modifications to the local-part.
That's my interpretation, as well. The standard is for carriers, not mailboxes. As a carrier, (or someone sending an email) you should respect case, as well as respect all of the special characters, because the server is allowed full decision power over whether those things are meaningfully used.
I mean, there are good reasons laid out in that document.
"By RFC, email addresses are unique by mixed-case. Most (99.9+%) email systems do not treat email addresses as such."
Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.
You -should- treat email the way that vast majority of hosted services do. "Foo Bar"@gmail.com is not allowed. Covering the million edge cases seems to not be worth the trouble, especially when it might cause difficulty for the average user
> Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.
With smartphone keyboards and the capitalization of the first letter of the first word in form input fields by default, this is a very common occurrence. If case was considered for uniqueness of email addresses, at best, people would be extremely annoyed. At worst, there would be a tremendous amount of leakage of sensitive information to random people (due to human errors in entering case sensitive addresses), chaos due to incorrectly delivered emails and fatigue in receiving mails intended for thousands of other people. In an alternate universe where this is true, email would never have been a killer application, only a quickly killed and abandoned one. :)
Other services also let you use the alias as a subdomain: example@alias.gmail.com. Wish Gmail added that feature. Do they have any place I can sent a feature request?
Another feature of Gmail is you can place dots anywhere in your email and it will still reach you: ex.am.ple@gmail.com. I haven't seen services that reject that so it is what I use when I can't use a +.
I host my email with FastMail who allow the use of subdomains. This is a great feature, and I use it frequently.
HOWEVER, you should only do so after careful consideration. This will restrict moving your email hosting to the limited number of providers who provide provide this type of service, or hosting your own server.
Alternatively, you could go and reset your email address with all of the services that you gave a subdomain email.
For myself, I have been using FastMail for years and feel confident that I will continue to use their services. In the event that I needed to move from FastMail, I know that could self host if forced to.
I do the unique address thing, but I also have another system for giving out temporary email addresses. If I want to hand an email address which I know should not receive email after say, this Saturday, I'll just give them "2016-09-03@tmp.grepular.com" - I don't have to do anything to set that up, it will accept mail as long as the date isn't after 3rd September 2016. I blogged it up a while ago here:
Interesting. I've been considering doing this but, frankly, have been too lazy to implement it. But if you are using a password manager anyway, what's one more field?
Haha for me it's the opposite. My password never works in Dropbox. I think it's because they don't support spaces in passwords, but they don't tell you when you change your password. They just accept the change and then you can't login.
There are many sites with little exceptions like that. I think that their password filter allows the characters, but their backend input sanitization doesn't, so it cleans it up and inserts a transformed version of the pass without providing notification. I've found this happens particularly often with passwords with symbols like !, #, or ;.
In general, this is one of the most frustrating things with trying to secure yourself online. I have gone through like "I WANT TO USE PASSPHRASES" then gone to places like PAYPAL and had them have an upper limit on password length. It's absurd that they all have slightly different requirements. I am switching to a password manager now.
This problem has been noted for some time. Past articles on the subject have shown how the various requirements for passwords come about through a combination of limitations imposed by the system they're being used on, or through misguided attempts at making things easier for users.
I wonder if there has ever been an attempt through a forum like RFCs or ISO to define a worldwide (or at least latin char set) standard for password requirements. Based on what i've seen in forums like this, there seems to be fairly broad acceptance that allowing a large number of characters from a character set with as few limitations as possible bests serves the interest of security. The thorniest issue would likely be about balancing requirements for increased complexity (eg capitals and lowercase, numbers, etc) with ease of use.
Totally. You wanna talk about people forgetting? It seems everyone has totally forgotten (or forgiven) that Dropbox was mentioned specifically in the Snowden leaks as a source.
box.com is pretty good. I've personally used it for several years now and I can't recall the last time there was any real issue with it, usability or security-wise.
"Better" is subjective. I consider Google Drive much better, personally.
Alternatives, though? Plenty: Google Drive, Box, OneDrive, iCloud Backup and iCloud Drive.. the list goes on with a simple Google search for "online storage"
Does google drive work the same way as Dropbox? Cross platform, acts as a folder in your home dir, selective sync, etc? Seriously ready to move on from Dropbox and my google fiber account comes with a free terabyte of google drive.
The Windows and Mac clients create a folder in your home directory. There are ways to rename it, but essentially anything you put in the ~/Google Drive/ folder is synced just like Dropbox.
No native linux support is a bummer, but if you only need to use it there infrequently, the web client is quite capable for manual uploads and downloads.
if you are willing to use a rather more complicated system with harder setup, syncthing.net is great, it syncs files between your computers without needing a cloud service.
For more similar alternatives, running owncloud on a VM is straightforward. And, of course the featureset is limited compared to Dropbox.
I had big problems with OwnCloud. Specifically it ate files at work, but did so in such an insidious manner (slowly, over time, with no indication that anything was wrong) that I don't trust it to this day. I haven't checked lately, but the issue was acknowledged by OwnCloud devs, with the workaround being to "use a secondary sync application" (no kidding). These days I use Seafile, and I can also say that your suggestion of Syncthing is a good one. I have used and enjoy both Syncthing and Seafile. Just a word of advice: Don't trust Seafile to encrypt your data. Use Veracrypt (or equivalent) in place of the built-in "encryption" offered by Seafile.
They sent both me and my wife an email a couple of days ago regarding this, and have a Help Center page[0] for it:
Hi <first name>,
We’re reaching out to let you know that if you haven’t
updated your Dropbox password since mid-2012, you’ll be
prompted to update it the next time you sign in. This is
purely a preventative measure, and we’re sorry for the
inconvenience.
To learn more about why we’re taking this precaution,
please visit this page on our Help Center. If you have
any questions, feel free to contact us at
password-reset-help%dropbox.com.
Thanks,
The Dropbox Team
Change your passwords; especially if you use the same password for many things.
you're not alright, we have a way of knowing if that was your password or not and having unlimited tries with unlimited processing power, which means it's a matter of time before someone is able to guess their way into your accounts.
Can someone in the know indicate how to BEST manage passwords for different services in a secure way in 2016? Should I be using password managers (à la 1Password, LastPassword and others), or use something like Keychain Access on Mac OS X (what are the Windows equivalents?), anything else? It's important to note that not everyone is well-educated on the matter, despite the fact that most people on HN are technical people.
EDIT: Thanks everyone for your answers, this is a good example of the power of communities.
Password manager + two factor authentication whenever possible. As for the former: Opinions here differ but my recommendation would be not to trust a "cloud" password manager and employ an offline password manager instead. KeePass works great for instance and is open source and cross-platform.
While an offline password manager is inherently more secure, at some point you're either going to have to store the database on a cloud somewhere or worry about constantly keeping your databases in sync. Whether you store it in Dropbox/OneDrive/Google/etc. or use LastPass or another service, there's always going to be some risk.
At present I still recommend LastPass because that way you can easily have everything synced on your computers, phone, etc., and it's easier to convince people to remember one strong password and let LastPass handle remembering all the other strong passwords no matter what device you're on.
Sure, with an offline password manager backups and synchronization are up to you, but even if you end up relying on cloud storage it's a different story; for instance, if you store your KeePass database on a Dropbox account and said Dropbox account gets breached, at least you know that unless there's a flaw in the encryption algorithm used by KeePass, the password database cannot be decrypted without the master password (and brute forcing it should be very impractical if the master password is good enough).
If you use service like LastPass or 1Password you can never be entirely certain that a breach or a security flaw in any of these services isn't going to expose your passwords. I'm sure they use the proper encryption measures, but like the Dropbox breach shows, shit happens and companies get hacked.
I'm not saying never use a cloud password manager, but understand that the added convenience comes with added risk; I would definitely not make my company depend on them.
There's really not much of a difference between syncing via Dropbox (or similar products) and cloud services with the following characteristics:
- Client-side encryption, meaning the service has no way to obtain your cleartext passwords (short of planting a backdoor, which is a vector that applies to all password managers).
- Full offline support, with the ability to export your database. This becomes relevant when the service is down, you're running into billing problems, or if the company goes out of business entirely.
- Availability of a native client (as opposed to web apps or extensions that act as a thin layer on top of a web app). Planting a backdoor that leaks your secrets is significantly harder when you also need to compromise the vendor's signing key, as opposed to just breaching their web server and adding some JS file.
I just sync my 1Password via WiFi between my phone, work computer and personal computer. It's really not that much work either. Well worth keeping the vault of the internet.
Secure the password manager itself with a long password. Put your logins into it, and generate a unique random password for each one, then go to the website in question and change the password to the new one.
When you want to login to that website, open your password manager, copy the password to your clipboard and paste it in. Remove the password from the clipboard (Keepass does this automatically after about 10 seconds).
That is ALL you need to do. You could get into using keys, etc, to secure the password manager but if you have a long, unique password for the password manager, it shouldn't be necessary. I'm sure others can provide you with info on how to finesse the process using online password managers, etc, but what I've just described is the basics. Start simple, ramp it up later if you're the paranoid type (which you should be ;)
EDIT: Another thing, if you can use two-factor authentication, do it. I use this on my Google accounts, Paypal and my bank.
Another edit: You can store more in the password manager than just passwords. I keep a scan of my signature in there in case I have to put it into one of those (admittedly insecure) PDF-type forms to "verify" I've signed something. I also make up stupid answers to password hint questions and these also go in the password manager, e.g. "First school" -> "Dr Magnus Pike's School for Aspiring Arsonists". Too easy for people to work out what my real first school is called.
Yeah, I've been doing that same thing with security questions, except I just generate a new random password for each. I really wish that field was automatically blocked from view without the master password like the passwords themselves are when you toggle that (excellent) option.
Is Keychain Access from OSX a safe password manager?
Also, how comes all security-aware people trust 1Password and LastPass, even though they are not open source? Isn't that one of the rules of security, publish the source so we can trust it?
Another "rule of security" is that taking one step forward is better than nothing at all. So theoretically, a proprietary password manager could have a backdoor which could be used by the vendor or security services. But that's a relatively small group of people compared to "the whole world" which is where most people are with easily-guessed passwords which get reused everywhere.
Also, the idea that an army of trained security professionals is ready and able to scan open-source software for vulnerabilities isn't true - I think there was a study a few years ago which proved these security checks often didn't happen, people just assumed they did. The OpenSSH (secure shell) software was compromised for years and nobody noticed, and it is true open source and a critical part of people's systems as well.
You're looking to mitigate risks. A password manager is a step in the right direction. If you are truly paranoid (good for you) something like this, based on GPG, might be the right answer for you:
Personally I prefer not to use cloud-based password managers because I don't know what their backend security is like. But those more knowledgeable than me might say "they're fine" because of the way the encryption is structured.
>all security-aware people trust 1Password and LastPass
I don't think this is true at all. Many people do not recommend using these services for exactly that reason. Plenty of so-called experts make lots of compromises in their choices and recommendations for various reasons.
I really dislike password managers and there's good news: you don't need one to have unique password per site. A good password algorithm is very useful:
The article is dated. I'd suggest a longer minimum and 2 factor for services that support it. The advantage is unique passwords that you don't have to look up.
I used to do this before switching to a password manager; the problem with pattern-based passwords is that while in paper it sounds better than password reuse (unique passwords for each site/service while still being able to remember them, yay!) in practice you are still using the same pattern for all of them. A potential smart adversary could figure out the pattern used and then apply it to every site/service much like if the password was reused. E.g., if your facebook password is "j0hnf4c3b00k83", an adversary could easily guess that you are using a site/service pattern, and that your google password is "j0hng00gl383".
Of course, the pattern doesn't have to be that simple, but even if it were incredibly complex, at the end of the day you are still relying on one single pattern for all your passwords.
Right. But the idea does take advantage of the fact that some kinds of patterns are more obvious to humans and some to machines. Most people's threat model is a massive data breach rather than a determined single attacker focused on them who actually uses a smart human brain to analyze the passwords.
Exactly. If someone goes after you personally, they'd need several of your password (at least three or four) if you have a decent algorithm. Then they'd have to find that pattern.
Most password leverage comes from breaches and people running larger scale operations for scamming and spamming.
I use 1Password and I'm fairly happy with it. I also use dropbox for sync, since other methods suck. I didn't had a Dropbox account in 2012 so I'm not sure if I'm affected, but anyway, my 1Password chain should be secure even if stolen/accessed... That's what encryption is all about anyway.
I’ve always been under the impression the most secure and (technically) simple solution is to use the local system, like Keychain Access.
I wrote a small program that generates a list of random passwords. I just open terminal and type password, then copy/paste one of the outputs and allow Keychain Access to remember it. I do this for every service, the only manual password I use is for my actual computer, which is rotated periodically. You’ll need to manually backup your keychain file though.
Recently I had received an email from Dropbox asking me to change my password and now I read about the hack , I wonder if there is any correlation here.
Make sure you sign yourself up for something like https://haveibeenpwned.com if you haven't already. Sometimes being timely in responding to leaks can make a big difference on any further leaks.
Can't upvote hard enough. Also, it is shocking how bad security is for all these games I've played over the years. The publishers seem to be the source of the vast majority of these leaks I've been caught in.
Thankfully the notification emails from this service are prompt and helpful (not to mention totally free).
Also, LastPass uses a similar site, plus it's specific knowledge of your passwords (last time it was changed), to let you know if a password has been compromised.
Not sure if 1Password does as well, but it seems like a fairly obvious feature to add.
1Password has a "Watchtower" feature that "identifies websites that are vulnerable to Heartbleed". Also under Security Audit are sections for Weak Passwords, Duplicate Passwords, and groupings of password ages (3+ years old, 1-3 years old, 6-12 months old for me). It does not appear to keep track of leaks/hacks.
The problem with this feature seems to be that it thinks if the site reissues its certificate it means all passwords there were compromised. Which leads it to mark all old passwords as vulnerable, even if no breaches were actually reported for the site.
The certificate/password link is a guess since on their website they say to change the password starting with date that matches the date of certificate reissuance.
This seems to be related to Hearbleed, also it lists a site that didn't reissue certificate after Heartbleed as vulnerable too, and so for passwords there, seems to be regardless of age.
I am a long-time 1password user and have a lot of old passwords, so for me like 90% of passwords are listed as compromised, which I'm pretty sure is not the case.
I'm not sure how much I can trust the results of a site that claims an email address I only use for one site has been breached on sites and services I've never been to. However it's calculating if what you enter into the form appears in the leaked content sure gives a lot of false positives.
Which I suppose forces more awareness, but it doesn't instill a lot of confidence.
A false positive from your perspective doesn't mean your email address isn't actually being used to sign up for things.
My primary personal email address is routinely used by a small handful of other real people (all strangers) for all sorts of things - college applications, car insurance, some address books think it belongs to a cousin who gets included in a lot of group threads about reunions and full of photos. I've found the families more difficult to unsubscribe from than the services, name+email associations spread like a virus. I routinely get alarming/misleading "Someone has your password!" security alerts from Google after someone tries to list my email as a backup account.
These little strings we use to identify ourselves can be typed by anyone, anywhere, bot or human. I wouldn't worry too much about false positives.
It's not that I'm worried, it's that it's a distraction. When the margin of error is high enough, it becomes less signal and more noise, which leads to either panic (spending all your time managing access credentials) or complacency (ignoring the indicators).
Why do I see my username as breached on a service I never signed up to?
When you search for a username that is not an email address, you may see that name appear against breaches of sites you never signed up to. Usually this is simply due to someone else electing to use the same username as you usually do. Even when your username appears very unique, the simple fact that there are several billion internet users worldwide means there's a strong probability that most usernames have been used by other individuals at one time or another.
Its worth pointing out that other people can use your email address to create accounts. It's just a string of characters to type in.
They might not even know it's yours, like if your email is davidsmith@gmail and they fat-finger davidrsmith@gmail--boom, "you" now have an account.
Good services use double-opt-in to ensure that every account is actually tied to a correct and working email address. But not every service does this.
And even services that do use double opt-in would create a row in their database to note that a confirm email was sent out. If they never scrub those invite rows, "your" email address would still be in the DB when it's exfiltrated, even if the confirmation process was never completed.
Fun fact: Have I Been Pwned neither salts nor hashes the creds which it stores on its website, potentially making itself an interesting target for hackers[0]
I think it should hash entered email client-side in JS to be more trustworthy.
I am a bit worried about giving my various email addresses to some random site.
Ironically, https://haveibeenpwned.com certificate is signed by StarCom, which is the same as WoSign https://news.ycombinator.com/item?id=12411870 which means it basically trusts a known scammer to provide its security and one should not be giving this site any information you don't want to see in public.
If find this just interesting that just last week my steam account was successfully logged in from Russia (I'm in the UK). Looks like I forgot about Steam to make my passwords stronger.
> As for Dropbox, they seem to have handled this really well.
I'm biased, but I can't agree with this. From what I can tell, there are two communications from Dropbox -- one in 2012 [1] and one last week [2].
In 2012 they did not disclose that hashes were stolen, so I don't see how it's really relevant. In the latest communication, they don't actually explain the risk to the user. They say it is "purely as a preventative measure" but if salts and hashes were accessed, then that is not the case.
Just because Troy doesn't have access to some of the salts, doesn't mean the attacker doesn't have access. We don't know how many iterations of SHA-1, but SHA-1 can be run by a single GPU on the order of billions of times per second. So unless Dropbox is coming out and saying they know for certain that random 128-bit salts were definitely not accessed by the attacker, almost all of the SHA1 hashed passwords are getting cracked. Users need to know their passwords are exposed, and must be reset not as a preventative measure, but because they are almost certain to be compromised.
As for the salted/bcrypt passwords, we can see from Troy's hash they used $2a$08$ which is bcrypt with a cost factor of 8 -- 2^8 iterations. Gosney's latest rig [3] could crack these bcrypt hashes at about 105,700 / 8 = 13,212 per second. That's not terrible, but that's still 416 billion tries in a year for a modest investment.
> > As for Dropbox, they seem to have handled this really well.
> I'm biased, but I can't agree with this. From what I can tell, there are two communications from Dropbox -- one in 2012 [1] and one last week [2].
Especially given that 2012 they assured me that no credentials were lost and this time they didn't even inform me since my account was deleted in the mean time. So it's more or less luck that I know that my old password was compromised.
>> "Users need to know their passwords are exposed, and must be reset not as a preventative measure, but because they are almost certain to be compromised."
This should be assumed regardless of what is known if it's know a breach happened; meaning basic password hygiene should be followed, and I'm the case of Dropbox, if a user had any plaintext files with passwords to other accounts (yes, people still do this) - they need to change those passwords too.
Right, but you're assuming optimal response from every Dropbox user, when I'd assume the vast majority of Dropbox users aren't aware of best password practices (or are aware and only change passwords when forced anyway because 'I have nothing to hide'). The severity of the breach means Dropbox should be forcing password changes. I didn't even receive an e-mail notifying of the breach. Nothing in the spam filters, it's just not there. The only reason I'm aware of it is Troy Hunt, and the only reason I'd ever be aware of it is that. I was getting ready to leave dropbox anyway, this just reasserted that it's the correct decision.
Honestly, I've found security bugs in Dropbox using it (oddly) as designed in the past and would never use it again; basically, as a non admin I could become an admin in a business account; reported the issue, had a call with them and it appeared they fixed it, but still it was a wtf moment for me given if you're an admin you are able to permanently delete all the data and according to Dropbox the data would not be recoverable regardless of the time frame.
As for the average user, to be honest at the point I increaslying feel like people are responsible for their own security and if you that concerned a service won't notify you of a breach or make a mistake that to you is unforgivable — don't use them. Reason I take this position now is because increased you feel like all the hand holding related to security is dangerous long-term.
I agree that, ultimately, the only person who really cares about your security is you. That is certainly where the buck stops, and if a service has security you don't agree with stop doing business with them.
However, a forced password and session reset on accounts whose credentials have become public knowledge isn't "hand holding." It's SysAdmin101. It should be the first thing you do. Unless I'm misreading you, the stated stance is "Anyone using dropbox got what they deserved," but not everyone has the knowledge to perform a security audit. The user is not without blame or having made mistakes, but Dropbox isn't taking ownership of their own mistakes or being transparent to every affected user about what those mistakes were and/or led to. If they want to be a service that does hand-holding, they can give the correct advice. If they don't, they NEED to be transparent about what occurred and what information was released or the onus is entirely on them. Right now, they're doing neither. I think that is criminally negligent, though I'm certain no legal action will be taken.
I feel that lowering those expectations of a service only helps justify these shitty, lazy practices to others.
The only thing that would've been exposed in the breach relating to me are the e-mail address and password for that service itself (alongside all the crappy memes I stored there), but I'm not ready to watch the world burn from the sidelines. The security of others is just as much your personal security, and the more of it others sacrifice the more you'll be expected to do the same and suffer repercussions for not doing so.
I don't remember the details, but I remember that it was really awful how they handled it back in 2012. Really thought about dropping them (small pun intended). I am very happy to see that they got better, but am still a little sceptical.
The email they sent out completely neglects to mention that there was a breach unless you follow a link:
"We’re reaching out to let you know that if you haven’t updated your Dropbox password since mid-2012, you’ll be prompted to update it the next time you sign in. This is purely a preventative measure, and we’re sorry for the inconvenience.
To learn more about why we’re taking this precaution, please visit this page on our Help Center. If you have any questions, feel free to contact us at password-reset-help@dropbox.com"
Horrible communication, much more important than to force a change on the site itself is to say to all users: look, your passwords are at risk, if you reused them change them now. All that in a way that non-techies can understand. Else we can all just wait for the millions of compromised accounts.
What really bothers be about this is that Dropbox hasn't bothered to reset the sessions. Even after I manually reset my password (which I wasn't prompted or forced to do btw), all my apps (iPhone, desktop etc) that have existing sessions wasn't expired. So for all I know, a hacker might already have an open session to my Dropbox and changing the password will not fix that
Clarification edit: I did receive the e-mail from Dropbox letting me know that I should change my password, but when visiting dropbox.com I was already logged in and wasn't prompted to perform the pw reset
You can see all the existing sessions and authorised applications from their website. It is not perfect and it is extra work to go through those and delete them, but at least there is a way.
I'm a lead at Syncplicity, a prominent competitor. Early in my career at Syncplicity I changed all of our desktop clients to use long-lived sessions that do not reset when the user's password is changed.
For us, this is deliberate for a few reasons. Most of our customers authenticate via their employer's SSO (single sign on) and do not use any Syncplicity password management. We also do not believe that routine password maintenance should force someone to run around and re-authenticate all their computers. (Like Dropbox, a user can log into our web site and remove computers from their account.)
I do understand the argument that a password change should force a re-authentication on all clients; but I don't think it's the right approach. Changing a password is reactionary and preventative. An email notification will inform a user that his or her account is compromised.
Maybe one could add a checkbox to allow users to do that when they want to. My Skype password was recently hacked and I'm very very happy that I could via one command logout all the clients. Sometimes it's a feature you really really want to react fast.
I recently unlinked all my Dropbox sessions that were older than one month, which was a staggeringly high number to tell the truth. It would have been nice (and faster!) to have had a "panic button" that let me unlink everything all at once and only relink the things I needed to relink.
Indeed. I would really love to recommend Keepass, but their website is really ugly and makes the impression of a non-polished software - even though Keepass is absolute mature and fine.
On the other hand, the PuTTY website is also everything but polished, but people have always been using it. Also, I suspect that most people will get it through the third-party site "www.putty.org" instead of the real PuTTY website, whose URL is as complicated as: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h...
I don't think it's ugly -- just dated. Isn't it weird that mentally we trust software less if they have a dated website? Shouldn't it be the opposite? (As in: a dated website means this software is mature and tested?)
The problem with dated websites is that they have the appearance of being thrown on the web in 10 minutes and forgotten about rather than being mature and tested.
If the software is well supported and maintained than the website should be too.
Isn't the mentality more to do with insecure sites having dated websites with misleading links etc. Unless its a known company a dated/poor website often flags warnings for me about security, support for the product and more.
You know what always gets me: PuTTY's website isn't served over HTTPS. That software everyone downloads to type all their firewall and router credentials into... is from a website not served over HTTPS. I see the download and signature links are, but if I could have this non-HTTPS website offer up different links to your web browser...
The downloads are all GPG-signed, so that shouldn't be an issue. You have the issue of the initial trust, but that applies to HTTPS too to a lesser extent.
How many people do you think download the application, then check the signature? Additionally, if you can spoof the download link on this HTTP page, you can also spoof the signature link, and provide a fake signature matching your malicious package.
Frankly, about the same number of people as the number checking the HTTPS certificates are as expected. GPG does have the advantage though that once the public key is known and trusted, the package can't be tampered with on the server. (Authenticode might also work, but then you're back to trusting all the CAs that Windows does.)
It absolutely blows my mind that people are okay with giving their passwords (encrypted or not, see this very breach for why that's not always enough) to a 3rd party, but are not okay reusing a password somewhere.
If 1Password ever got owned, the Internet would be severely fucked.
And to stem the potential flood a bit, I realize there are plenty of good counterargument built up over the years to try and combat this general idea, but fundamentally the concept of giving your password to someone else to manage is still a confounding idea, regardless of whatever points those arguments make.
> It absolutely blows my mind that people are okay with giving their passwords (encrypted or not, see this very breach for why that's not always enough) to a 3rd party
That sounds more like LastPass than 1Password, although I haven't looked at the new subscription offering.
Which does not change the parent post's point, that with LastPass you're still giving it to a 3rd party who could leak that information for brute forcing.
That's a really unhelpful comment. Please specify what encryption you think Dropbox is doing on the passwords and what knowledge you have on the topic.
I'm pretty sure you're going to say "they do TLS" and then the person you're talking to can go ahead and explain that the encryption LastPass/1Password does protects an entirely different threat model, but unless you have a conversation here no one is going to be able to communicate a thing.
To be clear, I don't owe you or anyone anything with regards to this conversation. I am not obligated to conform to any particular conversational strategy, and if my intention was to simply claim something was incorrect without elaborating, I am entitled to do so.
That said, I was wrong. I recalled what bcrypt does incorrectly.
A great example was the recent Opera browser sync hack. Everyone who uses it has to change ALL of their passwords everywhere. Password managers are a TERRIBLE idea, and it's kinda sad so many security researchers recommend them. Single point of failure is a really basic concept to understand.
Password reuse has been slightly overblown as a concern. Things like your Google, GitHub, TeamViewer, bank, etc. accounts should always be unique. But if someone hacks your password for the Engadget forums or something, does it matter that they can now log in to your Kotaku commenting account? REALLY? People talk about how they have hundreds of accounts and could never remember passwords for all of them, so need a password manager... but in reality, only a few of those accounts actually matter.
And you're better off leaving a piece of paper with passwords on it by your desk than using a password manager. The likelihood of a digital hack of a password manager is infinitely greater than the likelihood of someone breaking into your house to get your passwords (instead of like... just taking your TV).
The majority of cloud-based password managers perform encryption client-side. A server hack would leave the attacker with random garbage. Short of brute-forcing your master password, they're not likely to get anything.
The only real concerns here are weak crypto and backdoors. If your threat model includes backdoors planted by software vendors you trust, not using a password manager won't help you, since someone might as well just backdoor your browser and get your brain-managed passwords as you type them. I'd stay away from webapp-based password managers, as planting a backdoor is typically easier for these.
Weak crypto is a hard problem, so you'd have to do some research and check whether the format your password manager uses has been vetted by the crypto community.
Looking at the vectors that are most commonly used to hack people today, I'm certain that password managers would be a massive improvement compared to the short and re-used passwords the majority of users use today.
1Password only recently added a service which syncs your vault with them. I use 1Password with a vault that exists only on my encrypted MBP. If my laptop is decrypted and my 1P vault is decrypted then yes I'm screwed. What's the alternative exactly?
To be more direct, I'm suggesting the standalone native application may not completely correctly implement the encryption algorithms. I have no evidence of this, but the concept still concerns me.
That's not what you said. You said that if someone owned up 1Password, the whole Internet would be in trouble. But that's like saying that if someone owned up one of the OpenSSH developers, the Internet would be instantly vulnerable. A false statement.
It's a true statement, not a false one. If someone was able to release an intentionally vulnerable version of OpenSSH/1Password, people who updated would be "instantly* (your word) vulnerable.
I used KeepPass for a number of years and it's a fine piece of software. To solve the problem of access on multiple devices and keeping it in sync I kept my password database in Dropbox. It works reasonably well but you often run into "lock conflict" issues when it is open from multiple devices, fine if it's read-only but I always felt uneasy when making changes.
A few months back I switched to LastPass and although it's GUI takes some getting used to, I was able to import everything from KeePassX into it easily and de-dupe it.
It even has 2FA support via Google Authenticator so it's convenient.
There are also apps for Firefox, Chrome and Android (phone and tablet) so I forked out for a Premium license and I'm pretty happy.
You can get it to generate passwords for a new site, no fear of using the same password in multiple places and LastPass will warn you if that happens.
You should probably audit the list and disconnect any you don't recognize, but you should probably be doing that periodically anyway with everything...
556 comments
[ 2.2 ms ] story [ 576 ms ] threadI highly recommend Troy's HIBP service, hiding your e-mail from showing up in public searches (important for opsec), and donating whatever you can to Troy. He's doing excellent work. This is the first time it's notified me and it was great, because I completely forgot I signed up. I appreciate a service that low maintenance.
HIBP is a truly essential service and I'd be happy to pay more. Even with good password discipline it's useful knowledge on your exposure and I cannot recommend it enough. He mentions it near the end but this is one of those no brainers that should be repeated very loudly.
https://haveibeenpwned.com
I changed my Dropbox password last week after they sent the email, same with LinkedIn.
Great site though
It was a complete nightmare unless you understood what public key crypto is, how it works, and how to configure your browser for it.
Don't get me started about having to move your certificate/keys around.
It doesn't work for the masses.
I don't know how feasible it would be to replace passwords for the general public, but if browser vendors were actually serious about security, they could go a very long way towards making client certs feasible just by giving up on their current strategy of putting their fingers in their ears and pretending it doesn't exist.
I recommend Authy as your 2FA app, as it lets you set a backup password, which you can use to move your 2FA tokens between devices.
For your critical services, keeping encrypted copies of your backup codes is a must.
A canary of chrome did have the ability to generate random passwords, but password management in chrome is still a pain IMO. Not sure about FF, but a quick google suggests it doesn't generate random passwords automatically.
People use other managers for many reasons: storing passwords (and other secrets) which aren't used on a site, using them on different browsers (say, Safari on the desktop and Chrome on mobile) and lack of trust on the browser's password manager.
Also, for a long time, browsers didn't save passwords with forms marked with autocomplete=off.
https://blog.lastpass.com/2014/12/introducing-auto-password-...
I works for most of the major websites (Google, Amazon, etc. I think you can look them up). And also handles multiple google accounts pretty well, even when an google account is logged in, without logging it out. And it definitely doesn't works for the majority of the websites.
(And now for the skeptical ones) I'd say use it for websites you use 2FA since any bug (or intentional backdoor) won't be successful.
PSA: If you're using LastPass for managing passwords, DONOT use their 2FA authenticator app, since now it offers an option to autofill option. Now that is the point where you're crossing into al eggs in one basket territory.
A successful attack would require both an Authy breach and that the attacker have passwords for the services that they want to compromise.
This should buy you enough time to regenerate your 2FA tokens to mitigate the threat.
Note: Dropbox also supports U2F for 2FA, which provides much better protection agains phishing.
https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
https://www.yubico.com/
I have one on my keychain, never an issue in years, but I can't help but be concerned, one day, I will be locked out...
Yeah if it is really a critical service and rarely used, we should. But if I have to wait 30sec in front of a login box every time I go on netfix or on amazon, you can bet their sales will go down the drain.
I like the idea behind SQRL, which still requires another device, so still inconvenient, but at least it does not rely on the server sending a message through a slow protocol. The website displays a QR code, you launch an app, scan the QR code, this app connects to the server and authenticate you through cryptography. No login or password to type, no message to wait for or to copy manually. No privacy concern since it does not rely on a third party. I could live with that.
Duo is the counterpoint to 2FA being cumbersome.
SMS isn't real time either, it's best effort. Mostly (~99,9%) it gets through within seconds, but delays of a few minutes are perfectly acceptable to telcos. As service provider you can't do much about it, either pay through the nose for "priority" delivery (which maybe halves the amount of delayed messages in our experience) or tell your customers to switch mobile providers (yeah, good luck with that).
Verizon: will deliver all messages typically with low latency.
AT&T: Variable delivery latency and they have some sort of rate-limiting where if your system generates 10 alert messages within a short period, they queue them up for a couple of hours!
Inmarsat: Fast consistent delivery but they have an undocumented rate cap that when reached results in all (all!) messages being black-holed for 30 days. There is no way to reset this state. The cap is something 150 messages per month or 5 per 10 minute period.
That's definitely true, and it's definitely annoying. But one is not logging in every day (or even, I hope, every month: 90-day cookies are safe enough).
That's not such a high penalty so that devices you've physically used are authorized and all others aren't.
I don't turn on 2FA because it's a pain in the ass. I want to like it but the extra annoyance isn't compelling enough for me.
It's hard to make a strong recommendation without knowing where on the scale of 1 to RMS you are...
[1] https://www.technologyreview.com/s/531926/a-physical-key-to-...
For me I don't like staying logged into most services, I find it very uncomfortable that my computer "remembers" me for some reason. I use a browser plugin to delete cookies on tab close and don't save any history. I'm not so much RMS, just like my browser to "start fresh" most of the time. I also use a VPN 90% of the time.
So I value quick login more than account security, I guess.
The real pain point is that it managed to corrupt one of my keys (how??) and the app tries to get me to backup my keys to their servers with multiple popups (which I cannot disable) prompting me to backup every time I use the app. I don't know why they are so determined to get hold of my OTP keys, but it isn't happening.
I'm currently using an app called "OTP Auth" and it seems quite nice, and is quick to use.
I would recommend testing theories of :
- losing phone
- losing computer
- losing both
and have reasonable backup strategies for these scenarios.
I'm less worried about losing my "computer" since I don't own a laptop, plus the secrets are backed up using my normal backup process.
Backing up the secrets to a third party makes them vulnerable to anyone who can hack your Authy account. I'm not sure what that requires, possibly hacking a phone number. Of course, there's also a backup password, but then you're just replacing the "physical" factor in 2FA with another password.
Without Authy, to compromise my account, you need physical access to my phone, my backup codes, or another backup mechanism I've specified. Authy just provides an additional way to compromise my account, and I don't think it provides any real benefit in exchange for that risk.
That's the idea for using Authy.
https://blog.agilebits.com/2011/09/23/two-factor-or-not-two-...
Not a fault of authy, but namecheap and paypal both don't offer support.
I'm especially angry at namecheap because their homegrown 2fa solution is unreliable. Especially when travelling. I'm considering leaving them agter 4 years of promises to support authy but nothing!
https://www.namecheap.com/support/knowledgebase/article.aspx...
FWIW, Gandi.net supports TOTP, but their prices are a bit higher. However if you only own a handful of domains, the $20/year difference won't really matter.
So, asking the HNers who crack passwords or follow the tech closely and have a good feel:
Salted sha1 can be brute forced much quicker, but in practical terms what kind of complexity of password is vulnerable today if it was stored salted sha1 vs bcrypt?
And how can this be projected to change in the next couple of years?
Just because there is no obvious salt now doesn't mean it's not there. Only Dropbox knows how it worked at this point.
See hashcat docs and benchmarks for complete answers to your questions. The GPU versions of hashcat.
Is anyone able to make any sense of the GPU hashcat benchmarks that are posted? Something distilled down to "if you spend $xxx, then you can crack any salted sha1 under 12 letters+digits+punctuation in n hours if you knew the salt; if its bcrypt, that would take x hours". Something like that ;)
Added: I'm a bit confused how the attackers know the hash and not the salt though; normally they are stored side-by-side. Or were dropbox using a site-wide salt?
(I've seen systems with a site-wide salt hardcoded into the codebase and a per-user salt in the db with the hash; This means attackers have to compromise both sourcecode and db to get far.)
Switch to bcrypt and you're now at 25 million hashes per dollar on those same instances. Now you can barely crack passwords that are 4 characters long, or for a million dollars you get 7 characters.
That's if you know the salt, of course. Otherwise that gets added on to the length you're cracking.
None of this is very exact but it gets you in the right ballpark. And you can compare it to a password manager spitting out 20 character passwords that are completely immune to brute forcing.
Do we know for sure these were "salted SHA"? It could well be "SHA1-HMAC through an HSM", and thus, actually be the stronger option.
Alternatively, someone has probably kept a lot of cracked passwords to themselves.
> My wife uses a password manager. If your significant other doesn't (and I'm assuming you do by virtue of being here and being interested in security), go and get them one now! 1Password now has a subscription service for $3 a month and you get the first 6 months for free.
How about...not? There are tiny open source tools for every OS. You can do it locally, save it on a stick or on your damn phone...why taking more risks especially facing this massive fail here?
Because you can secure it better than them? Or because you'll be less of a target?
E.g., I use Resilio Sync (formerly Bittorrent Sync) for file sync with encryption-only keys on my cloud peer. The cloud peer participates in the mesh, providing bandwidth, but if it gets hacked, no one can read the data.
(Of course, I would prefer an open source solution. SyncThing does not have the right sharing model for me. So I was thrilled to hear about LibreVault on HN, which provides functionality similar to BTSync 1.x: https://librevault.com)
Good job they changed their name. Couldn't get the product adopted in a corporate environment because of all the cries of "Witch! Witch!" when the suits saw the word Bittorrent in there.
https://en.wikipedia.org/wiki/ΜTorrent#Ads_and_malware
1. An interesting phishing target for a hacker
2. Lots of employees who can fuck up, a hacker only needs one, one time
I'd say the probability you will be hacked is probably less if you use like a Synology with a reasonably strong password and automatic system updates.
Or better yet, ask actual security experts about that setup, they're likely to come up with something better (just as simple and more secure).
I hope this will bring out even more cloudless solutions in the future.
Also I find there's some kind of pride in quality amongst mac-developers.
Plus the lastpass vulnerability that was disclosed a couple of month ago seemed pretty basic and I haven't heard from serious vulnerabilities in 1password for a while.
And that 1Password is local.
All of that is just a feeling though, of course.
Or: "they are a company depending on just one commercial product".
Doesn't look that good anymore hm?
Try keepass for excample. It's local too and it's open source.
This fact alone make me lose all trust in it's developers.
First of all, we would like to note that KeePass cannot update itself. KeePass does support checking for updates (optional; by downloading a version information file, comparing the available with the installed version number, and displaying a notification if necessary). However, it neither downloads nor installs any new version automatically. Users have to do this manually.
KeePass can be downloaded from many servers (SourceForge with its many mirror servers, FossHub, etc.). In order to make sure that the downloaded file is official, users should check whether the file is digitally signed (Authenticode; all KeePass binaries are signed, including the installer, KeePass.exe and all other EXE and DLL files). The digital signature can be checked using Windows Explorer by right-clicking the file -> 'Properties' -> tab 'Digital Signatures' (the expected signer name is 'Open Source Developer, Dominik Reichl'). When running the installer, the UAC dialog displays the digital signature information, i.e. users who carefully read the UAC dialog do not have to inspect the file properties separately. This is recommended for all users, independent of where you download KeePass from.
The KeePass website links to SourceForge for downloading KeePass. However, even if SourceForge (or the KeePass website) is compromised and serves a malicious download, users who check the digital signature will notice the attack and will not run the malware. Note that HTTPS cannot prevent an attack via a compromise of the download server; checking the digital signature does.
The version information file is downloaded from the KeePass website over HTTP. Thus a man in the middle (someone who can intercept your connection to the KeePass website) could have returned an incorrect version information file, possibly making KeePass display a notification that a new KeePass version is available. However, the next steps (downloading and installing the new version) must be carried out by the user manually, and here users who check the digital signature will notice the attack.
Resolution. In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-4096 and SHA-512). KeePass 2.34 and higher only accept such a digitally signed version information file. Furthermore, the version information file is now downloaded over HTTPS.
http://keepass.info/help/kb/sec_issues.html#updsig
Actually it does. They depend on selling their product to security-savy users, so they will ensure it's quality.
No they don't. They just need some good advertising and they can sell to people who didn't even know they need it (fear works very well here). Really tech savy users will just move on if they don't like something or won't even come in because it's not open source or because of data thrift. The untechy customer will stick to what he has.
On the other side: if there is just one company better then them, with better advertising they'll have to see how they can get money with just this product. There are many creative solutions out there. A sheer endless horizon of possibilities I don't even want to think about.
This is a dangerously naive attitude.
No idea about Keepass(x), although I found that ecosystem to be confusing, with different apps for different platforms you might accidentally download a rouge one on e.g. your phone. I know, paranoia.
But sure. Looking for yourself is not easy. You have to do something for yourself and not just throw money on some company that is depending on this one product.
Not sure if your paranoia is directed the right way here though.
http://www.lifehacker.com.au/2016/06/keepass-vulnerability-l...
There have been some articles about automatic KeePass updates being vulnerable. This section clarifies the situation and its resolution.
First of all, we would like to note that KeePass cannot update itself. KeePass does support checking for updates (optional; by downloading a version information file, comparing the available with the installed version number, and displaying a notification if necessary). However, it neither downloads nor installs any new version automatically. Users have to do this manually.
KeePass can be downloaded from many servers (SourceForge with its many mirror servers, FossHub, etc.). In order to make sure that the downloaded file is official, users should check whether the file is digitally signed (Authenticode; all KeePass binaries are signed, including the installer, KeePass.exe and all other EXE and DLL files). The digital signature can be checked using Windows Explorer by right-clicking the file -> 'Properties' -> tab 'Digital Signatures' (the expected signer name is 'Open Source Developer, Dominik Reichl'). When running the installer, the UAC dialog displays the digital signature information, i.e. users who carefully read the UAC dialog do not have to inspect the file properties separately. This is recommended for all users, independent of where you download KeePass from.
The KeePass website links to SourceForge for downloading KeePass. However, even if SourceForge (or the KeePass website) is compromised and serves a malicious download, users who check the digital signature will notice the attack and will not run the malware. Note that HTTPS cannot prevent an attack via a compromise of the download server; checking the digital signature does.
The version information file is downloaded from the KeePass website over HTTP. Thus a man in the middle (someone who can intercept your connection to the KeePass website) could have returned an incorrect version information file, possibly making KeePass display a notification that a new KeePass version is available. However, the next steps (downloading and installing the new version) must be carried out by the user manually, and here users who check the digital signature will notice the attack.
Resolution. In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-4096 and SHA-512). KeePass 2.34 and higher only accept such a digitally signed version information file. Furthermore, the version information file is now downloaded over HTTPS.
We noticed some of the websites you read, and were wondering if you'd like to buy some stuff?
A lot of the stuff we're selling is directly related to what you were reading about just five minutes ago!
Are you interested in spending money on our stuff? Click here to find out more!
Would you like to fill out a survey, and be entered into a contest to win our stuff. It's fast, fun and easy! Try it now!
Here are some other articles we thought you might like. Is this ad irrelevant? Tell us how!
I did this for a few months for a master password and set everything to forget the password so I used it several times a day. After a little while I can get rid of the paper and have a LONG random password that is committed to memory.
I have implemented a little program to generate such a square: http://loup-vaillant.fr/projects/password-generator
Though by now, I find this a little tedious. I'm thinking of using an encrypted password database, protected with a diceware generated password. That way I will be able to copy&paste my passwords instead of typing them by hand.
This way I don't ever remember a password, I just remember the system.
If an attacker has access to 4 of your passwords in plaintext, you have bigger fish to fry.
I use this same method, but my method will often generate special characters, and AWS as an example, and several others (apparently following AWS' lead) won't let you use those. (Any punctuation not on the shift-numbers row of USA keyboards are not considered legit for password use)
I still mostly use this system, and given my lucky memory I can memorise the exceptions, but I doubt a vast majority of the population could follow my example.
On a side note, don't forget the time dropbox accepted ANY password during logins - http://www.cnet.com/news/dropbox-confirms-security-glitch-no...
- Useful as a canary of which website has been breached
- Useful as a canary of which website sold your details
- and if your details are in the wild, you can stop the spam by deleting the address
Credit cards should work the same way: a unique authorization code specific to this vendor or this transaction and useless to any other actor.
Isn't that how chip-and-pin works?
With chip and pin? I don't think they do.
Where I work you need the 3 digit security code and some address numbers (which you can make up) to properly process a transaction without the card.
Something to keep in mind is that when chip and PIN was developed to combat credit card fraud it was card present fraud that was the big problem, either by someone using the stolen card itself at a brick and mortar merchant or making a counterfeit cart by writing the stolen number onto a blank card and using that at a brick and mortar merchant. Card not present fraud, where the number is used but not a card such as at an online merchant or a mail order merchant or telephone order merchant, was much less common.
Chip and pin made card present fraud much harder because it was much harder to obtain blank chip cards and the equipment to write a stolen number to them, and it made using an actual stolen card harder because of the PIN.
I have no idea what Paypal is trying to achieve by passing on this fairly personal piece of data. I always have to enter a separate email address with the retailer anyway, and because of this scheme, those two of course never match.
For years the Paypal API sucked, and even today their are many companies that do not have full integration with paypal, so this is a way to match payment records as for 99% of shoppers the email address for the order/account will match the paypal email address.
Of course I let her know about it, and I seem to recall her saying she'd addressed it successfully, but if she described how, I no longer remember. It quite astonished me that this was even a thing that could happen, though. One hopes it no longer does.
It's like her giving out her email address and it being firstname.lastname@gmail.com
I'm not sure the fault lies with the service.
I recently started using it, works great.
But thanks anyway!
So, it seems they have some kind of partnership with a bank, which is able to generate unlimited card numbers for them.
http://www.theregister.co.uk/2016/08/17/pgp_admins_kill_shor...
I'm using a card from getfinal.com, which appears to be the same idea. So far so good, though it's not 100% disposable, I still have a plastic card who's number is no easier to change than a chase card.
(Yes, I know about the '+' in gmail, but I suspect the word is out on it)
Biggest downside to ASO: you have to pay $7/yr extra on domain registrations to make them private. So I register with Hover and host with ASO.
I also take this one step further and have inbox rules to automatically send all promotional email (from sites I'm interested in) to the trash folder. If I want a coupon for a website I frequent, I'll just search my trash for the latest offers from that company. Google conveniently purges messages from the trash folder every 30 days or so, and I don't have to worry about a massive backlog of promos.
Also like realemail+alias@gmail.com, this is really transparent to a spammer and gives away the real email.
Of course, if someone sees my email address, they could certainly infer a new one. But I'll deal with that if and when I get singled out. I don't think the spammers often actually look at the millions of addresses they use.
If I start getting spam on a particular alias, I can set up filtering rules to delete them.
There was an HN discussion about it fairly recently, https://news.ycombinator.com/item?id=11781361
If someone steals my credit card, AMEX has a problem. I'll take reasonable care, but I'm not going to generate transaction specific numbers or whatever unless there is a strong incentive to do so.
whatever the theoretical rise in price would be (due to the fraud), don't you think the merchant would price things at that level in the first place to make extra profit, if they could?
Sounds a lot like a bitcoin address.
I know the credit card company and everyone they share your data with can see your transactions, and that's a problem some may wish to avoid, but that is still a much smaller number of people who can see your transactions than Bitcoin. Bitcoin does not inherently include privacy.
I do this too, but it taught me everything is breached - the local ambulance service, the local computer store, the local car share, small businesses overseas that I've placed orders with.
Some of the big names don't seem to be, which is lucky because otherwise I'd be wondering if it was the ISPs that had been breached. Either large chunks of SMTP routes are breached and picking up confirmation emails, or there's a giant iceberg of pwnage floating beneath the surface out of view.
Very poetic. I'd like to see this made into one of those motivational posters and hung in the office of every dev team nationwide.
For the sysadmins out there ;)
More likely, sold. Every service that collects user data will get offers, and many can't resist the temptation.
Doesn't matter however, businesses that will sell you to the highest bidder (and in many cases, outside the US, illegally) can't be trusted to ever seriously invest in security. So if they aren't breached, they sooner or later will be.
I have been running per-service emails for 10 years and wonder to myself if it is worth the bother as I can recall only one ever spreading.
I don't have any fancy script to check these addresses - I have to go into my spam headers manually, and I've not done that for a long time. Perhaps there was a common issue a while ago that got patched. I'll have to check whether modern addresses are being spammed.
I mention that because most of the ISP do have re-targeting efforts.
Also it would seem more likely that your email provider is breached as opposed to lots of other companies/servers.
Then, if the spammer strips (removes) that part, it gets sent to the trash (binned).
E.g. myaddress+service1@gmail.com will go to your inbox and you can filter on it.
My earlier hypothesis was that this was on purpose, to make sure you don't use a filter on any email they might send. But these days I'm tending to think it's just a bad regexp on their side.
"I can't log in and to boot your site says there is no account matching first.last@gmail.com. What kind of Mickey Mouse operation are you running here?"
"Sir, you are an idiot."
What's important is to keep a backup of your password database in a few places. I use KeePass because I have no desire to keep passwords, encrypted or not, in a cloud service. I also don't find value in browser integration (possible attack vector?). I'm generally very DIY-inclined anyway. Your preferences may vary.
As a full disclaimer, there are some issues with KeePass [1], but known issues are detailed in full by the project and are available for review.
1. http://keepass.info/help/kb/sec_issues.html
I also have expiring subdomains. So I'm not using domain.com, but something like b2.domain.com. The rationale is that if I start receiving a lot of spam, I go through all the accounts I have, change all emails to use another subdomain like b3.domain.com, and then invalidate the old subdomain entirely. I haven't had to do that yet and my domain is several years old.
With two big exceptions: the email address I leave on my website and the email address I publish on my GitHub profile. These 2 have dedicated throwaway domains like throwaway283728@domain.com. Because you wouldn't believe how much spam I get from that GitHub profile, not just recruiters, but also get rich offers from princes in Nigeria and Viagra pills.
failure to send to a@example.com
failure to send to b@example.com
...
failure to send to aa@example.com
etc.
Everything is breached. From websites to software to hardware, I would estimate the majority of them can be/have been exploited by advanced hackers.
I'm awaiting the time when we all acknowledge that computers are fundamentally insecure.
1. https://gist.github.com/eligrey/5084991
One that stands out in my head is Cadillac. I had requested a brochure for a CTS, and I got random unrelated spam just days later!
My dropbox alias email started getting loads of spam about 2 years ago, I immediately junked that account, and set-up a new dropbox account (friends insist on sharing stuff over it...) - my old spammy dropbox alias is in the Dropbox leaked dump, my new current one isn't, which proves that this dump of credentials is from at least before 2015.
When I've contacted them about it, they've been absolutely adamant that the spammer must have (twice) guessed the exact email address that I've had there.
Sadly, it doesn't support 2FA.
I am a google apps customer and already have a few 20 aliases in there but having to go through their UI every time I sign up seems very tiresome. Can I create a wildcard email in the terms of service-*@bar.com being a alias of email foo@bar.com?
Do you know of a non-selfhosted provider that is able to do that?
/EDIT: Looks like fastmail, a service many on HN recommended is able to do something similar [0], though if one email gets added into a spam list, it seems to be not possible to remove one particular one.
/EDIT2: Fastmail just confirmed to be on Twitter that it is possible to set individual emails to rejected. Though this requires effectively creating a new alias and setting it to bounce which falls under the account limitations [1], so 600 for a single person account.
[0]: https://www.fastmail.com/help/receive/alias-catchall.html
[1]: https://www.fastmail.com/help/account/limits.html
Gmail also ignores full stops, so you could also use d.v.crn@gmail or dvc.rn@gmail etc.
Plus you can't completely shut down a label. You could route it into the trash but it will still end up in your email account.
Another Google Mail trick is to use periods. Not as useful as the +, but for those sites that don't accept +, one can usually add in a few extra periods to place sites into buckets (multiple adjacent periods don't work).
m.y.e.m.a.i.l@example.com
You probably just locked the stranger out of accessing their account though, so you probably shouldn't do this, unless said stranger is signing up for all kinds of services using your email address, in which case maybe they deserve it. :p
I would assume that google apps version of gmail offers something similar.
I also use it but some services do not allow the plus sign in their registration form. Very frustrating.
Sometime I even fire a mail explaining people rejecting '+' how and why they lost my business...
yourusername+anything@gmail.com
This also works on google apps hosted email domains. You can then use that as part of a filter if you start getting spam to it.
This works better than something+realaddress@gmail.com because many sites fail to handle/allow that 'format'.
Unfortunately, depressingly many sites validate email fields, and get it wrong - thinking '+' is not allowed.
IMO it's not even worth trying to get an email regex (or other validation) right - you're probably going to send out an activation email anyway!
[0] http://girders.org/blog/2013/01/31/dont-rfc-validate-email-a...
Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.
You -should- treat email the way that vast majority of hosted services do. "Foo Bar"@gmail.com is not allowed. Covering the million edge cases seems to not be worth the trouble, especially when it might cause difficulty for the average user
With smartphone keyboards and the capitalization of the first letter of the first word in form input fields by default, this is a very common occurrence. If case was considered for uniqueness of email addresses, at best, people would be extremely annoyed. At worst, there would be a tremendous amount of leakage of sensitive information to random people (due to human errors in entering case sensitive addresses), chaos due to incorrectly delivered emails and fatigue in receiving mails intended for thousands of other people. In an alternate universe where this is true, email would never have been a killer application, only a quickly killed and abandoned one. :)
Another feature of Gmail is you can place dots anywhere in your email and it will still reach you: ex.am.ple@gmail.com. I haven't seen services that reject that so it is what I use when I can't use a +.
HOWEVER, you should only do so after careful consideration. This will restrict moving your email hosting to the limited number of providers who provide provide this type of service, or hosting your own server.
Alternatively, you could go and reset your email address with all of the services that you gave a subdomain email.
For myself, I have been using FastMail for years and feel confident that I will continue to use their services. In the event that I needed to move from FastMail, I know that could self host if forced to.
https://grepular.com/Automatically_Expiring_Email_Addresses
I've not forgotten, and this glitch has kept me from ever considering opening a Dropbox account.
I'm surprised everyone else seems so forgiving of this massive screw up.
I wonder if there has ever been an attempt through a forum like RFCs or ISO to define a worldwide (or at least latin char set) standard for password requirements. Based on what i've seen in forums like this, there seems to be fairly broad acceptance that allowing a large number of characters from a character set with as few limitations as possible bests serves the interest of security. The thorniest issue would likely be about balancing requirements for increased complexity (eg capitals and lowercase, numbers, etc) with ease of use.
Alternatives, though? Plenty: Google Drive, Box, OneDrive, iCloud Backup and iCloud Drive.. the list goes on with a simple Google search for "online storage"
Install the desktop application: https://support.google.com/drive/answer/2374987 Change sync settings: https://support.google.com/drive/answer/2375083
No native linux support is a bummer, but if you only need to use it there infrequently, the web client is quite capable for manual uploads and downloads.
For more similar alternatives, running owncloud on a VM is straightforward. And, of course the featureset is limited compared to Dropbox.
[1] https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_A...
https://blogs.dropbox.com/dropbox/2012/07/security-update-ne...
Oh well, another HIBP entry with my email address...
Troy Hunt is a person, not a team, and I guess he links to HIBP because he's proud of his work. I know I would.
At this point I'd say signing up for notifications with it is just a solid security practice.
SHA-1 hashes should still be okay, right?
you're not alright, we have a way of knowing if that was your password or not and having unlimited tries with unlimited processing power, which means it's a matter of time before someone is able to guess their way into your accounts.
EDIT: Thanks everyone for your answers, this is a good example of the power of communities.
At present I still recommend LastPass because that way you can easily have everything synced on your computers, phone, etc., and it's easier to convince people to remember one strong password and let LastPass handle remembering all the other strong passwords no matter what device you're on.
If you use service like LastPass or 1Password you can never be entirely certain that a breach or a security flaw in any of these services isn't going to expose your passwords. I'm sure they use the proper encryption measures, but like the Dropbox breach shows, shit happens and companies get hacked.
I'm not saying never use a cloud password manager, but understand that the added convenience comes with added risk; I would definitely not make my company depend on them.
- Client-side encryption, meaning the service has no way to obtain your cleartext passwords (short of planting a backdoor, which is a vector that applies to all password managers).
- Full offline support, with the ability to export your database. This becomes relevant when the service is down, you're running into billing problems, or if the company goes out of business entirely.
- Availability of a native client (as opposed to web apps or extensions that act as a thin layer on top of a web app). Planting a backdoor that leaks your secrets is significantly harder when you also need to compromise the vendor's signing key, as opposed to just breaching their web server and adding some JS file.
Even if Google or your Google drive is hacked, assuming you are using a strong passphrase for keypads, you are still OK.
If Lastpass is hacked, that's a different story.
https://en.wikipedia.org/wiki/List_of_password_managers
I use Keepass, it does exactly what I need.
Secure the password manager itself with a long password. Put your logins into it, and generate a unique random password for each one, then go to the website in question and change the password to the new one.
When you want to login to that website, open your password manager, copy the password to your clipboard and paste it in. Remove the password from the clipboard (Keepass does this automatically after about 10 seconds).
That is ALL you need to do. You could get into using keys, etc, to secure the password manager but if you have a long, unique password for the password manager, it shouldn't be necessary. I'm sure others can provide you with info on how to finesse the process using online password managers, etc, but what I've just described is the basics. Start simple, ramp it up later if you're the paranoid type (which you should be ;)
EDIT: Another thing, if you can use two-factor authentication, do it. I use this on my Google accounts, Paypal and my bank.
https://www.google.com/landing/2step/
https://www.turnon2fa.com/tutorials/how-to-turn-on-2fa-for-p...
Another edit: You can store more in the password manager than just passwords. I keep a scan of my signature in there in case I have to put it into one of those (admittedly insecure) PDF-type forms to "verify" I've signed something. I also make up stupid answers to password hint questions and these also go in the password manager, e.g. "First school" -> "Dr Magnus Pike's School for Aspiring Arsonists". Too easy for people to work out what my real first school is called.
Also, how comes all security-aware people trust 1Password and LastPass, even though they are not open source? Isn't that one of the rules of security, publish the source so we can trust it?
Also, the idea that an army of trained security professionals is ready and able to scan open-source software for vulnerabilities isn't true - I think there was a study a few years ago which proved these security checks often didn't happen, people just assumed they did. The OpenSSH (secure shell) software was compromised for years and nobody noticed, and it is true open source and a critical part of people's systems as well.
You're looking to mitigate risks. A password manager is a step in the right direction. If you are truly paranoid (good for you) something like this, based on GPG, might be the right answer for you:
https://www.passwordstore.org/
Personally I prefer not to use cloud-based password managers because I don't know what their backend security is like. But those more knowledgeable than me might say "they're fine" because of the way the encryption is structured.
I don't think this is true at all. Many people do not recommend using these services for exactly that reason. Plenty of so-called experts make lots of compromises in their choices and recommendations for various reasons.
http://penguindreams.org/blog/my-accounts-been-hacked-no-it-...
The article is dated. I'd suggest a longer minimum and 2 factor for services that support it. The advantage is unique passwords that you don't have to look up.
Of course, the pattern doesn't have to be that simple, but even if it were incredibly complex, at the end of the day you are still relying on one single pattern for all your passwords.
Most password leverage comes from breaches and people running larger scale operations for scamming and spamming.
I wrote a small program that generates a list of random passwords. I just open terminal and type password, then copy/paste one of the outputs and allow Keychain Access to remember it. I do this for every service, the only manual password I use is for my actual computer, which is rotated periodically. You’ll need to manually backup your keychain file though.
This isn’t a friendly solution for most people.
Thankfully the notification emails from this service are prompt and helpful (not to mention totally free).
Not sure if 1Password does as well, but it seems like a fairly obvious feature to add.
https://watchtower.agilebits.com/
The certificate/password link is a guess since on their website they say to change the password starting with date that matches the date of certificate reissuance.
This seems to be related to Hearbleed, also it lists a site that didn't reissue certificate after Heartbleed as vulnerable too, and so for passwords there, seems to be regardless of age.
I am a long-time 1password user and have a lot of old passwords, so for me like 90% of passwords are listed as compromised, which I'm pretty sure is not the case.
Which I suppose forces more awareness, but it doesn't instill a lot of confidence.
FWIW I was subscribed and didn't get anything until this most recent breach. Unfortunately GMail thought it was spam (speaking of false positives!).
My primary personal email address is routinely used by a small handful of other real people (all strangers) for all sorts of things - college applications, car insurance, some address books think it belongs to a cousin who gets included in a lot of group threads about reunions and full of photos. I've found the families more difficult to unsubscribe from than the services, name+email associations spread like a virus. I routinely get alarming/misleading "Someone has your password!" security alerts from Google after someone tries to list my email as a backup account.
These little strings we use to identify ourselves can be typed by anyone, anywhere, bot or human. I wouldn't worry too much about false positives.
It's not that I'm worried, it's that it's a distraction. When the margin of error is high enough, it becomes less signal and more noise, which leads to either panic (spending all your time managing access credentials) or complacency (ignoring the indicators).
Why do I see my username as breached on a service I never signed up to? When you search for a username that is not an email address, you may see that name appear against breaches of sites you never signed up to. Usually this is simply due to someone else electing to use the same username as you usually do. Even when your username appears very unique, the simple fact that there are several billion internet users worldwide means there's a strong probability that most usernames have been used by other individuals at one time or another.
They might not even know it's yours, like if your email is davidsmith@gmail and they fat-finger davidrsmith@gmail--boom, "you" now have an account.
Good services use double-opt-in to ensure that every account is actually tied to a correct and working email address. But not every service does this.
And even services that do use double opt-in would create a row in their database to note that a confirm email was sent out. If they never scrub those invite rows, "your" email address would still be in the DB when it's exfiltrated, even if the confirmation process was never completed.
[0]: http://risky.biz/RB388
Also it's an email address, not your credit card number.
He goes on to say that 1Password has a subscription now and that you should signup for it.
No. I will never, ever put all my passwords into a cloud based password store. I simply do not trust them to not fuck it up at one point in time.
Am I alone with this view?
For some products, they are.
"Your vaults, items, and documents are fully encrypted in your 1Password Families and 1Password Teams and stored on our servers."
I'm biased, but I can't agree with this. From what I can tell, there are two communications from Dropbox -- one in 2012 [1] and one last week [2].
In 2012 they did not disclose that hashes were stolen, so I don't see how it's really relevant. In the latest communication, they don't actually explain the risk to the user. They say it is "purely as a preventative measure" but if salts and hashes were accessed, then that is not the case.
Just because Troy doesn't have access to some of the salts, doesn't mean the attacker doesn't have access. We don't know how many iterations of SHA-1, but SHA-1 can be run by a single GPU on the order of billions of times per second. So unless Dropbox is coming out and saying they know for certain that random 128-bit salts were definitely not accessed by the attacker, almost all of the SHA1 hashed passwords are getting cracked. Users need to know their passwords are exposed, and must be reset not as a preventative measure, but because they are almost certain to be compromised.
As for the salted/bcrypt passwords, we can see from Troy's hash they used $2a$08$ which is bcrypt with a cost factor of 8 -- 2^8 iterations. Gosney's latest rig [3] could crack these bcrypt hashes at about 105,700 / 8 = 13,212 per second. That's not terrible, but that's still 416 billion tries in a year for a modest investment.
[1] - https://blogs.dropbox.com/dropbox/2012/07/security-update-ne... [2] - https://blogs.dropbox.com/dropbox/2016/08/resetting-password... [3] - https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
> I'm biased, but I can't agree with this. From what I can tell, there are two communications from Dropbox -- one in 2012 [1] and one last week [2].
Especially given that 2012 they assured me that no credentials were lost and this time they didn't even inform me since my account was deleted in the mean time. So it's more or less luck that I know that my old password was compromised.
This should be assumed regardless of what is known if it's know a breach happened; meaning basic password hygiene should be followed, and I'm the case of Dropbox, if a user had any plaintext files with passwords to other accounts (yes, people still do this) - they need to change those passwords too.
As for the average user, to be honest at the point I increaslying feel like people are responsible for their own security and if you that concerned a service won't notify you of a breach or make a mistake that to you is unforgivable — don't use them. Reason I take this position now is because increased you feel like all the hand holding related to security is dangerous long-term.
However, a forced password and session reset on accounts whose credentials have become public knowledge isn't "hand holding." It's SysAdmin101. It should be the first thing you do. Unless I'm misreading you, the stated stance is "Anyone using dropbox got what they deserved," but not everyone has the knowledge to perform a security audit. The user is not without blame or having made mistakes, but Dropbox isn't taking ownership of their own mistakes or being transparent to every affected user about what those mistakes were and/or led to. If they want to be a service that does hand-holding, they can give the correct advice. If they don't, they NEED to be transparent about what occurred and what information was released or the onus is entirely on them. Right now, they're doing neither. I think that is criminally negligent, though I'm certain no legal action will be taken.
I feel that lowering those expectations of a service only helps justify these shitty, lazy practices to others.
The only thing that would've been exposed in the breach relating to me are the e-mail address and password for that service itself (alongside all the crappy memes I stored there), but I'm not ready to watch the world burn from the sidelines. The security of others is just as much your personal security, and the more of it others sacrifice the more you'll be expected to do the same and suffer repercussions for not doing so.
"We’re reaching out to let you know that if you haven’t updated your Dropbox password since mid-2012, you’ll be prompted to update it the next time you sign in. This is purely a preventative measure, and we’re sorry for the inconvenience.
To learn more about why we’re taking this precaution, please visit this page on our Help Center. If you have any questions, feel free to contact us at password-reset-help@dropbox.com"
Clarification edit: I did receive the e-mail from Dropbox letting me know that I should change my password, but when visiting dropbox.com I was already logged in and wasn't prompted to perform the pw reset
Unlink the device to restart the session.
For us, this is deliberate for a few reasons. Most of our customers authenticate via their employer's SSO (single sign on) and do not use any Syncplicity password management. We also do not believe that routine password maintenance should force someone to run around and re-authenticate all their computers. (Like Dropbox, a user can log into our web site and remove computers from their account.)
I do understand the argument that a password change should force a re-authentication on all clients; but I don't think it's the right approach. Changing a password is reactionary and preventative. An email notification will inform a user that his or her account is compromised.
Don't pay for this people. Use the open source password manager Keepass http://keepass.info/
On the other hand, the PuTTY website is also everything but polished, but people have always been using it. Also, I suspect that most people will get it through the third-party site "www.putty.org" instead of the real PuTTY website, whose URL is as complicated as: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h...
I don't think it's ugly -- just dated. Isn't it weird that mentally we trust software less if they have a dated website? Shouldn't it be the opposite? (As in: a dated website means this software is mature and tested?)
If the software is well supported and maintained than the website should be too.
https://support.1password.com/pro-features/
If 1Password ever got owned, the Internet would be severely fucked.
And to stem the potential flood a bit, I realize there are plenty of good counterargument built up over the years to try and combat this general idea, but fundamentally the concept of giving your password to someone else to manage is still a confounding idea, regardless of whatever points those arguments make.
That sounds more like LastPass than 1Password, although I haven't looked at the new subscription offering.
I don't give my passwords to 1Password.
Dropbox was also encrypting your passwords, FWIW.
Dropbox was not encrypting passwords they were hashing them.
If you stored already encrypted files on Dropbox nobody can decrypt those files provided your encryption key is good.
Incorrect.
I'm pretty sure you're going to say "they do TLS" and then the person you're talking to can go ahead and explain that the encryption LastPass/1Password does protects an entirely different threat model, but unless you have a conversation here no one is going to be able to communicate a thing.
That said, I was wrong. I recalled what bcrypt does incorrectly.
Password reuse has been slightly overblown as a concern. Things like your Google, GitHub, TeamViewer, bank, etc. accounts should always be unique. But if someone hacks your password for the Engadget forums or something, does it matter that they can now log in to your Kotaku commenting account? REALLY? People talk about how they have hundreds of accounts and could never remember passwords for all of them, so need a password manager... but in reality, only a few of those accounts actually matter.
And you're better off leaving a piece of paper with passwords on it by your desk than using a password manager. The likelihood of a digital hack of a password manager is infinitely greater than the likelihood of someone breaking into your house to get your passwords (instead of like... just taking your TV).
The only real concerns here are weak crypto and backdoors. If your threat model includes backdoors planted by software vendors you trust, not using a password manager won't help you, since someone might as well just backdoor your browser and get your brain-managed passwords as you type them. I'd stay away from webapp-based password managers, as planting a backdoor is typically easier for these.
Weak crypto is a hard problem, so you'd have to do some research and check whether the format your password manager uses has been vetted by the crypto community.
Looking at the vectors that are most commonly used to hack people today, I'm certain that password managers would be a massive improvement compared to the short and re-used passwords the majority of users use today.
To be more direct, I'm suggesting the standalone native application may not completely correctly implement the encryption algorithms. I have no evidence of this, but the concept still concerns me.
I used KeepPass for a number of years and it's a fine piece of software. To solve the problem of access on multiple devices and keeping it in sync I kept my password database in Dropbox. It works reasonably well but you often run into "lock conflict" issues when it is open from multiple devices, fine if it's read-only but I always felt uneasy when making changes.
A few months back I switched to LastPass and although it's GUI takes some getting used to, I was able to import everything from KeePassX into it easily and de-dupe it.
It even has 2FA support via Google Authenticator so it's convenient.
There are also apps for Firefox, Chrome and Android (phone and tablet) so I forked out for a Premium license and I'm pretty happy.
You can get it to generate passwords for a new site, no fear of using the same password in multiple places and LastPass will warn you if that happens.