Close enough security
-
@remi Do people even read NIST security guidelines?
Passwords longer than 15 characters, 2fa for important things/people, not in HIBP, and no expiration date. For a standard it's not stupid.
At my old job we had constant 'arguments' about this. I would say "hey check the NIST guidelines, they even have reasons why there" "Oh I don't trust that."
-
@AyGeePlus said in Close enough security:
Do people even read NIST security guidelines?
Short answer? No.
Longer answer: most people probably don't even know they exist.
-
@AyGeePlus said in Close enough security:
Do people even read NIST security guidelines?
Not until they've aged appropriately. Getting rid of expiring passwords is still pretty new for this sort of thing.
-
@boomzilla The science behind them (which again, cited in the guidelines) is pretty clear, and fairly old.
This is computers. Stuff comes at you fast.
-
@AyGeePlus said in Close enough security:
@boomzilla The science behind them (which again, cited in the guidelines) is pretty clear, and fairly old.
This is computers. Stuff comes at you fast.
You can't rush bureaucracy.
-
@boomzilla First, you have to accept the obvious arguments laid out in front of you, or at least read them.
This isn't my lounge bitching thread, so I'll leave it at that.
-
@levicki said in Close enough security:
If you are entering website passwords manually in the 21st century instead of using say KeePass and Kee plugin (or some other password manager preferrably not cloud-based) then you are
.AKA "putting all your eggs in the same basket". It's very convenient until the basket gets stolen and you lose everything.
your user doesn't have administrator rights, right? Because if it does, then you are
.
-
@Zerosquare Which is why I never use e-mail apps, etc.* on my smartphone: Everything sensitive is opened in a (passworded) private session on the browser, and when outside I log out as soon as I'm done. And my phone is of the kind that ejects the battery when dropped.
*Especially e-mail apps, which usually lack an option not to memorize your password, on account of needing it to check for new mail every X minutes.
-
@Medinoc said in Close enough security:
And my phone is of the kind that ejects the battery when dropped.
I'm not sure if this actually helps. I've got the impression that Android et.al. save app state to non-volatile memory on a regular basis due to RAM congestion.
But I'm a proponent of the drop-eject design anyway, since it has other uses.
-
@Gąska said in Close enough security:
phonetic transcription (Polish language has nearly 1-1 mapping between sounds and letters) to protect against dictionary attacks.
For the same reason, I have been known (to myself, mainly) to spell words I use as a password according to their pronunciation in my local dialect of Dutch rather than following standard spelling.
-
@acrow said in Close enough security:
@Medinoc said in Close enough security:
And my phone is of the kind that ejects the battery when dropped.
I'm not sure if this actually helps. I've got the impression that Android et.al. save app state to non-volatile memory on a regular basis due to RAM congestion.
But I'm a proponent of the drop-eject design anyway, since it has other uses.
The way I understood it, his point about the battery was that his phone
isn't a smartphoneis Old As Fuck
-
@topspin I honestly don't know. Does a Galaxy S5 mini count as "old as fuck" nowadays?
-
@Medinoc No, I wrongly assumed you meant much older than that.
-
@Medinoc said in Close enough security:
@topspin I honestly don't know. Does a Galaxy S5 mini count as "old as fuck" nowadays?
Isn't anything not made in a year considered Old As Fuck
? 
-
@Medinoc said in Close enough security:
@topspin I honestly don't know. Does a Galaxy S5 mini count as "old as fuck" nowadays?
Hey, we've got the same phone!
It's... tolerably ancient, yes. I'd still continue using it, but I just got issues with the backlight on the bottom 1/3 of the screen. Looking for a replacement now.
-
@Zerosquare said in Close enough security:
@hungrier said in Close enough security:
Their guideline is the Principle of Most Surprise
It's a bit self-defeating, since when you've been working with npm for a while, nothing surprises you anymore.
Sanity. It might even scare the ingrained Node dev witless... If there would happen to be any wit left.
-
Galaxy S5 mini
backlightI thought all the Galaxy S phones had AMOLED screens, even back to 2009 or whenever that line started
-
@Zerosquare It makes some sense if you consider "rootkit" to be a driver.
-
@error "rootkit" sounds more like some kind of malware than some kind of driver.
-
@Medinoc said in Close enough security:
Especially e-mail apps, which usually lack an option not to memorize your password
Thunderbird has that. I mean, it will remember during that session. But it won't remember if you close/reopen unless you check the checky. Me? Yeah, I'm screwed if someone gets access to my logged in account...
-
@_P_ said in Close enough security:
@error "rootkit" sounds more like some kind of malware than some kind of driver.
Yet they require the same privileges and functionality; really, the only thing distinguishing them is intent.
-
Sure, you can do more bad stuff with admin rights. But you can already do a lot of bad stuff with standard user rights.
A strong barrier between user stuff and admin stuff makes sense when you're a sysadmin running a multi-user machine. What matters is preventing a malicious or careless user from compromising the system for everyone else ; user accounts can be zapped, and their data restored from backup, but reinstalling the system is a major pain.
For single-user personal computing, it's much less clear-cut. Reinstalling the system is not the main problem there.
-
@Zerosquare said in Close enough security:
Sure, you can do more bad stuff with admin rights. But you can already do a lot of bad stuff with standard user rights.
A strong barrier between user stuff and admin stuff makes sense when you're a sysadmin running a multi-user machine. What matters is preventing a malicious or careless user from compromising the system for everyone else ; user accounts can be zapped, and their data restored from backup, but reinstalling the system is a major pain.
For single-user personal computing, it's much less clear-cut. Reinstalling the system is not the main problem there.
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights. That is, the user is theoretically unable to compromise the security of their main online-banking tool, and a clean/secure browser session will remain as stated on the label.
Unfortunately, this doesn't really work for normal users, since they'll gleefully install every trojan horse, with admin rights. Since there is no way to install stuff without admin rights in Windows, even though most stuff doesn't need them. Or, well, if the maker of the installer is thoughtful, there is a way. I've seen some FOSS installers make use of it. But trojan horses are not thoughtful.
@hungrier said in Close enough security:
Galaxy S5 mini
backlightI thought all the Galaxy S phones had AMOLED screens, even back to 2009 or whenever that line started
That would explain why the "backlight" failure is so clearly limited to one section of the screen. Like a line had been drawn across the screen; only the bottom 1/3. And I think it's somehow connected to PWM dimming, since the failure mode is: Flickering and erratic brightness fluctuation when the screen is dimmed below a certain threshold (while phone is used in low-light environments).
-
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights. That is, the user is theoretically unable to compromise the security of their main online-banking tool, and a clean/secure browser session will remain as stated on the label.
Except in practice, you don't need to alter the binary: merely running a malicious piece of Javascript, or displaying some content that exploits a bug in a parsing library, is enough to compromise the browser. And you don't need admin rights for that. Focusing on them is using an outdated model.
-
@Zerosquare said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights. That is, the user is theoretically unable to compromise the security of their main online-banking tool, and a clean/secure browser session will remain as stated on the label.
Except in practice, you don't need to alter the binary: merely running a malicious piece of Javascript, or displaying some content that exploits a bug in a parsing library, is enough to compromise the browser. And you don't need admin rights for that. Focusing on them is using an outdated model.
Again, if you start a clean session, and browse straight to your bank, then those are not an issue, and only the purity of the browser binary matters (INB4: and certificate cache). Unless the bank's page is compromised, in which case every security consideration is moot anyway.
-
Except a malware could install itself as an extension, so even if the binary is unchanged and you bothered to start a clean session, you could still be running malicious code. At this point, you may as well use another browser just for banking: it would be more secure and not more inconvenient.
-
@acrow said in Close enough security:
It's... tolerably ancient, yes.
I've got a Samsung R451c. It's a slider phone that used to be able to access the internet, though it wouldn't run most scripts and it wouldn't display most media other than jpeg images. I think even the supported CSS was only a limited subset. It ultimately stopped being able to access the internet at all (including the Samsung app/media store) when site certification was standardized a few years ago. So now the only network functionality that works includes, exhaustively, phone calls, SMS texting, and MMS media messaging, but as individual messages, not as "conversations," like smartphones today do. And the MMS messages cannot contain anything other than audio, static image, and text. Emojis, animated images, and videos are out.
-
@Zerosquare Don't browsers disable extensions in Secure Mode (tm)? Not that it matters if the extension does other worming and trickery, true. This may be a (small) part of why Chrome disabled extensions in favor of blacklists.
Remember how Morbs complained about the difficulty of installing multiple copies of the same browser side-by-side? You'd really have to use another browser.
...Say, would another user-account work just as well? OS is supposed to isolate users from each other, so extensions wouldn't affect other users on the same machine.
-
@djls45 said in Close enough security:
wouldn't run most scripts
I disabled javascript on my phone anyway. It didn't get any updates whatsoever in the first 2 years, so, low-hanging fruit and all that...
-
@acrow said in Close enough security:
@Zerosquare Don't browsers disable extensions in Secure Mode (tm)? Not that it matters if the extension does other worming and trickery, true.
Firefox recently did, but there is a setting to override this on a per-extension basis.
@acrow said in Close enough security:
...Say, would another user-account work just as well? OS is supposed to isolate users from each other, so extensions wouldn't affect other users on the same machine.
I guess so. But I'd probably use a VM. Nowadays they're pretty painless, and you get an extra level of isolation.
-
@acrow said in Close enough security:
Remember how Morbs complained about the difficulty of installing multiple copies of the same browser side-by-side? You'd really have to use another browser.
...Say, would another user-account work just as well? OS is supposed to isolate users from each other, so extensions wouldn't affect other users on the same machine.
If all you care about is separating extensions, I think on Firefox having multiple profiles should work instead of having multiple copies of Firefox.
-
@Zerosquare said in Close enough security:
At this point, you may as well
use another browser just for bankingforbid users from performing any actions on their PCs: it would be more secure and not more inconvenient.
-
@Zerosquare said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights. That is, the user is theoretically unable to compromise the security of their main online-banking tool, and a clean/secure browser session will remain as stated on the label.
Except in practice, you don't need to alter the binary: merely running a malicious piece of Javascript, or displaying some content that exploits a bug in a parsing library, is enough to compromise the browser. And you don't need admin rights for that. Focusing on them is using an outdated model.
Exploits exist that can get around security measures, but that doesn't mean throw out all the security measures
-
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights.
Chrome quite happily installs itself in a directory that doesn't require admin privileges to do anything to it.
-
@hungrier said in Close enough security:
Exploits exist that can get around security measures, but that doesn't mean throw out all the security measures
I didn't mean "throw out all security measures" ; I meant "those security measures may not be as useful as you think in practice". Kinda like spending a lot to secure your house's front door, but not thinking about the easy-to-break window.
-
@levicki said in Close enough security:
But Chrome also cannot alter anything which requires admin rights (such as files in Windows folder or root of C:\ drive, or registry entries).
True, but if your goal is to fuck with the user's browser and you've not got admin privileges then I'm sure the sufficiently creative person can still do something. It's even easier if your target already uses Chrome and doesn't have admin privileges so has installed it as a normal user.
-
@levicki said in Close enough security:
Anyone can take my AES-256 encrypted .kdbx file, but good luck opening it given that password key derivation function was tuned to have the number of iterations which take 1 second for one password guess on my PC (hint: that's quite a lot of iterations).
Until the day you get hit by a piece of malware that includes a keylogger. Then you're fucked.
@Zerosquare said in Close enough security:
You are wrong on that one.If you run as admin user, Javascript just has to escape the sandbox and it has full access to everything.
If you run as limited user, Javascript must chain another vulnerability (privilege escalation) to sandbox escaping to be able to do some real damage.Nowadays, you can do some real damage by compromising just the browser, because more and more stuff is done thru sites or webapps: e-mail, banking, etc.
-
@levicki said in Close enough security:
But Chrome also cannot alter anything which requires admin rights (such as files in Windows folder or root of C:\ drive, or registry entries).
Wrong. Extensions can do that.
Also, Chrome can issue an UAC prompt when required, which will cause elevated right if user clicks "Allow". And you know most users will click it. After all, it's just a harmless little Chrome, how much damage can it cause? Might as well throw in some phishing web pages to tell user to "install an extension to prove you're not a robot".
-
@Zerosquare said in Close enough security:
But I'd probably use a VM. Nowadays they're pretty painless, and you get an extra level of isolation.
In practice, yes. (Although the "painless" is debatable.)
But in theory, it's counterproductive, because the virtual machine disk, and thus the browser binary, sits in the userspace. I know it's an unlikely-to-ever-get-exploited vulnerability, since it will never catch on with the hoi polloi. But for posterity, I'd like to point that out.
-
@topspin said in Close enough security:
@acrow said in Close enough security:
Remember how Morbs complained about the difficulty of installing multiple copies of the same browser side-by-side? You'd really have to use another browser.
...Say, would another user-account work just as well? OS is supposed to isolate users from each other, so extensions wouldn't affect other users on the same machine.
If all you care about is separating extensions, I think on Firefox having multiple profiles should work instead of having multiple copies of Firefox.
No, I meant for a clean browser session with no chance of extension trojan trickery, as far as the OS is intact kind of separation. We were assuming that the extensions had found a way to change browser functionality at runtime in such a way that the browser's own sandboxing was compromised. Or at least I was.
@loopback0 said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights.
Chrome quite happily installs itself in a directory that doesn't require admin privileges to do anything to it.
Do you mean it allows to install, or by default installs in such a location?
-
@acrow said in Close enough security:
@loopback0 said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights.
Chrome quite happily installs itself in a directory that doesn't require admin privileges to do anything to it.
Do you mean it allows to install, or by default installs in such a location?
AFAIK it does so by default, or at least it always does it when a non-administrator user downloads it.
-
@Medinoc said in Close enough security:
@acrow said in Close enough security:
@loopback0 said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights.
Chrome quite happily installs itself in a directory that doesn't require admin privileges to do anything to it.
Do you mean it allows to install, or by default installs in such a location?
AFAIK it does so by default, or at least it always does it when a non-administrator user downloads it.
Ubiqutousness at the cost of security. Hah... Should have seen it coming.
-
@acrow said in Close enough security:
@loopback0 said in Close enough security:
@acrow said in Close enough security:
For single-user systems, the main point of the separation would be that the browser binary can only be altered with admin rights.
Chrome quite happily installs itself in a directory that doesn't require admin privileges to do anything to it.
Do you mean it allows to install, or by default installs in such a location?
So long as you're not installing the "Enterprise" build, or from the one bundled with Adobe Reader, then yes, it default installs to %AppData%.
