221–230 of 434 posts
Earlier quoted context omitted.
> This attitude is cancer > yes really - fucking always You're really angry with that straw man you've stood up. The OP isn't saying systems have to be locked down to the extent that they're useless. Who would ever argue for such a thing? Note that "You don't stop securing it just because you've found one good option" is NOT the same thing as saying "You don't stop securing it until you've closed every possible secur…
The point is that it's a really bad tradeoff, because the impact to the users is high, and the impact to security is low. And yet we do it, because "You don't stop securing it just because you've found one good option", and that's a really bad reason to improve security by such a small increment with such large negative consequences. The problem with 'defense in depth' is that it comes as close as possible to locking…
Earlier quoted context omitted.
Hacker gets in, exfiltrates your log files that mistakenly have session tokens in them, goes through over the course of an hour or two before stumbling upon an admin session token that's still valid apparently. Could easily write a script to find the session tokens and check them for validity. Many have their TTLs directly embedded, no need to touch a server to check, at least for that.
If a hacker is able to exfiltrate log files, what's to prevent them from exfiltrating other things? If they get into a server, they could as well dump sensitive data form the database or do something to gain persistence, like installing a shell or adding their SSH key. If they get into a client device, they could steal more, more valuable data than just some logs — browser cookies, email credentials, app tokens, owne…
For example, if you're building a banking application, there's a huge monetary risk in allowing someone to potentially leave an open session on an unlocked shared computer.
Is this something that we could resolve with browser standards, for example the browser being able to provide some kind of a hint about how well secured the end user terminal is? Not cryptographic remote attestation or anything, just something simple like a header or API that would return some basic information such as whether the user has a screen lock with password enabled and whether the computer is a shared device or kiosk.
On Android, there is the KeyguardManager.isDeviceSecure method which provides this sort of functionality.
"Thank got we set the session timeout to 5 minutes, or we would have been compromised" - no one ever. I am in the 10-hour session timeout camp (or at least 4h, so you only have to authenticate twice a day). Session timeout checks are same sort of checkbox tests auditors (and pentesters) like, like password policy where you have to change it every 90 days. And about as effective. What's missing in the article is the d…
It really depends. I would certainly comment less often on HN if it logged me out at 4 hours. For my online banking it's okay if they kick me out after 15-30 min.
Earlier quoted context omitted.
> if you have any issues with your alternative authentication devices, you are completely locked out of your work You have printed the rescue codes when prompted, and have put that physical piece of paper into your wallet, haven't you?
That's a nightmare process for any normal user. There's no way the vast majority of people are savvy enough to do this correctly.
Earlier quoted context omitted.
If a hacker is able to exfiltrate log files, what's to prevent them from exfiltrating other things? If they get into a server, they could as well dump sensitive data form the database or do something to gain persistence, like installing a shell or adding their SSH key. If they get into a client device, they could steal more, more valuable data than just some logs — browser cookies, email credentials, app tokens, owne…
Permissions; if logs aren’t properly locked down that doesn’t mean everything is available.
> Also, it would be better to protect against this by securing the logs or using hard drive encryption. This one line is emblematic of the flaws in the article. My take on the article is, “Imagine that everything else in a system is done correctly, and the system, overall, is perfectly secure. In this imaginary world, short sessions don’t help.” One fact about security which you cannot avoid is that any one particula…
> Short sessions are there because there are various ways that sessions could be compromised. You haven't actually addressed either of the author's points, though. Namely: 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. 2: The vast majority of ways to compromise a session already give you access far beyond that session itself…
If we are talking about bounding the lifetime of a refresh token, I agree with the articles, but that is not what I think of when I think about credential expiry. Credentials that you send to third parties should be short lived. I think without that underlying distinction the article is dangerously confusing. Time-bound credentials have many useful features.
Earlier quoted context omitted.
The point is that it's a really bad tradeoff, because the impact to the users is high, and the impact to security is low. And yet we do it, because "You don't stop securing it just because you've found one good option", and that's a really bad reason to improve security by such a small increment with such large negative consequences. The problem with 'defense in depth' is that it comes as close as possible to locking…
The other thing security people fail to realize is that when you’re hostile to UX, people start coming up with all sorts of workarounds that leave you less secure than you were before. Like the corporate managed laptop is so full of spyware that users bypass it and use their own personal device for development.
Security folks are humans too.
We realize that every human loves convenience and security removes conveniences. Simple As.
No matter what we do as security folks, the users will do everything possible to return to their convenience or complain about the inconvenience until the security is removed.
I’m not saying there aren’t over zealous security folk but our goal isn’t to make humans lives harder. We want to make it harder for the bad guys to ruin humans lives.
Earlier quoted context omitted.
The point is that it's a really bad tradeoff, because the impact to the users is high, and the impact to security is low. And yet we do it, because "You don't stop securing it just because you've found one good option", and that's a really bad reason to improve security by such a small increment with such large negative consequences. The problem with 'defense in depth' is that it comes as close as possible to locking…
> The problem with 'defense in depth' No, that's a problem with bad engineering. That a process requires skills most people attempting it don't have isn't a problem with the process, it just means that it is hard and relatively new. One thing I see all the time that demonstrates this incompetence is talking about something being more or less "secure" without reference to a threat model. You simply can't make reasonab…
Hey - I completely 100% agree. Believe it or not, I did quite a stint in software security before becoming this jaded (5+ years fulltime work at a security focused product sold primarily to large fortune 100 companies [banks - it was all banks]).
I think my problem is that for any difficult challenge... there is an answer that is simple, obvious, and incorrect.
My opinion is that the incorrect answers I see most are the two extremes: I don't care about security (BAD!). I only care about security (WORSE!!!!).
The first will eventually lead to compromised accounts/data and that can kill a company. The second will lead to products no one wants to use, which WILL kill a company.
Neither is a good spot to be. You want to find an appropriate compromise in the middle: Secure enough.
----
Side note - no one truly does the threat assessments based on threat model because no one in industry likes the answers.
For small and inconsequential threats - you are already secure enough.
For nation states - there is likely no solution that is workable if the thing is on the internet.
It's like trying to buy a secure door for your house: For most folks walking down the street, the current door is fine. When the Gov shows up with tanks - there is no door you can buy to solve the problem.