> the company hopes to see 'Iron Man' suits deployed in the field by 2015.
Yes! THAT'S how you win 'the heart and minds' of the conquered:
Prisoner: "What did you do with my donkey?"
Army guy: "Oh...Iron Joe here threw it out of the way while we were storming your house. But don't worry...it should come down to earth any minute now..."
> > the simple precaution of displaying the last date, time, and location from which I (putatively) logged in.
> Gmail displays this information in the footer of the page.
Yes, and that's the wrong place for it. New e-mails are on top and if your list is set to 100 (or 200) you'll never have a need to scroll down. It needs to be obvious. Ergo: on top! Google...u listening?
> Example: excluding the dictionary-based, If your system obliges you to change your password every 2 months - 1 day, when the attacker finally breaks the old password it's no longer valid.
Except there's a fundamental error in that argument:
The attacker doesn't have to search the entire key space to finally hit the password. Only half of it on average. In fact, he can get lucky and hit it in a couple hours! So you have no idea and that 2 months policy is worthless!
And that's not even getting into the question of how to determine the time it takes to crack a password, even if 100% key space search in brute-force mode were necessary. What's the possible tries per second reference? Your laptop? The corporate network clustered? distributed.net? The NSA?
Only way to be sure...given today's knowledge and computing power...is to pick (for high-sec apps) a password of at least 128-bit strength, since it's currently agreed upon as being completely outside the realm of possibility for anyone to crack. YMMV:-)
> Weak passwds rejected, mild passwds say 30 days, medium passwds 60-90 days, strong passwds 180-360 days, and impenetrable passwds should not require changing.
I like it. Might not be that easy to test for though.
> Impenetrable = >= 16 characters, mixed case, numerals, punctuation, and passing all dictionaries.
Personally I *hate* all that mixed character crap and only use lower-case characters, so I don't have to hit Shift or otherwise contort my fingers. Rather make it longer but a lot easier to type:
16 random characters from entire ASCII set (95) = 105 bits (you'd need 21 to reach 128-bit security) 16 random characters from lower-case letters (26) = 75 bits (you'd need 28 to reach 128-bit security)
Not that much of a difference. Even 75 bits would suffice for most applications.
More characters to type overall, but probably the best trade-off for entry speed, recall ability and security is the Diceware approach. 10 random words = 128+ bit.
Use KeePass anyway for the multitudes of Logins or even a simple: vim -x my_passwords.txt (:set cryptmethod=blowfish )
Good suggestions and am with you on self-signed certs.
For 1 there is the Perspectives plugin (FF). Close to what you want. Basically it polss SSL sites and their certs from several locations and throws up a warning, if the cert presented to your session is not what they have seen the past few weeks or so. (If I understand it correctly)
For 2 you will love the CertificatePatrol plugin. Does exactly what you want. Even throws a big warning, if just the CA changed.
Such things should be in the browser proper, IMHO. But then...by way of plugin perhaps it makes it there.
> if you have a system that's susceptible to MitM > attacks and doesn't throw up huge red flags > whenever there's a possibility of it, then the > users will get complacent and not notice that > their browser's icon is yellow instead of green > like it should be
OK...I am not opposed to warnings where they are warranted and sensible. But if we talk security it should be more like this:
> if you have a system that's susceptible to MitM > attacks and doesn't throw up huge red flags > whenever there's a possibility of it, then the > users will get complacent and not notice that > their browser's icon is yellow instead of green > like it should be
OK fine. I am not opposed to warnings, where they are needed and sensible. Let's do the following:
For each HTTP page you request = 2 warnings For each HTTPS page (unauthenticated) = 1 warning For each HTTPS page (authenticated) = 0 warning
> People with the most common form of colour > blindness can't tell the difference between green > and red.
Good point! How about a visual feedback, that everybody knows even better than traffic lights:
unencrypted plain-text HTTP::-( encrypted, unauthenticated HTTPS::-/ encrypted and authenticated HTTPS::-)
I am serious! There could be a bunch of different options for just such a security-status feedback (chosen via Preferences)...why limit ourselves to just one. I'm just throwing ideas around... All I know is, that anything even remotely like that will work infinitely better for 99% of people, than some technical mumbo-jumbo text as in current browser warnings.
> I'll leave you in charge of the communication and > education campaign so that John Q Public gets the > message reliably then!
John Q Public isn't getting the message now! All s/he usually knows is click Next until the page displays. We assume, that there is some inherent or trained "sense-of-security" with users. Fact is, there isn't. Especially not with the multiple innocuous SSL-Errors, like expired certs, misconfigured (shared) domains etc.pp.. I fully believe, SSL, while nice in concept, to be an almost total failure. Certainly so, when even with no errors you still can't say reliably, that your session isn't MITM'd by your friendly.gov certs, signed by one of the countless companies your browser "trusts". There has got to be a better way!
> I don't think I really see much benefit from > allowing self-signed stuff more easily, > particularly when an unauthenticated > certificate could be the indicator of an attack
An indicator, which you don't even have with plain-text HTTP! Therefore common sense only allows for treating unauthenticated but encrypted sessions not any differently (no warnings) than HTTP! You can still differentiate and provide info via colors, like I described, or whatever...
> Is it secure? Is it bollocks. MITM is perfectly possible. To the extent that in our arms-race-at-starbucks scenario where the hacker has done his ARP spoofind and DHCP, > you just add an MITM proxy for SSL connections. Done, your self-signed certs are now useless.
You're right. And yet this "It's gotta be perfect or it's gotta be nothing at all!" attitude is IMHO what has held crypto back a lot more than necessary. Regardless of crypto and its setup, it's still just one part of a security chain...a chain, which even in the best of circumstances will NEVER achieve 100% security! So let's cut the scare-mongering and focus on not black or white, but lovely hues of security degrees. Something people already know (traffic lights):
> Until something changes with either the browsers or the signing process, we'll never see 100% SSL use
It'd be great to use PGP/GPG's Web-of-Trust also for SSL sites. So if you have a trust path in your e-mail to the CEO of a company, that company's SSL site would also be accepted on the same terms. After all, people make/run web sites and people use them!
> Because certs from "trusted by default" organizations are ridiculously expensive.
Aside from the money, the "trusted by default" organizations will not only be 'trusted' with the actually intended SSL-site, but equally 'trusted' for the 'officially' signed TLA MITM certificate. It's 2am...do you know where your Gmail certificate comes from?
Yes, there is an SSL-page for login. After login it the re-directs to the main/. page (http). So far so good except...I am still NOT logged in! Anybody know, what the deal is with that?
Hmm...I get a warning thrown up by the SSLPasswdWarning FF plugin (actually on the hotmail-redirected login.live.com):
Warning!!! The password field you have selected will transmit your information over an unencrypted and insecure connection. The form submits to: UNKNOWN (or handled in Javascript)
Anybody verified, that this actually gets handled via SSL (in JS or whatever)?
In God# mode, however, touch(1) works. Therefore, God is blind and he doesn't see, if you install the Slapper rootkit and give yourself permissions for touch(1) and eject(1). What He don't know, won't blind you! So go ahead and don't worry about it.:-)
> > People in the ISS staring back at Earth while a huge asteroid wipes off the planet killing off all mammals > > would probably say "yup... that's some nice ROI.. good investing".
> They'd be able to say that for a few weeks or months, anyway...
I'd be so pissed, if the other astronauts on board were only guys!:-)
Personally I love the idea of firesheep (although it's not new...just user-friendly). That said, I can't wait for e-mail sheep, instant message sheep, sms sheep etc.pp.. I'd like to see Terrabytes of peoples conversations using any of those ways posted publicly. Ditto for voice (phone) conversations. Post it, post it and post it again. Until even the last grandma understands the realities of electronic communication and *wants* to encrypt.
People lock their doors because they perceive of getting a benefit from it (lock door = kids & stuff inside are safer). All we need is for them to extend the same mindset to online interactions with people. For that to happen, they need to perceive a *real* threat that they can look at themselves "Mom? I just found a hot chat you did while away for your business trip on Google. Dad is PISSED and who's David anyway?!" Imagine, if people saw their last 300 e-mails posted on Usenet....
I don't ever want to see anything again, why Johnny can't encrypt. I want Johnny to slap me in the face if I even suggest he contact me without encrypting!
> > SSL has, potentially, been seriously compromised in that some fairly dodgey entities are trusted issuers > > from the perspective of the vast majority of consumer browsers, etc.
> Now that I'm curious, who are the dodgey entities?
Slashdot Mirror
> the company hopes to see 'Iron Man' suits deployed in the field by 2015.
Yes! THAT'S how you win 'the heart and minds' of the conquered:
Prisoner: "What did you do with my donkey?"
Army guy: "Oh...Iron Joe here threw it out of the way while we were storming your house. But don't worry...it should come down to earth any minute now..."
> > the simple precaution of displaying the last date, time, and location from which I (putatively) logged in.
> Gmail displays this information in the footer of the page.
Yes, and that's the wrong place for it. New e-mails are on top and if your list is set to 100 (or 200) you'll never have a need to scroll down. It needs to be obvious. Ergo: on top! Google...u listening?
> Example: excluding the dictionary-based, If your system obliges you to change your password every 2 months - 1 day, when the attacker finally breaks the old password it's no longer valid.
Except there's a fundamental error in that argument:
The attacker doesn't have to search the entire key space to finally hit the password. Only half of it on average. In fact, he can get lucky and hit it in a couple hours! So you have no idea and that 2 months policy is worthless!
And that's not even getting into the question of how to determine the time it takes to crack a password, even if 100% key space search in brute-force mode were necessary. What's the possible tries per second reference? Your laptop? The corporate network clustered? distributed.net? The NSA?
Only way to be sure...given today's knowledge and computing power...is to pick (for high-sec apps) a password of at least 128-bit strength, since it's currently agreed upon as being completely outside the realm of possibility for anyone to crack. YMMV :-)
> Weak passwds rejected, mild passwds say 30 days, medium passwds 60-90 days, strong passwds 180-360 days, and impenetrable passwds should not require changing.
I like it. Might not be that easy to test for though.
> Impenetrable = >= 16 characters, mixed case, numerals, punctuation, and passing all dictionaries.
Personally I *hate* all that mixed character crap and only use lower-case characters, so I don't have to hit Shift or otherwise contort my fingers. Rather make it longer but a lot easier to type:
16 random characters from entire ASCII set (95) = 105 bits (you'd need 21 to reach 128-bit security)
16 random characters from lower-case letters (26) = 75 bits (you'd need 28 to reach 128-bit security)
Not that much of a difference. Even 75 bits would suffice for most applications.
More characters to type overall, but probably the best trade-off for entry speed, recall ability and security is the Diceware approach. 10 random words = 128+ bit.
Use KeePass anyway for the multitudes of Logins or even a simple: :set cryptmethod=blowfish )
vim -x my_passwords.txt
(
> Duke Nukem Forever would ship before RHEL 6
Actually Duke Nukem Forever is included in RHEL6 as Easter Egg ;-)
> Red Hat server licensing is pricier than Windows Server licensing
Apparently Red Hat is also revamping their licensing conditions to some extent. Check with them if under the new options you can get a better deal...
Good suggestions and am with you on self-signed certs.
For 1 there is the Perspectives plugin (FF). Close to what you want. Basically it polss SSL sites and their certs from several locations and throws up a warning, if the cert presented to your session is not what they have seen the past few weeks or so. (If I understand it correctly)
For 2 you will love the CertificatePatrol plugin. Does exactly what you want. Even throws a big warning, if just the CA changed.
Such things should be in the browser proper, IMHO. But then...by way of plugin perhaps it makes it there.
3rd try (what's with /. ?):
If talking security it should be more like this:
unauthenticated plain-text HTTP page = 2 warnings
unauthenticated encrypted HTTPS page = 1 warning
authenticated encrypted HTTPS page = 0 warning
/. ate my post, I think. Sorry if my response gets double-posted...
> if you have a system that's susceptible to MitM
> attacks and doesn't throw up huge red flags
> whenever there's a possibility of it, then the
> users will get complacent and not notice that
> their browser's icon is yellow instead of green
> like it should be
OK...I am not opposed to warnings where they are warranted and sensible. But if we talk security it should be more like this:
unauthenticated plain-text HTTP page = 2 warnings
unauthenticated encrypted HTTPS page = 1 warning
authenticated encrypted HTTPS page = 0 warning
> if you have a system that's susceptible to MitM
> attacks and doesn't throw up huge red flags
> whenever there's a possibility of it, then the
> users will get complacent and not notice that
> their browser's icon is yellow instead of green
> like it should be
OK fine. I am not opposed to warnings, where they are needed and sensible. Let's do the following:
For each HTTP page you request = 2 warnings
For each HTTPS page (unauthenticated) = 1 warning
For each HTTPS page (authenticated) = 0 warning
I am glad you're sure about that! ;-)
> People with the most common form of colour
> blindness can't tell the difference between green
> and red.
Good point! How about a visual feedback, that everybody knows even better than traffic lights:
unencrypted plain-text HTTP: :-( :-/ :-)
encrypted, unauthenticated HTTPS:
encrypted and authenticated HTTPS:
I am serious! There could be a bunch of different options for just such a security-status feedback (chosen via Preferences)...why limit ourselves to just one. I'm just throwing ideas around...
All I know is, that anything even remotely like that will work infinitely better for 99% of people, than some technical mumbo-jumbo text as in current browser warnings.
> I'll leave you in charge of the communication and > education campaign so that John Q Public gets the > message reliably then!
John Q Public isn't getting the message now! All s/he usually knows is click Next until the page displays. We assume, that there is some inherent or trained "sense-of-security" with users. Fact is, there isn't. Especially not with the multiple innocuous SSL-Errors, like expired certs, misconfigured (shared) domains etc.pp.. I fully believe, SSL, while nice in concept, to be an almost total failure. Certainly so, when even with no errors you still can't say reliably, that your session isn't MITM'd by your friendly .gov certs, signed by one of the countless companies your browser "trusts". There has got to be a better way!
> I don't think I really see much benefit from
> allowing self-signed stuff more easily,
> particularly when an unauthenticated
> certificate could be the indicator of an attack
An indicator, which you don't even have with plain-text HTTP! Therefore common sense only allows for treating unauthenticated but encrypted sessions not any differently (no warnings) than HTTP! You can still differentiate and provide info via colors, like I described, or whatever...
> Is it secure? Is it bollocks. MITM is perfectly possible. To the extent that in our arms-race-at-starbucks scenario where the hacker has done his ARP spoofind and DHCP,
> you just add an MITM proxy for SSL connections. Done, your self-signed certs are now useless.
You're right. And yet this "It's gotta be perfect or it's gotta be nothing at all!" attitude is IMHO what has held crypto back a lot more than necessary. Regardless of crypto and its setup, it's still just one part of a security chain...a chain, which even in the best of circumstances will NEVER achieve 100% security! So let's cut the scare-mongering and focus on not black or white, but lovely hues of security degrees. Something people already know (traffic lights):
Browser location bar is:
Red: unencrypted plain-text HTTP
Yellow: encrypted, unauthenticated HTTPS
Green: encrypted and authenticated HTTPS
Just a suggestion.
> Until something changes with either the browsers or the signing process, we'll never see 100% SSL use
It'd be great to use PGP/GPG's Web-of-Trust also for SSL sites. So if you have a trust path in your e-mail to the CEO of a company, that company's SSL site would also be accepted on the same terms. After all, people make/run web sites and people use them!
Combine with DNSSEC at your leisure.
> Because certs from "trusted by default" organizations are ridiculously expensive.
Aside from the money, the "trusted by default" organizations will not only be 'trusted' with the actually intended SSL-site, but equally 'trusted' for the 'officially' signed TLA MITM certificate. It's 2am...do you know where your Gmail certificate comes from?
http://pastebin.com/raw.php?i=M2MUEdv4
Fire up your rainbow tables :-)
In recent threads about Firesheep in regards to Slashdot I had seen several times the suggestion to use:
https://slashdot.org/my/login
Yes, there is an SSL-page for login. After login it the re-directs to the main /. page (http).
So far so good except...I am still NOT logged in! Anybody know, what the deal is with that?
> https://www.hotmail.com/
Hmm...I get a warning thrown up by the SSLPasswdWarning FF plugin (actually on the hotmail-redirected login.live.com):
Warning!!!
The password field you have selected will transmit your information over an unencrypted and insecure connection.
The form submits to:
UNKNOWN (or handled in Javascript)
Anybody verified, that this actually gets handled via SSL (in JS or whatever)?
> So quit touching your device. You'll go blind.
That's the advantage of being raised catholic:
$ touch /dev/myself0
touch: cannot touch `/dev/myself0': Permission denied
Everything's still nice and clear.
In God# mode, however, touch(1) works. Therefore, God is blind and he doesn't see, if you install the Slapper rootkit and give yourself permissions for touch(1) and eject(1). What He don't know, won't blind you! So go ahead and don't worry about it. :-)
> > People in the ISS staring back at Earth while a huge asteroid wipes off the planet killing off all mammals
> > would probably say "yup... that's some nice ROI.. good investing".
> They'd be able to say that for a few weeks or months, anyway...
I'd be so pissed, if the other astronauts on board were only guys! :-)
Personally I love the idea of firesheep (although it's not new...just user-friendly). That said, I can't wait for e-mail sheep, instant message sheep, sms sheep etc.pp.. I'd like to see Terrabytes of peoples conversations using any of those ways posted publicly. Ditto for voice (phone) conversations. Post it, post it and post it again. Until even the last grandma understands the realities of electronic communication and *wants* to encrypt.
People lock their doors because they perceive of getting a benefit from it (lock door = kids & stuff inside are safer). All we need is for them to extend the same mindset to online interactions with people. For that to happen, they need to perceive a *real* threat that they can look at themselves "Mom? I just found a hot chat you did while away for your business trip on Google. Dad is PISSED and who's David anyway?!"
Imagine, if people saw their last 300 e-mails posted on Usenet....
I don't ever want to see anything again, why Johnny can't encrypt. I want Johnny to slap me in the face if I even suggest he contact me without encrypting!
> > SSL has, potentially, been seriously compromised in that some fairly dodgey entities are trusted issuers
> > from the perspective of the vast majority of consumer browsers, etc.
> Now that I'm curious, who are the dodgey entities?
Edit / Preferences / Advanced / Encryption / View Certificates / Authorities
Your welcome!
> SSL has not been compromised.
We agree!
Your NSA :-)