Security Snake Oil Inc.
-
@Rhywden said in Security Snake Oil Inc.:
@Bulb Um, there's one small snag to your scheme: You cannot register a link between a website and an application without access to the website itself. Android will check if this URL exists and has the proper content:
https://domain/.well-known/assetlinks.jsonIf it doesn't, your app can register app-links all it wants, they simply won't be presented as a choice.
The documentation clearly says they will. The assetlinks makes them default, but as choice they will appear even without. On iOS their corresponding json is required for the registrations to work at all, but on Android it isn't.
-
@Bulb said in Security Snake Oil Inc.:
It isn't about simulating clicks, but about making user aim the finger to click something and redirecting them to the right site at the right moment. Yeah, clicking the always is two clicks, so it's unlikely to work in this case. But given enough tries, some users will probably misclick.
That's actually pretty hard to do. For one thing, as others stated, the app has to be installed, and the malicious app wouldn't be able to do that, so now you've gotta get a user to install the app and visit your site, and set it as default with a mis-click, which requires you to know which version and, in some cases, which manufacturer they're using, because that dialog is pretty frequently bikeshedded in Android updates (and manufacturer skins). And in Android 10+, they must not only mis-click, but then also select the app as default in another settings dialog after that one. In other words, getting a user to accidentally mis-click is a huge endeavor.
-
@sloosecannon They don't have to set the application as default, because opening it once in that redirect is enough for the hacker to get access to their account. But yes, it is a pretty complicated attack to pull off and does require significant luck with the user doing a bunch of mistakes. But again, users do mistakes, so it depends on the value of the target. For ours it definitely does not sound like worth it.
-
@sloosecannon said in Security Snake Oil Inc.:
the app has to be installed
For the huge majority of users, that means going through the main App Store, and the claimed URL metadata is one of the things that they check carefully. (There's an equivalent field for SMS messages I believe, so confirmation codes are handled more smoothly.) It might also need to be signed by the right authority for Android to pay any attention to that part of the metadata; after all, most apps that you'd ever want to side-load don't need this sort of stuff in the first place.
In short, this is an area where things are possible, but there are aggressive protective practices in place too.
-
This post is deleted!
-
@dkf said in Security Snake Oil Inc.:
the claimed URL metadata is one of the things that they check carefully
Can they be trusted to check anything carefully? Last I checked the applications became live immediately and then maybe some background checks would retract them.
@dkf said in Security Snake Oil Inc.:
It might also need to be signed by the right authority
I am fairly certain nothing ever expects the signing key to be signed with anything, and the signing key is totally arbitrary. The only requirement for it is that it must be the same for all versions of the same application (and since it cannot be rekeyed, it's a security joke).
-
-
@Bulb said in Security Snake Oil Inc.:
Can they be trusted to check anything carefully? Last I checked the applications became live immediately and then maybe some background checks would retract them.
That's declared in the manifest and part of the initial scan when you upload.
@Bulb said in Security Snake Oil Inc.:
I am fairly certain nothing ever expects the signing key to be signed with anything, and the signing key is totally arbitrary. The only requirement for it is that it must be the same for all versions of the same application (and since it cannot be rekeyed, it's a security joke).
Correct, the signing system just prevents an app with the exact same package name from being installed when it has a different signing key.
@dkf said in Security Snake Oil Inc.:
In short, this is an area where things are possible, but there are aggressive protective practices in place too.
yeah. And there are usually easier ways to achieve what you're trying to do - namely through social engineering...
-
@sloosecannon said in Security Snake Oil Inc.:
@Bulb said in Security Snake Oil Inc.:
Can they be trusted to check anything carefully? Last I checked the applications became live immediately and then maybe some background checks would retract them.
That's declared in the manifest and part of the initial scan when you upload.
It is, however, tricky to decide whether the declaration is legitimate or not. Navigations legitimately register for search links to various maps, there are alternate Facebook apps that I suppose register for facebook links etc.
@sloosecannon said in Security Snake Oil Inc.:
social engineering
This involves some social engineering as well.
… it's probably easier to persuade the users to install a “special highly secure browser” that actually siphons their credentials somewhere. And the application vendor can't do anything at all about that.
-
@Bulb sure, but that special browser won't intercept in-app HTTP requests. If the app launches the default browser to handle it, it will, but that's not guaranteed to work anyways...
-
@sloosecannon It will offer itself for opening the authentication dialog though (provided the app opens browser for authentication, which is the declared case for PKCS), or if the app is a web one (“spa”) as is actually my cases at the moment, the user might open it in that browser.
-
@pie_flavor said in Security Snake Oil Inc.:
@Shoreline My university has password requirements, all of which are lifted if it exceeds 16 characters. I think that's a good middle ground.
I like that.
-
@pie_flavor said in Security Snake Oil Inc.:
@Shoreline My university has password requirements, all of which are lifted if it exceeds 16 characters. I think that's a good middle ground.
Um. No. It continues to allow e.g. AAAAAAAAAAAAAAAAA ... or ABCEDFGHIJKLMNOPQ, both of which are extremely bad.
-
@Steve_The_Cynic It's not actually as bad as you think. Attackers are not going to jump directly to those passwords, they're going to attempt to exhaust the 15-characters-and-under-with-special-rules password space first, and that's got a lot of passwords in it. If the target implements any kind of defenses, that attack is untenable.
-
@TwelveBaud said in Security Snake Oil Inc.:
@Steve_The_Cynic It's not actually as bad as you think. Attackers are not going to jump directly to those passwords, they're going to attempt to exhaust the 15-characters-and-under-with-special-rules password space first, and that's got a lot of passwords in it. If the target implements any kind of defenses, that attack is untenable.
They will if they get common.
-
@TwelveBaud said in Security Snake Oil Inc.:
@Steve_The_Cynic It's not actually as bad as you think. Attackers are not going to jump directly to those passwords, they're going to attempt to exhaust the 15-characters-and-under-with-special-rules password space first, and that's got a lot of passwords in it. If the target implements any kind of defenses, that attack is untenable.
A typical rainbow book of passwords will include those plus the local equivalent of AZERTYUIOPQSDFGHJKLM and similar(1). About the only defense against a rainbow book attack is a "three strikes and you're (locked) out" rule, which is probably why mobile/cell phone unlock codes use it.
(1) Think about it this way: if there's a hard-edged relaxation rule like that, you (as an attacker, that is) have to figure that people will go long to make easier-to-remember and easier-to-type passwords. AZERTYUIOPQSDFGHJKLM works nicely for that - all the keys in left-to-right order on two rows of the keyboard. Such passwords will therefore figure way up high in a rainbow book for such a target.
-
@PleegWat said in Security Snake Oil Inc.:
They will if they get common.
Fortunately it is completely impossible to ever change the rules…
-
One way to get around such weakness would be to check the password against a dictionary when submitted (computationally easy since changing the password usually involves sending its cleartext to the server -- hopefully under SSL/TLS). If it's in the dictionary, reject it as "vulnerable to dictionary attacks".
-
So, funny story, I'm working on an IdP for a few friends (they want Discord OAuth but with additional claims like "must be a member of my guild/server/chatroom") and was about to start on auth for desktop apps, so I dug up more documentation. PKCS is still nothing within scope. PKCE, on the other hand, is an actual thing that verifies that the application that issued the authentication challenge is the same one that's asking for a bearer token (but without any validation of what that app is). It tries to fix the hole that applying this best practice has blown in it by a malicious app registering itself as handling your SPA entirely. (Which, as discussed, Android, iOS, and Windows require your cooperation to do silently, so there's that...) That said, you already shouldn't trust your SPA with anything sensitive.
Bottom line, tell your security insultants you're following best practices and they should go piss up a tree.
-
@TwelveBaud said in Security Snake Oil Inc.:
tell your security insultants
- It's not my security insultants, it is the ones on the web – the implicit grant is considered insecure and obsolete and blah blah blah.
- My situation is a bit different anyway. We have a customer who uses OAuth 1, won't switch to OAuth 2 (for
, but probably 
—they contracted us to rewrite some app that was too slow, but appear to have nobody maintaining the backend server at the time, so it has to be used as is), and I am trying to analyse whether using OAuth 1 and/or doing the app as an SPA (the old abysmally slow version was server-side JSP) creates any security risks.
-
@Mason_Wheeler said in Security Snake Oil Inc.:
A friend of mine likes to use an all-text password. It's seven words from an obscure poem in a foreign language.
Your friend isn't very good at this. No matter how good a password is, reuse will get you. It's only a matter of time before that password gets into a password dump. After that, any attacker with ten bucks to spend will try their dumped user/pass on every site they think of. Since user names are often email addresses, it will often work on the first try.
Back to the original snake oil comment - security is mostly about doing the fundamentals right. However, the fundamentals are plenty of work. The biggest thing people miss is knowing all of your dependencies and keeping track of security updates to them. You can spend all the time you want getting OAuth right, but sooner or later, the OAuth library you use will be found to have a weakness. Too many people go down the path of... I tried to update but one of the functions I call was removed and we forgot how to set that feature up in the test environment. They rationalize their way out of one update, then five, and eventually they're in too much technical debt to catch up.
-
@Jaime said in Security Snake Oil Inc.:
@Mason_Wheeler said in Security Snake Oil Inc.:
A friend of mine likes to use an all-text password. It's seven words from an obscure poem in a foreign language.
Your friend isn't very good at this. No matter how good a password is, reuse will get you. It's only a matter of time before that password gets into a password dump.
Worse than that: if it's "from an obscure poem" then it's probably in some corpus somewhere on-line and a good dictionary attack will get it easily.
-
@Planar, I wouldn't even worry about the absolute quality of the password. The problem is that people tend to pick a threat that they understand and beat that one to death, while getting pwned from every other angle.
Really weak password can be guessed online (someone can simply try to log in as you). Sorta weak password can't be guessed online unless the service is really horrible. Nearly everyone has some sort of throttling or lockout. So, for protection against simple password guessing, the bar is really low. Any amount of thought put into a password is "good enough" and doing better doesn't produce better results.
Weak, or even not very strong passwords can be retrieved from properly hashed dumps.
Strong passwords can't be retrieved from properly hashed dumps, but if the service provider makes a cryptographic error, or the actual password change mechanism is compromised, then password strength is irrelevant.
So, we have three attack scenarios:
- Someone tries to guess your password.
- The service provider has a system compromise, but did password security properly.
- The service provider has a system compromise, but didn't do password security properly.
Notice that if the service provide isn't compromised, any non-weak password is just fine. If the service provider is compromised, then strong passwords only help if the service provider didn't make a mistake. Since security mistakes are pretty much "business as usual" in the world today, I say that no amount of password strength provides very much benefit over a "weakly strong" password.
If you reuse passwords, then if any provider is compromised, all service providers can be breached.
So, non-reuse provides a significant incremental benefit and "building the perfect password" provides nearly none. Yet, I see a lot of discussion about better vs. worse passwords and little discussion about simply never, ever, ever, ever, reusing a password. Since you need a lot of them, you can't remember them, therefore you must have a password manager.
Web browsers seem to have finally built some tools to help users here. Chrome will now tell you that a password you are currently entering is already in a password dump and warn you not to use it. That's 1000 times more valuable than a password strength meter. Unfortunately, people don't understand what Chrome is saying - I constantly get reports from customers that Chrome told them that we had a compromise, but really Chrome was telling them that they were using their old LinkedIn password that every cyber criminal already knows. Chrome yelled at them, and they yelled at us for their own bad behavior!
-
@Jaime said in Security Snake Oil Inc.:
Your friend isn't very good at this. No matter how good a password is, reuse will get you. It's only a matter of time before that password gets into a password dump. After that, any attacker with ten bucks to spend will try their dumped user/pass on every site they think of. Since user names are often email addresses, it will often work on the first try.
Much like with banking, the real security isn't in having a secure password nobody can guess - it's in being able to contact the admin after someone guessed your password and being able to undo everything that was done. Therefore, the only password that really matters is the email password. And also online banking password, but a bit less so.
-
@Jaime said in Security Snake Oil Inc.:
It's only a matter of time before that password gets into a password dump.
My
oldsecurepassword (no longer in use as of 2017) has been in no less than 18 breaches.Nobody has used it, despite it being my initials and elementary school ID number (no joke, it's literally this).
Well, I should say, nobody used it after my Skype account got fuckered by someone. Still can't reset it because apparently I wasn't quite truthful in my account registration...
-
@Jaime said in Security Snake Oil Inc.:
I constantly get reports from customers that Chrome told them that we had a compromise,
To be fair, the message is extremely ambiguous and only happens on sites with said breached password sooooo.....
-
@Tsaukpaetra said in Security Snake Oil Inc.:
sooooo.....
Are you suggesting that the message implies we were the source of the breach? The only people that get this message are password-reusers and in those cases, it's like 99 out of 100 that the breach was somewhere else.
The message isn't intended to implicate any specific site, it's supposed to tell the user "it's time to stop using that password, it's broke". Any user that thinks the message means that my site has been breached didn't understand what Google was trying to tell them. I'm not concerned so much about being blamed (hey, it could have been me), I'm concerned that people are highly resistant to the message "don't reused passwords".
-
@Jaime said in Security Snake Oil Inc.:
@Tsaukpaetra said in Security Snake Oil Inc.:
sooooo.....
Are you suggesting that the message implies we were the source of the breach? The only people that get this message are password-reusers and in those cases, it's like 99 out of 100 that the breach was somewhere else.
The message isn't intended to implicate any specific site, it's supposed to tell the user "it's time to stop using that password, it's broke". Any user that thinks the message means that my site has been breached didn't understand what Google was trying to tell them. I'm not concerned so much about being blamed (hey, it could have been me), I'm concerned that people are highly resistant to the message "don't reused passwords".
Have you seen the message? Asking for a friend...
Edit: if you haven't, it looks like this;
This unclear verbiage, triggered by visiting specific site, does make the user believe that said site may have had that breach.
If it popped up at any other time not involving navigation (for example, upon browser start up and not as a tab-local modal dialog where site passwords are usually queried), I might be more inclined to believe it would be more as you say.
-
@Jaime said in Security Snake Oil Inc.:
@Tsaukpaetra said in Security Snake Oil Inc.:
sooooo.....
Are you suggesting that the message implies we were the source of the breach? The only people that get this message are password-reusers and in those cases, it's like 99 out of 100 that the breach was somewhere else.
The message isn't intended to implicate any specific site, it's supposed to tell the user "it's time to stop using that password, it's broke". Any user that thinks the message means that my site has been breached didn't understand what Google was trying to tell them. I'm not concerned so much about being blamed (hey, it could have been me), I'm concerned that people are highly resistant to the message "don't reused passwords".
Have you ever met users?
-
Shhhh. Please don't shatter his cute innocence.
-
@Zerosquare said in Security Snake Oil Inc.:
Shhhh. Please don't shatter his cute innocence.
I have it on good authority that the cute ones are the best.
-
@Bulb said in Security Snake Oil Inc.:
@hungrier Sorta
- When you try to phish enough users this way, some will take the bait even if by simply misclicking.
- I don't see how, but maybe somebody could make the user click, some time in advance, the always option with some trick like this (see here for more detailed discussion).
Neither the trick site nor the explanation describe how exactly he's trying to demonstrate his point:
He has a site that shows itself to be some weird banking site, but then it immediately cuts away (opens a full-page frame, I guess) to a "game" site with a button that says "click me"; when you click it, another "click me" button appears in a different location. This repeats a few times, during which, the site tracks how quickly the user moves the mouse and how long it takes the user to click on the button. Once it figures that it has a good prediction, it will show the last button over the location where the "send all my money to a scammer" button from the weird banking site's page, and then at the last moment, it will switch back to it so the user would click on the scam button instead of the last "click me" button.
-
@djls45 said in Security Snake Oil Inc.:
opens a full-page frame, I guess
No. Just navigates there and then back. The point is getting around the frame restrictions.
@djls45 said in Security Snake Oil Inc.:
Neither the trick site nor the explanation describe how exactly he's trying to demonstrate his point
I understood it from the description.
