|
|
#
?
Aug 19, 2016 10:17
|
|
|
|
| # ? May 9, 2024 23:01 |
|
|
The point about allowing unicode made me recall this tangentially related hack: https://labs.spotify.com/2013/06/18/creative-usernames/
|
|
#
?
Aug 19, 2016 11:55
|
|
|
Or this. http://apple.stackexchange.com/questions/202143/i-included-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite
|
|
#
?
Aug 19, 2016 14:50
|
|
|
TheFluff posted:The point about allowing unicode made me recall this tangentially related hack: https://labs.spotify.com/2013/06/18/creative-usernames/ Unicode in passwords has kind of the opposite problem. Say you wanted to use the character 'ñ' in your password. The problem is, there are two different 'ñ's: U+00F1 by itself (ñ), and a U+006E followed by a U+0303 (ñ). They're semantically identical, but they will produce totally different hash values. While that's an easy problem to solve, there are a ton of edge cases in Unicode that can make passwords fail to match up. For instance, there's a modifier character for certain emoji that lets you change the skin color. Some systems could strip out that character, resulting in an entirely different password. For the Web in particular, you have to rely on browsers and servers using consistent and correct implementations of Unicode, or your users could get locked out when their browser updates. Double Punctuation fucked around with this message at 14:54 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 14:51
|
|
|
dpbjinc posted:Unicode in passwords has kind of the opposite problem. Say you wanted to use the character 'ñ' in your password. The problem is, there are two different 'ñ's: U+00F1 by itself (ñ), and a U+006E followed by a U+0303 (ñ). They're semantically identical, but they will produce totally different hash values. While that's an easy problem to solve, there are a ton of edge cases in Unicode that can make passwords fail to match up. For instance, there's a modifier character for certain emoji that lets you change the skin color. Some systems could strip out that character, resulting in an entirely different password. For the Web in particular, you have to rely on browsers and servers using consistent and correct implementations of Unicode, or your users could get locked out when their browser updates. Interesting. I use characters like é in my passwords because of Quebec and speaking a minimally acceptable level of French, and I haven't run into this!
|
|
#
?
Aug 19, 2016 16:16
|
|
|
ItBurns posted:Or this. Stories like this are amazing.
|
|
#
?
Aug 19, 2016 17:03
|
|
|
I'm trying to see where NIST says password expiration is out (like it says in the Sophos blog) and I'm not finding it. The draft says that authenticators SHOULD expire (800-63b-6.2). Sophos blog also has a thing saying KBA is out, but the draft says it's acceptable for identify verification. I think Sophos misinterpreted 'no expiration without reason,' although those words don't appear anywhere in the draft either so it's like whoever wrote the blog misunderstood someone who actually read the draft. wyoak fucked around with this message at 17:56 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 17:49
|
|
|
i mean expiration with no reason is still dumb. encourages dumb things love2016 love20161 love20162 love20163 at least with reason you can be like "you shouldn't use any part of your old password, because someone might have found it out!" Daman fucked around with this message at 18:54 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 18:50
|
|
|
Any password complexity requirements from the last decade would stop something like that. I'd still recommend expiration on a corporate AD since the users are going to register accounts with their work email and use the same password, so force them to change your side so you're more likely to leak an old password that doesn't work any more. The one exception would be if you managed to implement 100% 2FA for anything externally accessible, then drop password expiration because who cares. If you're providing some kind of web service then password expiration is likely counterproductive, either get out of credentials entirely with facebook/openauth or only force password expiration when you know something bad happened. Let the users handle it at their own discretion from there.
|
|
#
?
Aug 19, 2016 19:25
|
|
|
I wasn't arguing for/against password expiration, just saying that NIST's draft doesn't seem to match what Sophos is saying in their summary. NIST says that using an expired authenticator should specify that expiration is the reason for failure, Sophos seems to have telephone-gamed that into "No expiration without reason" -> "Passwords don't need to expire." Now, NIST does use the verbage SHOULD instead of SHALL, so maybe that's what they're referring to?
|
|
#
?
Aug 19, 2016 19:33
|
|
|
Regular expiration is still good because of PtH attacks imo Even better if you use something like TPAM or CyberArk
|
|
#
?
Aug 19, 2016 19:35
|
|
|
wyoak posted:I wasn't arguing for/against password expiration, just saying that NIST's draft doesn't seem to match what Sophos is saying in their summary. NIST says that using an expired authenticator should specify that expiration is the reason for failure, Sophos seems to have telephone-gamed that into "No expiration without reason" -> "Passwords don't need to expire." If they use verbiage similar to RFCs then SHALL = do this to be in spec SHOULD = you don't have to do this, but we really recommend it.
|
|
#
?
Aug 19, 2016 19:38
|
|
|
flosofl posted:If they use verbiage similar to RFCs then Yeah if I hadn't already bored myself reading specs I'd track down the old version and compare the verbiage but meh
|
|
#
?
Aug 19, 2016 19:53
|
|
|
ChubbyThePhat posted:These are excellent rules. correct horse battery staple was right
|
|
#
?
Aug 20, 2016 17:25
|
|
|
Diceware FTW. Just pick a length that suits your particular application.
|
|
#
?
Aug 20, 2016 22:18
|
|
|
Is Linux actually any more secure in design than Windows? Is it more secure in practice just due to attacks targeting Windows having a higher return on investment? This is for personal use, not enterprise. What Antivirus should I use on Fedora? 
|
|
#
?
Aug 21, 2016 02:19
|
|
|
I'd argue that the highly modular design of Linux in general is better practice. That plus the open nature of the source code makes it easier to identify and address security issues.
|
|
#
?
Aug 21, 2016 02:25
|
|
|
Windows and Linux are no different in terms of how "secure" they are but certain things are approached differently in each.
|
|
#
?
Aug 21, 2016 05:01
|
|
|
22 Eargesplitten posted:Is Linux actually any more secure in design than Windows? https://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels#In-kernel_security
|
|
#
?
Aug 21, 2016 06:48
|
|
|
When comparing Linux with the NT kernel, I'd say Linux has a slight lead due to the LSMs and the monolithic architecture (less bad drivers, since there's less of a need for third-party drivers). Comparing Windows with OSs using Linux, I'd say Windows, primarily because Windows handles authorization based on what an application is trying to do, not what the application is. With Linux, you are either a user or an administrator, but you can run specific programs as an administrator even if you are a user. With Windows, you can hand out certain rights to users without giving them full administrative privileges in any application. Overall, though, they're fairly comparable, and it's more a matter of preference. Unless you're talking about GUIs, in which case, all I'll say is stay the gently caress away from X.Org as root. It's trash and has been for a decade. Wayland can't come fast enough.
|
|
#
?
Aug 21, 2016 07:07
|
|
|
dpbjinc posted:With Linux, you are either a user or an administrator, but you can run specific programs as an administrator even if you are a user. With Windows, you can hand out certain rights to users without giving them full administrative privileges in any application. this isn't true. Linux supports capabilities and MAC too
|
|
#
?
Aug 21, 2016 14:28
|
|
|
dpbjinc posted:When comparing Linux with the NT kernel, I'd say Linux has a slight lead due to the LSMs and the monolithic architecture (less bad drivers, since there's less of a need for third-party drivers). Comparing Windows with OSs using Linux, I'd say Windows, primarily because Windows handles authorization based on what an application is trying to do, not what the application is. With Linux, you are either a user or an administrator, but you can run specific programs as an administrator even if you are a user. With Windows, you can hand out certain rights to users without giving them full administrative privileges in any application. Overall, though, they're fairly comparable, and it's more a matter of preference.
|
|
#
?
Aug 21, 2016 16:33
|
|
|
ratbert90 posted:This is so wrong it's anti-right at this point. SELinux does support contexts, that's how it's designed. Then again, SELinux. Very capable apparently, also very complex. I remember few years ago I decided to give SELinux a go, and not just disable it like i usually do (this is my home computer, I don't manage computers at my work). It worked for almost 6 months. SELinux would tell me what it blocked and how to enable it if I want to. Until one day I hit a wall. If I remember correctly it was lighttpd related, but whatever SELinux was suggesting was simply not working. Many hours of googling later I simply gave up. I had a thing to do and gently caress SELinux. Went back and disabled it and did what I had to do. drat that thing. They probably have books about it, but unless I would need to manage enterprise computers I wouldn't worry about it too much.
|
|
#
?
Aug 21, 2016 16:50
|
|
|
Volguus posted:Then again, SELinux. Very capable apparently, also very complex. I remember few years ago I decided to give SELinux a go, and not just disable it like i usually do (this is my home computer, I don't manage computers at my work). It worked for almost 6 months. SELinux would tell me what it blocked and how to enable it if I want to. Until one day I hit a wall. If I remember correctly it was lighttpd related, but whatever SELinux was suggesting was simply not working. Many hours of googling later I simply gave up. I had a thing to do and gently caress SELinux. Went back and disabled it and did what I had to do. drat that thing. 99% of the time running: grep "denied" /var/log/audit/audit.log |audit2allow -M $NAME will solve your problem. https://www.youtube.com/watch?v=cNoVgDqqJmM FlapYoJacks fucked around with this message at 17:27 on Aug 21, 2016 |
|
#
?
Aug 21, 2016 17:23
|
|
|
Info sec people, let's have a show of hands. Would you react badly if you conducted a P-o-C for a product and the vendor passed you data that had been completely scrubbed of any identifying detail? If not, would you react badly if the report covered criminal activity and the vendor asked you to pay for the detail?
|
|
#
?
Aug 22, 2016 09:36
|
|
|
Oh you're saying that they did a PoC and gave you the results that show criminal behavior from their tool, but won't show you what the problem is unless they pay for it? That's kinda hosed up, honestly. Nevermind showing management a win without even purchasing the tool and almost guaranteeing the purchase, now they want to withhold data that can prove the criminal activity actual took place and verify that the tool worked correctly. gently caress em. Take the data they give you and do your own investigation into who did what. Who is it? I'll put them on my vendor ignore list. Mustache Ride fucked around with this message at 12:32 on Aug 22, 2016 |
|
#
?
Aug 22, 2016 12:15
|
|
|
Mustache Ride posted:
let me  first.
|
|
#
?
Aug 22, 2016 13:38
|
|
|
ming-the-mazdaless posted:Info sec people, let's have a show of hands. I'd react badly if the report contained no details even without it showing criminal activity if I had a vendor in to do a PoC. I have them immediately remove their poo poo and start looking for another product (and hunt down said activity based on what was left in the report). I'd also let them know exactly why you're kicking them out.
|
|
#
?
Aug 22, 2016 14:01
|
|
|
Does anyone here work in Australia particularly in anything Government related? Have a few potential questions
|
|
#
?
Aug 25, 2016 12:09
|
|
|
Whatsapp is sharing user data (phone numbers, hardware fingerprints, etc.) with Facebook.
|
|
#
?
Aug 25, 2016 17:14
|
|
|
Whatsapp was bought by facebook 2? years ago now, you can't be surprised.
|
|
#
?
Aug 25, 2016 17:34
|
|
|
It's as if a company wants to integrate a product they bought for billions into their own. The horror! Also if you're using your fingerprint to unlock your phone, security is taking a backseat in your mind anyway.
|
|
#
?
Aug 25, 2016 17:35
|
|
|
I think he was talking about hardware fingerprints like user agents and device metadata, not your actual fingerprint. At least I hope he was, how the hell would whatsapp have access to your stored fingerprint info?
|
|
#
?
Aug 25, 2016 18:00
|
|
|
Mustache Ride posted:I think he was talking about hardware fingerprints like user agents and device metadata, not your actual fingerprint. The thing about WhatsApp is that the conversations are kept private but there is no expectation that the meta data is. I am not sure why ItBurns fails to grasp the difference between the two.
|
|
#
?
Aug 25, 2016 18:02
|
|
|
Back in the day the messages weren't even encrypted. They were stored in a plaintext database on the iPhone and relied solely on the iPhone's encryption to protect it (hah!). I haven't had to run a forensic case on an iPhone in a while, I wonder how much that has actually changed.
|
|
#
?
Aug 25, 2016 18:08
|
|
|
CLAM DOWN posted:Whatsapp was bought by facebook 2? years ago now, you can't be surprised. Don't be obtuse. It's a relevant development and a significant reversal of their position (and a few poster's own positions) with regard to sharing identifying info with FB and by proxy advertisers and law enforcement where the (now) encrypted messages can be stored until/if an attack on the encryption is found. OSI bean dip posted:Also if you're using your fingerprint to unlock your phone, security is taking a backseat in your mind anyway. You misread this, but I use the tip of my penis so the joke's on them!
|
|
#
?
Aug 25, 2016 18:11
|
|
|
ItBurns posted:Don't be obtuse. It's a relevant development and a significant reversal of their position (and a few poster's own positions) with regard to sharing identifying info with FB and by proxy advertisers and law enforcement where the (now) encrypted messages can be stored until/if an attack on the encryption is found. I'm not being obtuse, you simpleton. I'm saying I'm not surprised, and you shouldn't be either.
|
|
#
?
Aug 25, 2016 18:19
|
|
|
Mustache Ride posted:Back in the day the messages weren't even encrypted. They were stored in a plaintext database on the iPhone and relied solely on the iPhone's encryption to protect it (hah!). I haven't had to run a forensic case on an iPhone in a while, I wonder how much that has actually changed. Realistically the important thing here is not what is being done with the data at rest but what is being done with the data in transit. If the data is not being encrypted in transport, then there is little need to go and try and get your hands on your target's device. However, if you got your hands on the target's device, then what's to stop them from doing things like extracting the data out of memory or if the device is already unlocked? The iPhone is an example of where this is a problem, but it hasn't stopped the FBI in the past if the circumstances are right (this is not the secure enclave stuff). ItBurns posted:Don't be obtuse. It's a relevant development and a significant reversal of their position (and a few poster's own positions) with regard to sharing identifying info with FB and by proxy advertisers and law enforcement where the (now) encrypted messages can be stored until/if an attack on the encryption is found. What does it matter? You're using a third-party messaging application operated by a company that has a profit incentive. At the very least they encrypt the traffic going through their servers and there is no expectation that the meta data is obfuscated anyway.
|
|
#
?
Aug 25, 2016 18:23
|
|
|
OSI bean dip posted:What does it matter? You're using a third-party messaging application operated by a company that has a profit incentive. At the very least they encrypt the traffic going through their servers and there is no expectation that the meta data is obfuscated anyway. pr0zac posted:Watching the traffic will also let you confirm WhatsApp isn't some how sending something out of band. Whatsapp is run almost completely separately from Facebook, they aren't on the same infrastructure or even the same campus (frankly they kinda hate FB and do everything in their power to remain separate). It should be pretty obvious to see if something is going to a Facebook server directly. OSI bean dip posted:I'd be careful about challenging pr0zac on this one here because he actually knows a thing or two more about WhatsApp than most here.
|
|
#
?
Aug 25, 2016 18:30
|
|
|
|
| # ? May 9, 2024 23:01 |
|
|
Great so what does this have to do with infosec? Your privacy is a different subject entirely and you can go yell about it in D&D.
|
|
#
?
Aug 25, 2016 18:31
|
|
