Who would have thought?
-
I''ll just leave it here:
-
Well, serves people well for trusting Samsung.
You want to trust Apple. Apple's good for you, Apple will always protect you and treat you well.
Filed under: remember, children
-
@kt_ said in Who would have thought?:
Apple will always protect you and treat you well.
So what you're saying is it won't give me up, run around and desert me?
-
I'm shocked! Shocked, I tell you!
... It seriously took this long?
-
@Scarlet_Manuka said in Who would have thought?:
I'm shocked! Shocked, I tell you!
... It seriously took this long?
Yeah, given their love of plaintext passwords floating around everywhere.
Bonus WTF: If you have a S Health account, you can crash their servers by using a password with special characters and choosing to delete your account. I am basically unremovable now.
-
@NeighborhoodButcher said in Who would have thought?:
you can crash their servers by using a password with special characters and choosing to delete your account
QF
-
@NeighborhoodButcher They don't call it "Open" Auth for nothing.
-
@Onyx said in Who would have thought?:
@kt_ said in Who would have thought?:
Apple will always protect you and treat you well.
So what you're saying is it won't give me up, run around and desert me?
It's never gonna make you cry, never gonna say goodbye, never gonna tell a lie and hurt you.
-
@flabdablet said in Who would have thought?:
@NeighborhoodButcher They don't call it "Open" Auth for nothing.
What really pisses me off is that Google wants everybody to use this shit for everything, to the extent where they're telling everybody that IMAP over SSL with a strong password is "less secure" because not a "modern security standard".
-
@NeighborhoodButcher said in Who would have thought?:
@Scarlet_Manuka said in Who would have thought?:
I'm shocked! Shocked, I tell you!
... It seriously took this long?
Yeah, given their love of plaintext passwords floating around everywhere.
Bonus WTF: If you have a S Health account, you can crash their servers by using a password with special characters and choosing to delete your account. I am basically unremovable now.
They obviously interpreted "special" in a very special way.
-
Hey, I just thought it! We should never trust Koreans with our houses. Yup, we shouldn't. We should just build a wall, a tall wall around our houses. A wall so high that none of those pesky little Koreans will be able to go over it. They're small and we're smart. It's gonna be easy.
-
@flabdablet said in Who would have thought?:
What really pisses me off is that Google wants everybody to use this shit for everything
Done right, OAuth is fine. It's delegating the authentication problem to a separate server (simplifying the security management challenge) and then you just use the system you care about with a bearer token. Over SSL, because anything else is just dumb.
But it only really works well for HTTP-based protocols due to the complexity of the handshake required to establish the bearer token. Other techniques are required for IMAP, and in reality a strong password over SSL is about as good as you actually need. Security delegation is a horribly complicated area bedevilled with the usual problems of unclear threat models, security nazi assholes who hate users, and utter cluelessness all round.
The best technique I know is enabling client-side certificates for SSL. Though annoying as heck to set up, they're trivial to use after that and are extremely strong. Anyone who's used RSA keys with SSH has been using (a minor variation on) this.
-
@dkf said in Who would have thought?:
But it only really works well for HTTP-based protocols due to the complexity of the handshake required to establish the bearer token.
One implementation I had run across forced me to change a configuration setting on my server because the default config simply didn't accept GET requests longer than 256 characters.
Which is kind of too short when you seemingly put a whole javascript file of 4 kiloBytes into the request string.
-
@dkf said in Who would have thought?:
Done right, OAuth is fine.
Point is that it has more potential failure modes than strong-password-over-TLS, and is not a whit more resistant to any kind of attack. When Google dismisses IMAP over TLS as "less secure" they're completely full of shit.
-
@flabdablet said in Who would have thought?:
is not a whit more resistant to any kind of attack.
I'm not convinced. It's just that the amount of difference is rather marginal from an immediate end-user perspective. It's the dragging in of the whole camel caravan of HTTP and HTML and Javascript that I object to…
-
@flabdablet said in Who would have thought?:
When Google dismisses IMAP over TLS as "less secure" they're completely full of shit.
If you mean their grumpy attitude to e.g. Outlook 2016 (apparently it isn't "modern", which I suppose is true, seeing as how it's a proper desktop application), it's because Outlook starts in clear-text on the IMAPS port and then switches to TLS. (My IPS firewall - a real one, in a separate box - wouldn't let the connection through until I gave those connections special permission to do this.)
-
The researchers further found that 42 percent of apps were granted privileges they never asked for. Such overly broad permissions violate a core security tenant known as the least privilege principle.
@vaire you can come out now, we know you're in there
-
@flabdablet Let's all repeat the following mantras:
-
Security is a process, not a program.
-
Secure applications aren't secure without secure operating systems. Secure operating systems aren't secure without secure practices. Secure practices aren't secure without secure applications.
-
A chain is as strong as its weakest link.
-
The most common point of failure is the user.
-
95% of all cracking is predicated on social engineering.
-
Even the smartest and most competent users, administrators, and developers make security mistakes all the time, and the best you can hope to do is have a safety net in place to catch as many of them as possible before they cause a security hole..
-
-
@Steve_The_Cynic said in Who would have thought?:
it's because Outlook starts in clear-text on the IMAPS port and then switches to TLS
Thunderbird doesn't do that, yet Gmail won't let it log in until you allow "less secure apps".
-
About the original vulnerability....
To be fair, most people's front door locks aren't very secure. I would bet that fewer people could get into a house that switched from a $20 hardware store lock to one of these smart locks. As an added benefit, the smart lock has hope of being made stronger over time.
My front door lock is bump resistant, but it can be raked by someone who has a bit of skill. Since it uses the most common blank on earth, it can be duplicated from a photograph.
-
@flabdablet said in Who would have thought?:
Thunderbird doesn't do that, yet Gmail won't let it log in until you allow "less secure apps".
Neither does KMail. Given that and shit I ranted about getting introduced in Inbox I agree with the slightly tinfoil-worthy statement about Google trying to kill IMAP.
-
@Onyx said in Who would have thought?:
@flabdablet said in Who would have thought?:
Thunderbird doesn't do that, yet Gmail won't let it log in until you allow "less secure apps".
Neither does KMail. Given that and shit I ranted about getting introduced in Inbox I agree with the slightly tinfoil-worthy statement about Google trying to kill IMAP.
And they want it to die probably because they can't ship ads over IMAP without editing people's email, which is likely to be considered a no-no. (I'd consider it a no-no. Adlessness is part of why I use IMAP-bearing software to read GMail, the other part being that I can have all my inboxes in one place.) Shame really, because IMAP is very common and reasonably functional, but its concept of folders doesn't match Google's concept of labels, which has the disvirtue of looking enough like folders that it makes *GMail* look bad.
-
@ScholRLEA said in Who would have thought?:
- The most common point of failure is the user.
aka: the easiest algorithm for cracking passwords is a combination of one or more of:
- A $5 wrench
- A length of rubber hose
- A vial of sodium pentathol and a syringe.
- A large square man patting a baseball bat suggestively.
None of which help, of course, if you want to keep the crack secret.
-
@Steve_The_Cynic Quite so. For that you'll want access to an offshore detention facility.
-
@Steve_The_Cynic said in Who would have thought?:
@ScholRLEA said in Who would have thought?:
- The most common point of failure is the user.
aka: the easiest algorithm for cracking passwords is a combination of one or more of:
- A $5 wrench
- A length of rubber hose
- A vial of sodium pentathol and a syringe.
- A large square man patting a baseball bat suggestively.
None of which help, of course, if you want to keep the crack secret.
Actually, the best tools for cracking usually turn out to be
- a janitor's jumpsuit and a fake security badge
- a calm voice over the phone (or a screamingly hysterical pop-up on your monitor) telling the target that their computer has been compromised and that they need to provide their password and credit card number in order to fix it
- the victim's greed
That last one? Yeah, there are still plenty of people who fall for various kinds of advance fee scams every day, both online and in real life. Not to mention more sophisticated things like Ponzi schemes and who knows what else.
-
@Buddy said in Who would have thought?:
The researchers further found that 42 percent of apps were granted privileges they never asked for. Such overly broad permissions violate a core security tenant known as the least privilege principle.
@vaire you can come out now, we know you're in there
-
@Vaire tenant (should be tenet)
-
@Buddy said in Who would have thought?:
@Vaire tenant (should be tenet)
-
@Rhywden IE didn't (and probably still doesn't) support URLs over 2083 characters in the first place.
-
@Rhywden said in Who would have thought?:
@dkf said in Who would have thought?:
But it only really works well for HTTP-based protocols due to the complexity of the handshake required to establish the bearer token.
One implementation I had run across forced me to change a configuration setting on my server because the default config simply didn't accept GET requests longer than 256 characters.
Which is kind of too short when you seemingly put a whole javascript file of 4 kiloBytes into the request string.
That's a side effect of the standard not setting a limit and then turning around and telling you not to use URIs longer than 255 characters:
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
Did the server at least return a
414 Request-URI Too Long
error so you knew what was happening?
-
@powerlord said in Who would have thought?:
Did the server at least return a
414 Request-URI Too Long
error so you knew what was happening?The way things usually work, you get a
200 OK
, a504 OK
or a500 Did you know I can taste the color blue?
…
-
@dkf said in Who would have thought?:
The way things usually work, you get a 200 OK, a 504 OK or a 500 Did you know I can taste the color blue?…
And you know you're really fucked when you get
418 I'm a teapot
.
-
@asdf said in Who would have thought?:
And you know you're really fucked when you get
418 I'm a person
.HTFY.
-
@asdf meh, just send a
BREW
orPOST
and wait for the tea
-
@flabdablet said in Who would have thought?:
@flabdablet said in Who would have thought?:
@NeighborhoodButcher They don't call it "Open" Auth for nothing.
What really pisses me off is that Google wants everybody to use this shit for everything, to the extent where they're telling everybody that IMAP over SSL with a strong password is "less secure" because not a "modern security standard".
It won't even let me visit that page with 2FA enabled.
-
@ben_lubar Don't get me started on mandatory 2FA. Especially from companies like Apple, who will not let me set an Apple ID password to
dszlj.pdxid.jenpo.mghgq.uslfx
but are perfectly fine withApple123
.
-
@flabdablet said in Who would have thought?:
@Steve_The_Cynic said in Who would have thought?:
it's because Outlook starts in clear-text on the IMAPS port and then switches to TLS
Thunderbird doesn't do that, yet Gmail won't let it log in until you allow "less secure apps".
Update: Thunderbird 38+ now supports OAuth2 authentication for Gmail, and I've seen it work.
-
http://www.businessinsider.com/samsung-shifts-from-smartphones-to-software-2016-5
I cannot wait for them to ditch Android and adopt Tizen :) Nice timing to switch my phone, now which one will have Android?
-
@dkf said in Who would have thought?:
Done right, OAuth is fine.
Its former project leader disagrees with you.
-
@flabdablet said in Who would have thought?:
supports OAuth2 authentication for Gmail
Supporting it for one site is easy enough if you've browser-like capabilities and a user immediately available.
-
@flabdablet said in Who would have thought?:
disagrees with you.
Does he, though? The claim was that done right, OAuth is [secure]. The link you gave agrees:
To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation.
It's just far too easy to do it wrong.
-
@Yamikuronue said in Who would have thought?:
It's just far too easy to do it wrong
because 2.0 is more of a guideline than an actual spec. Implementing it securely means inventing about half the things, or crossing your fingers and hoping Facebook got it right.
-
@flabdablet said in Who would have thought?:
Implementing it securely means inventing about half the things, or crossing your fingers and hoping Facebook got it right.
Or whatever other ID Provider you choose to integrate with. Because you can't do it generically; you have to do different damn fuckery for each one. Because of course you do.
Security delegation is a swamp, complete with crocodiles, malaria and lost cannibal tribes.
-
@flabdablet said in Who would have thought?:
@ben_lubar Don't get me started on mandatory 2FA. Especially from companies like Apple, who will not let me set an Apple ID password to
dszlj.pdxid.jenpo.mghgq.uslfx
but are perfectly fine withApple123
.
-
I still think it's lame idea to use "smart devices" for anything that is not supposed to require network connection to work.
When I was in secondary school, one of my classmates got his desktop hacked by some script kiddies. They guy controlled his CD-ROM and made the tray repetitively eject and load which is annoying but not every harmful.
However, you shouldn't want to see that in one night, when you go home, you found the lights in your home keeps switching on and off because some random folks get control of your "smart devices".
-
Strong passwords
Apple policy requires you use strong passwords with your Apple ID. Your password must have 8 or more characters and include upper and lowercase letters, and at least one number. You can also add extra characters and punctuation marks to make your password even stronger. Apple also uses other password rules to make sure your password isn't easy to guess.
Using a strong password is the most important thing you can do to help keep your account secure. If you aren’t sure if you have a strong password, visit your Apple ID account page to reset your password as soon as possible.
dszlj.pdxid.jenpo.mghgq.uslfx
fails:
Apple123
now fails as well! Booyah! Security upgrade!
Oh wait.
And this massively secure new password variant would be... what?
-
@flabdablet What? The same password suddenly became more secure?
-
@Jaloopa said in Who would have thought?:
The same password suddenly became more secure?
Not exactly the same. Replaced the L in Apple with a 1.
-
@ChaosTheEternal Oh, I was thrown off by the shitty font
-
@Jaloopa That's my 1337 infosec skillz at work.