Firefox cannot guarantee the safety of your data on digitalsecurity.intel.com because it uses SSLv3, a broken security protocol.
Advanced info: ssl_error_no_cypher_overlap
For some reason, many sites, including amazon recommendations, fail to support 256 bit ciphers. I don't understand why.
The left side is what the app picks up as the text of the article. The right side is the page itself loaded in a browser, after it has finished loading all of the scripts and automatically scrolled itself past some contest thing.
I'm on a dual-core Atom with 2GB of RAM and the site lags the entire thing. I mean, it's not as impressive as if it were the latest MacBook like some sites lag on, but still. Pretty shitty.
> For some reason, many sites, including amazon recommendations, fail to support 256 bit ciphers. I don't understand why.
I assume you mean AES-256 vs AES-128. If a site is preferring AES-128 ciphers (particularly in combination with other modern cipher suite choices (ECHDE, SHA2, etc)) that's actually a pretty good indication they know what they are doing.
AES-256 offers no practical advantage over AES-128. There are no known practical attacks against AES-128, and stretching the key to 256 bits just wastes CPU cycles.
In fact, most of the attacks out there that weaken AES to any meaningful degree are those that attack the key schedule used in the 192 and 256 bit versions.
Very odd. I'm using Chrome with chrome://flags/#ssl-version-min set to TLS 1.2, and I can connect just fine, although the certificate is signed with SHA-1.
It's a question of choice, as a user. My original question was - why? Saving Earth, that's one way to look at the thing. Why then, amazon.com connects just fine with 256 bit cipher, but then fails when one goes to personal recommentations section. Most likely, of course, it's a misconfiguration issue, but is it possible that there exist more sinister reasons?
Recall RC4. We now consider it broken. But it is still allowed on many servers, and even on 34.0.5 Firefox.
I agree, when one goes to disable legacy functionality, one should be prepared to suffer consequences. That's why my original question was "why".
I'm running Firefox 36.0.4 on OS X 10.8.5. I see a "grey warning triangle" using Mozilla parlance. Clicking on that says "the connection to this website is not fully secure ...".
Firefox refuses to show me Intel's certificate at all. It does say "This website does not supply identity information".
How is an average user to know what to do if even a single application, e.g. Firefox, presents different messages to different users? IMO the message you received: "cannot guarantee the safety of your data" is much different than the one I got: "not fully secure". So which is it, and what is the difference?
Bah. Right now I switch to a separate OS X user for my banking and credit card sites. But it's probably better to devote an entire computer (not a VM) to access just those few sites. It's 2015 and things are worse and more confusing than ever.
Yes. It is about setting an example and practicing what you preach. There is no point in lecturing people about one aspect of security whilst getting the security wrong. You would not buy from an ecommerce site if the https:// wasn't done properly.
I sort of thought that https was sufficient for most things on unsecured connections, so a VPN wouldn't be necessary to prevent things like password sniffing. Or is that wrong?
At home TLS is fine. If you're connected to a public wifi using a VPN on top of that is a good idea because you only have to trust one VPN provider (or your own server) instead of every hotel chain, coffeeshop, etc.
> sufficient for most things on unsecured connections
WPA2 + good TLS encryption (i.e., good cyphers) should be.
Are you worried about parts of the TLS handshake being intercepted, or something? Because even then that's non-sensitive information like public keys and cipher lists and stuff, no? Or are we worried about side-channel attacks, or weak ciphers being chosen?
Just curious about your reasoning for why TLS alone isn't sufficient.
I've used blackVPN and IPredator in the past. Running openvpn on your own box is pretty easy too (if you've ever set up something like a HTTPS server.)
PIA has never done me wrong, it's cheap, they support a ton of VPN protocols and OSes, multiple simultaneous clients (up to 5?), and at least one of the guys who runs it is a HN regular.
So hypothetically if you didn't care about people sniffing your non-https traffic there's little to be gained from a VPN? Besides various metadata collection and DNS queries.
A pragmatic one I like to say to non technical people like my mom and sister:
- Have a dedicated email password that is different from every other password you use.
Let's be honest: You should have different passwords for every site, and you should use strong passwords and a manager, but you don't because you're a normal person. At the very least, be pragmatic and have an email password that's separate from every other service password. The idea being, if your random-service-you-signed-up-for-once.com password gets hacked, and your username was your email address, the first thing an attacker will try to do is use that password on your email. So have a strong email password and trust that your gmail account is less likely to be hacked than your random-service account password.
KeePass plus multiple supported clients have allowed me (and my wife) to manage a unique password per account without too much effort. My eyes really opened when my linkedin leak happened and I realised how many accounts shared that same password.
I use LastPass and I can't recommend it enough. It's fantastic and I have different passwords for everything simply because I never bother making passwords. I just hit the random function on it.
I still have my email passwords memorized, though.
This is honestly the best service I've ever paid for. It has never failed me, and it substantially improves my life.
I use LastPass and think it's great as well. I've tried to recommend it to others though and the common reply is "that doesn't sound secure enough for company policy".
They don't seem to realise though that their usual approach of sharing passwords over email, using the same password for several logins so it's easy to remember and using easy to remember passwords in general is much more insecure.
Services like LastPass make it practical for you to use impossible to guess passwords, different passwords for every site and let you share passwords securely.
My key argument when I've convinced past employers to implement it: you already outsource all of the hard parts of your security. Antivirus, firewall, AD permissions, server config, all of it. They either bought a product to fit the need or hired a consultant to do the advanced stuff. $12/year is pretty cheap to hire a dedicated team of security wonks to safeguard your passwords, IMO.
It's not the cost that's the issue though, people don't like the idea of passwords being stored in a single place on a internet connected computer. I mention that you can secure password access behind two factor authentication but it doesn't get around the knee-jerk reaction often. Sharing lots of passwords when working with a team remotely is especially painful when password managers are not allowed...
Strip (https://www.zetetic.net/blog/) is a mature and multi-platform local password manager that does not need a cloud connection, and can optionally sync from mobile to a local desktop. Made by the developers of open-source SQLCipher for SQLite, https://github.com/sqlcipher/sqlcipher
I wish they would integrate with iOS8 Safari as an extension.
That's what I recommend as well. Once someone has access to your email, the attacker can then use the "forgot your password?" of most sites to get further passwords and access.
1 - use an iphone for all banking. It's the single hardest system for someone to install spyware on: they are more careful about which apps are in their store than android, and the apps are more isolated. Android apps often have spyware; android install prompts on websites are super sketchy (and cover 1/4 of the screen, perfect to trick older or unfamiliar users into installation), and the permissions are far less granular. Windows is a disaster for secure computing, from viruses to "install this to get 500 smiley faces" to flash with monthly zero-days to fake software installs advertised via google sem.
2 - use gmail, and use 2fa
3 - pay the $30 for the hardware login tokens for your brokerage (and ideally, banking) account
4 - don't use any wifi except home wifi; just use wireless
5 - NO, your friend/cousin/grandchild is not stranded in an airport in Europe
You have to pay for hardware login tokens? In most of Europe, they're not only free, but mandatory.
And, depending on how un-savvy you're talking about, I'd recommend just doing internet banking at your local bank. Just set all regular bills on auto, and configure your account to text you if something unusual happens (like your current account is running low). Then you should only really need internet banking a handful of times a year.
I realize that opinions on this differ, but I think that automatic bill payment is a horrible security practice.
Just last week I was paying with credit card in which the merchant punched in $5504 by accident instead of $504. Had I not noticed it right away, at least I'd get another chance to correct the error when my credit card bill arrived. With auto-pay, my bank account would have been emptied.
What would you do if some sort of auto pay error emptied your bank account? These things take time to resolve. What if it's a weekend, or a holiday, or you're traveling overseas, or the entity that caused the problem is on strike, or they want a written dispute from you?
I like auto payments for regular payments such as a gym membership of $X/month and even for payments that vary somewhat but are from pretty reliable sources (monthly utilities--maybe) but NOT for credit cards. Credit cards are all sorts of different charges every month for all sorts of things in all sorts of circumstances. You really should look over the charges each month and figure out any that don't look right. Auto payment trains you to ignore something you should train yourself to keep an eye on.
Many banks allow you to set a max for an ebill. However, 99% of my auto payments are fixed amounts, so your scenario doesn't apply. Auto pay is the only thing that keeps my bills paid on time (I suck at paying bills manually).
I wouldn't (and I don't) have autopay on the credit card. Anyway, if suddenly my current account is emptied for some weird reason, I have backup funds that can be transferred to the current account in five minutes on my phone.
Also, I started from the assumption of a non-technical person with "simple finances", so no credit card.
I freely admit that hardware tokens may be more secure, but the more 2FA that uses the standard implemented by Google Authenticator the happier I am. Plus, in my mind it would be cheaper and easier to implement a software only process than to try and convince a CFO that buying, shipping and managing little pieces of hardware will have sufficient ROI.
I also am not holding my breath for even the software 2FA since quite a few of my financial institutions won't even let me use punctuation in my password. Yes, the irony of implementing 2FA lowering the risk of a simple password isn't lost in me.
Alipay differentiates login password and "payment password", and it always asks SMS verification code if one tries to login via VPN, from new device, or from new location. I think that's good practice for websites.
> You should have different passwords for every site, and you should use strong passwords and a manager, but you don't because you're a normal person.
I'm amazed that people favor remembering passwords over using a password manager. With Firefox Sync, or the Chrome equivalent, you have your browser remember the password, every other browser you use syncs with that so it has the password, and you never need to have it memorized. The only thing that's missing for better usability is a built-in "generate and use a random secure password" mechanism.
I think mostly the industry is to blame here. We could have had a universal secure 2fa ages ago. I hope that with the advent of smart watches, 2fa could become more sexy, and hence could get more attention from the industry.
The problem I have with browser password managers is how simple they are to crack. Master passwords are disabled by default (if available at all), and even with a master password, many browsers still don't encrypt them in the password store.
If it syncs, that means that all my passwords are out in "the cloud" somewhere, which means I would be vulnerable everywhere all at once should that one master list ever be compromised.
If it doesn't sync, that means I can only get in from one computer, which is occasionally inconvenient.
So I keep my passwords in my brain, which is always with me, or at least with me at all the times when I might need to use a password.
> If it syncs, that means that all my passwords are out in "the cloud" somewhere, which means I would be vulnerable everywhere all at once should that one master list ever be compromised.
For Firefox Sync, that entire list is encrypted using a client-side key in your browser, and the server has no access to the cleartext.
I thought I was the only that did this! Only two passwords of mine need to be memorized. Dropbox and Gmail. 1Password for everything else, with a dedicated Dropbox account solely for keeping the 1Password vault backed up (I've had my laptop stolen before, and being locked out because you don't know any password makes for a terrible afternoon).
This helps when your password is lost along with thousands / millions of other passwords in a breach -- attackers would be trying to re-use passwords programmatically in bulk and wouldn't detect your algorithm.
But if you were individually targeted i.e. a human attacker is looking at your password, your algorithm would provide access to many of your accounts with little effort.
I used to use this solution, btw, but have now gone to a unique, complex password per site with a password manager.
I also used to use this solution about ten or fifteen years ago and have since moved on to password managers and long passphrases for accounts whose passwords I do not want to store in the password manager.
I would say disable flash/javascript by default but I too was surprised they didn't have this. Nothing like knowing you shouldn't click on a link only to have some malicious javascript do it for you.
It doesn't seem to matter much what I do when every company I interact with gets hacked.
I had to replace my debit card this week because somebody halfway across the country tried to use it to buy $400 in gas. They probably bought it from one of the usual black markets, who acquired it from Lowe's, or Jimmy John's, or Sony, or god knows who else got hacked this week.
Is this part of an Intel content marketing campaign to promote awareness of how difficult operational security is for the layman? Perhaps in anticipation of their new security suite and attempt to "eliminate the password?"
two factor authentication: Things like this are probably the best argument for why I should get a phone, thought I still wouldn't have much use for it.
Also, it seems safer to write down your passwords. I mean, someone might physically take it, but that seems less likely than someone digitally taking it.
Is there any advantage in using a password manager over authenticating with e.g. your google account through OpenID?
I usually use my google account to login to websites I care about (most sensitive websites I know provide this facility) and moderately strong but easy to remember passwords for non-critical websites that don't provide OpenID (e.g. a forum I never consult).
Of course I have 2FA on the google account and I feel rather safe.
So if I understand this diagram correctly, you connect to the server that you want to log into. It determines whether or not you are authenticated (probably through cookies). If so, it redirects you to the OpenID server. The OpenID server checks your credentials and returns back to the original server. The diagram does not specify, but I'm guessing the OpenID server has a session cookie for your credentials so that you don't have to log in over and over again.
So what are the downsides?
1) The server you want to log in to knows about your OpenID. In other words they can potentially identify you and track you (possibly with the help of Google).
2) The OpenID server knows which sites you are going to and when you are logging into them. It can track all of your movements. I think it would be naive in the extreme to assume that Google does not do this ;-)
3) Without knowing more details I couldn't say, but I suppose it might open you up to Cross Site Request Forgery style attacks. My experience with Google code in this respect is that they are usually extremely thorough about this sort of thing, so I think this is unlikely on the OpenID side. In my sleepy state, I can't really think clearly enough to imagine whether or not there are ways to screw up the code in the server that uses OpenID, though.
My employer loves Google and we use a ton of Google services. I am lucky enough to have incredibly technically competent management and they understand the tradeoffs of having Google track everything we do. Because of that, I use OpenID for any other external service that my employer mandates/approves of. I'm pretty careful not to go to OpenID authenticated sites by clicking on links and open them directly, so I feel confident that I can avoid CSRF attacks even if they could be done.
I do not use OpenID for personal use. My employer may be happy to have me daily work activities tracked by Google, but as a private individual, I don't really want that. I use an offline password manager: http://www.passwordstore.org/
I applaud you for being crypto-conscious (and confident) enough to write your own pw generator, but I think it's important for there to be commodity options available to those of us who aren't.
That may look sane, but you're deriving all your passwords from a single master "key". Leak it once, for any reason, and all your passwords just became known. (Unless you provide unique value of 'n' for each site, which I doubt you do.) If you use a common login or email address as your user name across the sites you use, they all pop open at the same time.
My take on password generation is even more straightforward:
% head -c 9 /dev/urandom | base64
Then whatever comes out, I store on an encrypted volume - so effectively I do have a master passphrase but none of the login credentials are derived from it. For sites that I think require even more entropy, I'll just bump up the number of bytes read. (98 = 72 bits of entropy, 128 = 96 bits)
I haven't yet found a password manager I truly liked.
EDIT: you do realise you are capping the entropy of your per-site passwords at 72 bits? It's more than enough against all practical brute force attacks, but it also means that any entropy in your master key above 72 bits is effectively lost.
I don't store my master password anywhere or execute this generator on a device that I don't own. The main problem with fully random passwords is that I need to carry my encrypted volume around with me everywhere, and also worry about backing it up.
Yeah I realize it is being capped at 72 bits -- the main reason is that I've seen a bunch of websites that don't allow passwords longer than 18-20 characters or so. :-/
But to give some substance to the claim, the speed record for single-system password hashing in 2012 was ~350GH/s [0].
Let's assume that in 2015 a single system is capable of doing 1TH/s, or ~1000GH/s. So, 10^12 password attempts per second. An attacker, who is not a nation state, should be expected to have access to maybe 400 such systems. But to make this conservative, let's assume they have 1000 such systems. So, the attackers should be able to reach 1000 TH/s, or 10^15 attempts per second.
10^15 =~ 2^(15/0.301) =~ 2^50.
Hence, a determined attacker with finite resources has to do, on average, 2^31 seconds of work to brute force a password with 72 bits of entropy. 2^31 seconds is roughly 68 years.
That in turn means that there are lot of lower hanging fruit to pick before even thinking of expending resources to brute force passwords with 72 bits of entropy.
On the other hand, the resource requirements are getting awfully close to the realm of feasibility, so 72 bits might not be sufficient for long after all...
I feel like it wouldn't be anywhere close to 10^15 if they use a slow hashing algorithm, which is what password stores should be using (e.g. http://en.wikipedia.org/wiki/PBKDF2 )
Every new sensible implementation of password store is using either bcrypt, pbkdf2 or scrypt.
I picked the lowest common denominator because it caters for the worst case scenario. Systems where passwords are improperly hashed are quite likely to have other security problems too. And as such are more likely to get breached, whereby their password store is lifted too.
Bah, that's embarrassing. I will break the HN etiquette and reply to myself, because I will not succumb to editing the post above and retroactively fix a calculation error. Whatever comes from that, I deserve it.
I was off by 2^10. For some reason I kept thinking the 72 bits as 82 bits. You can even see that from the numbers!
So yes, 72 bits is not enough anymore. I stand corrected. New ballpark figure for sensible security margin should be 96 bits.
Firefox nightly / built from development source refuses to connect to this site because it fails the (experimental) stronger SSL/cert requirements. (The site forces RC4)
On the habits of practically unhackable people indeed.
Speaking of password managers, what are some suggestions for password managers for sharing passwords around groups of staff in small businesses? We're currently using passpack, but the UI is a little janky - as a result, it's hard to get colleagues to practice good password hygiene. It's not terrible, but it is a bit annoying to use.
HACK ATM AND BECOME RICH TODAY
How to hack an ATM MACHINE or BANK ACCOUNT
You can hack and break into a bank's security ATM Machine without carrying guns or any weapon.
How is this possible? First of all we have to learn about the manual hacking of ATM MACHINES and BANKING ACCOUNTS HOW THE ATM MACHINE WORKS. If you have been to the bank you find out that the money in the ATM MACHINE is being filled right inside the house where the machine is built with enough security.to hack this machine We have develop the special blank ATM Card which you can use in any ATM Machine around the world. this card is been programmed and can withdraw 2000 USD within 24 hours in any currency your country make use of. The card will make the security camera malfunction at that particular time until you are done with the transaction you can never be trace. getting the card you will forward the company your address details so we can proceed to send the card to you once you agree to the terms and conditions. you can contact us on email now atmmachinehackes@gmail.com
100 comments
[ 3.5 ms ] story [ 165 ms ] threadFirefox cannot guarantee the safety of your data on digitalsecurity.intel.com because it uses SSLv3, a broken security protocol. Advanced info: ssl_error_no_cypher_overlap
For some reason, many sites, including amazon recommendations, fail to support 256 bit ciphers. I don't understand why.
http://i.imgur.com/tZ3IcwJ.png
The left side is what the app picks up as the text of the article. The right side is the page itself loaded in a browser, after it has finished loading all of the scripts and automatically scrolled itself past some contest thing.
I'm on a dual-core Atom with 2GB of RAM and the site lags the entire thing. I mean, it's not as impressive as if it were the latest MacBook like some sites lag on, but still. Pretty shitty.
I assume you mean AES-256 vs AES-128. If a site is preferring AES-128 ciphers (particularly in combination with other modern cipher suite choices (ECHDE, SHA2, etc)) that's actually a pretty good indication they know what they are doing.
AES-256 offers no practical advantage over AES-128. There are no known practical attacks against AES-128, and stretching the key to 256 bits just wastes CPU cycles.
In fact, most of the attacks out there that weaken AES to any meaningful degree are those that attack the key schedule used in the 192 and 256 bit versions.
tl;dr; Save the planet. Use AES-128.
Very odd. I'm using Chrome with chrome://flags/#ssl-version-min set to TLS 1.2, and I can connect just fine, although the certificate is signed with SHA-1.
Recall RC4. We now consider it broken. But it is still allowed on many servers, and even on 34.0.5 Firefox.
I agree, when one goes to disable legacy functionality, one should be prepared to suffer consequences. That's why my original question was "why".
Anyone who prefers AES-256 over AES-128 should take a basic cryptography course.
In fact, there are _more_ attacks against AES-256 thanks to the extended key schedule.
I disabled RC4 long time ago.
I'm running Firefox 36.0.4 on OS X 10.8.5. I see a "grey warning triangle" using Mozilla parlance. Clicking on that says "the connection to this website is not fully secure ...".
Firefox refuses to show me Intel's certificate at all. It does say "This website does not supply identity information".
How is an average user to know what to do if even a single application, e.g. Firefox, presents different messages to different users? IMO the message you received: "cannot guarantee the safety of your data" is much different than the one I got: "not fully secure". So which is it, and what is the difference?
Bah. Right now I switch to a separate OS X user for my banking and credit card sites. But it's probably better to devote an entire computer (not a VM) to access just those few sites. It's 2015 and things are worse and more confusing than ever.
In Chrome "https" is red and struck out: digitalsecurity.intel.com Identity not verified
No-one who runs a server which only accepts RC4 (!!) with no forward security, and SHA1 signatures, in 2015, should be giving security advice.
My daily driver browser has RC4 entirely disabled. This is one of the more amusing won't-connect sites I've found.
> sufficient for most things on unsecured connections
WPA2 + good TLS encryption (i.e., good cyphers) should be.
Just curious about your reasoning for why TLS alone isn't sufficient.
But also, there are plenty of sites around with broken TLS that can be intercepted by a man in the middle.
http://torrentfreak.com/which-vpn-services-take-your-anonymi...
The comments are probably as useful as the main content.
Personally I use AirVPN. They're not expensive, the client is open source, and performance seems good enough for casual use.
I'm not sure I'd trust any of the usual VPNs if I needed Snowden-level security. But I don't, so casual use is fine.
More in this thread: https://news.ycombinator.com/item?id=6345520
Not affiliated in any way, just a happy customer.
https://www.digitalocean.com/community/tutorials/how-to-set-...
- Have a dedicated email password that is different from every other password you use.
Let's be honest: You should have different passwords for every site, and you should use strong passwords and a manager, but you don't because you're a normal person. At the very least, be pragmatic and have an email password that's separate from every other service password. The idea being, if your random-service-you-signed-up-for-once.com password gets hacked, and your username was your email address, the first thing an attacker will try to do is use that password on your email. So have a strong email password and trust that your gmail account is less likely to be hacked than your random-service account password.
I still have my email passwords memorized, though.
This is honestly the best service I've ever paid for. It has never failed me, and it substantially improves my life.
They don't seem to realise though that their usual approach of sharing passwords over email, using the same password for several logins so it's easy to remember and using easy to remember passwords in general is much more insecure.
Services like LastPass make it practical for you to use impossible to guess passwords, different passwords for every site and let you share passwords securely.
I wish they would integrate with iOS8 Safari as an extension.
I'm surprised Google hasn't built it in to Chrome yet.
I'm not willing to load a proprietary blob that actively manipulates the dom and passwords every time I visit a page.
1 - use an iphone for all banking. It's the single hardest system for someone to install spyware on: they are more careful about which apps are in their store than android, and the apps are more isolated. Android apps often have spyware; android install prompts on websites are super sketchy (and cover 1/4 of the screen, perfect to trick older or unfamiliar users into installation), and the permissions are far less granular. Windows is a disaster for secure computing, from viruses to "install this to get 500 smiley faces" to flash with monthly zero-days to fake software installs advertised via google sem.
2 - use gmail, and use 2fa
3 - pay the $30 for the hardware login tokens for your brokerage (and ideally, banking) account
4 - don't use any wifi except home wifi; just use wireless
5 - NO, your friend/cousin/grandchild is not stranded in an airport in Europe
And, depending on how un-savvy you're talking about, I'd recommend just doing internet banking at your local bank. Just set all regular bills on auto, and configure your account to text you if something unusual happens (like your current account is running low). Then you should only really need internet banking a handful of times a year.
I realize that opinions on this differ, but I think that automatic bill payment is a horrible security practice.
Just last week I was paying with credit card in which the merchant punched in $5504 by accident instead of $504. Had I not noticed it right away, at least I'd get another chance to correct the error when my credit card bill arrived. With auto-pay, my bank account would have been emptied.
What would you do if some sort of auto pay error emptied your bank account? These things take time to resolve. What if it's a weekend, or a holiday, or you're traveling overseas, or the entity that caused the problem is on strike, or they want a written dispute from you?
Also, I started from the assumption of a non-technical person with "simple finances", so no credit card.
I also am not holding my breath for even the software 2FA since quite a few of my financial institutions won't even let me use punctuation in my password. Yes, the irony of implementing 2FA lowering the risk of a simple password isn't lost in me.
I'm amazed that people favor remembering passwords over using a password manager. With Firefox Sync, or the Chrome equivalent, you have your browser remember the password, every other browser you use syncs with that so it has the password, and you never need to have it memorized. The only thing that's missing for better usability is a built-in "generate and use a random secure password" mechanism.
If it doesn't sync, that means I can only get in from one computer, which is occasionally inconvenient.
So I keep my passwords in my brain, which is always with me, or at least with me at all the times when I might need to use a password.
For Firefox Sync, that entire list is encrypted using a client-side key in your browser, and the server has no access to the cleartext.
So for Facebook it can be "MYPASS" + "FACE"
And then it's easy to remember. Also you can substitute the first letter which allows it to a number or so
But if you were individually targeted i.e. a human attacker is looking at your password, your algorithm would provide access to many of your accounts with little effort.
I used to use this solution, btw, but have now gone to a unique, complex password per site with a password manager.
I had to replace my debit card this week because somebody halfway across the country tried to use it to buy $400 in gas. They probably bought it from one of the usual black markets, who acquired it from Lowe's, or Jimmy John's, or Sony, or god knows who else got hacked this week.
Yeah, definitely the people I want to talk to about security.
Very nice if so!
Also, it seems safer to write down your passwords. I mean, someone might physically take it, but that seems less likely than someone digitally taking it.
I usually use my google account to login to websites I care about (most sensitive websites I know provide this facility) and moderately strong but easy to remember passwords for non-critical websites that don't provide OpenID (e.g. a forum I never consult).
Of course I have 2FA on the google account and I feel rather safe.
Should I be worried?
The basic overview of how OpenID works is here: http://openid.net/pres/protocolflow-1.1.png
So if I understand this diagram correctly, you connect to the server that you want to log into. It determines whether or not you are authenticated (probably through cookies). If so, it redirects you to the OpenID server. The OpenID server checks your credentials and returns back to the original server. The diagram does not specify, but I'm guessing the OpenID server has a session cookie for your credentials so that you don't have to log in over and over again.
So what are the downsides?
1) The server you want to log in to knows about your OpenID. In other words they can potentially identify you and track you (possibly with the help of Google). 2) The OpenID server knows which sites you are going to and when you are logging into them. It can track all of your movements. I think it would be naive in the extreme to assume that Google does not do this ;-) 3) Without knowing more details I couldn't say, but I suppose it might open you up to Cross Site Request Forgery style attacks. My experience with Google code in this respect is that they are usually extremely thorough about this sort of thing, so I think this is unlikely on the OpenID side. In my sleepy state, I can't really think clearly enough to imagine whether or not there are ways to screw up the code in the server that uses OpenID, though.
My employer loves Google and we use a ton of Google services. I am lucky enough to have incredibly technically competent management and they understand the tradeoffs of having Google track everything we do. Because of that, I use OpenID for any other external service that my employer mandates/approves of. I'm pretty careful not to go to OpenID authenticated sites by clicking on links and open them directly, so I feel confident that I can avoid CSRF attacks even if they could be done.
I do not use OpenID for personal use. My employer may be happy to have me daily work activities tracked by Google, but as a private individual, I don't really want that. I use an offline password manager: http://www.passwordstore.org/
Also, as far as closed vs open source: http://keepass.info/
My take on password generation is even more straightforward:
Then whatever comes out, I store on an encrypted volume - so effectively I do have a master passphrase but none of the login credentials are derived from it. For sites that I think require even more entropy, I'll just bump up the number of bytes read. (98 = 72 bits of entropy, 128 = 96 bits)I haven't yet found a password manager I truly liked.
EDIT: you do realise you are capping the entropy of your per-site passwords at 72 bits? It's more than enough against all practical brute force attacks, but it also means that any entropy in your master key above 72 bits is effectively lost.
Yeah I realize it is being capped at 72 bits -- the main reason is that I've seen a bunch of websites that don't allow passwords longer than 18-20 characters or so. :-/
Source?
But to give some substance to the claim, the speed record for single-system password hashing in 2012 was ~350GH/s [0].
Let's assume that in 2015 a single system is capable of doing 1TH/s, or ~1000GH/s. So, 10^12 password attempts per second. An attacker, who is not a nation state, should be expected to have access to maybe 400 such systems. But to make this conservative, let's assume they have 1000 such systems. So, the attackers should be able to reach 1000 TH/s, or 10^15 attempts per second.
10^15 =~ 2^(15/0.301) =~ 2^50.
Hence, a determined attacker with finite resources has to do, on average, 2^31 seconds of work to brute force a password with 72 bits of entropy. 2^31 seconds is roughly 68 years.
That in turn means that there are lot of lower hanging fruit to pick before even thinking of expending resources to brute force passwords with 72 bits of entropy.
On the other hand, the resource requirements are getting awfully close to the realm of feasibility, so 72 bits might not be sufficient for long after all...
0: http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billi...
Every new sensible implementation of password store is using either bcrypt, pbkdf2 or scrypt.
I picked the lowest common denominator because it caters for the worst case scenario. Systems where passwords are improperly hashed are quite likely to have other security problems too. And as such are more likely to get breached, whereby their password store is lifted too.
I was off by 2^10. For some reason I kept thinking the 72 bits as 82 bits. You can even see that from the numbers!
So yes, 72 bits is not enough anymore. I stand corrected. New ballpark figure for sensible security margin should be 96 bits.
On the habits of practically unhackable people indeed.