|
Everybody who has Comcast has it deployed at home. For years now.
|
#
?
Mar 25, 2018 09:14
|
|
|
|
| # ? May 25, 2024 02:50 |
|
|
Nalin posted:Everybody who has Comcast has it deployed at home. For years now. Yeah, not on Comcast. Anyway, my whole point was that if a poor guy with a bunch of aging kit like me could handle having it working with all his kit, then there was no reason for bigger orgs not to.
|
|
#
?
Mar 25, 2018 10:01
|
|
|
What would you guys say are the minimum requirements for verifying someone's ID over a telephone or live chat support systems before giving account info, rebooting servers, etc.? I can't seem to convince the people I work with that address + last 4 digits of CC# is insanely bad but maybe I'm the rear end in a top hat. Apologies if this is opsec or something.
|
|
#
?
Mar 25, 2018 13:21
|
|
|
Have a method of generating a one-time support PIN from the admin control panel of your portal that verifies to phone agents that the person on the phone has access to the online account. If people lock themselves out of the online account and none of the recovery methods work then maybe the phone agents can call back one of a predetermined list of contact numbers stored on the account. If it's gone really wrong then have the customer submit statements showing payments to you and some form of ID to reset access, with a grace period that includes sending notification emails to people listed on the account to let them know what's going to happen and how to flag it as fraudulent. I think you have to treat people logged into the account as legit and then work to ensure that's as secure as possible rather than trying to bolt on another layer of verification if somebody opens a live chat. If people get into our AWS account then they can just delete all the services on our account, but that would be our own fault if we just used simple password verification, and I'd expect Amazon to be able to pick up on an attack on their authentication system. Thanks Ants fucked around with this message at 13:34 on Mar 25, 2018 |
|
#
?
Mar 25, 2018 13:31
|
|
|
Thanks, it's nice to know I'm not low-grade freaking out over something everyone else agrees is adequate. Everything you described is basically what the last DC I worked at did, but this one just went from a NOC to a SOC and I feel like nobody has even thought this through. Kinda embarrassing.
|
|
#
?
Mar 25, 2018 14:13
|
|
|
Paper Triangle posted:What would you guys say are the minimum requirements for verifying someone's ID over a telephone or live chat support systems before giving account info, rebooting servers, etc.? I can't seem to convince the people I work with that address + last 4 digits of CC# is insanely bad but maybe I'm the rear end in a top hat. Information security researchers have gone and done the math on comparative risk of authentication methods for you: https://pages.nist.gov/800-63-3/sp800-63b.html
|
|
#
?
Mar 25, 2018 14:25
|
|
|
Thanks, this is what I needed to actually show people at work. I've been doing DC sales forever but now that I'm actually in a technical role I'm poo poo at like, figuring out what accepted industry standards/best practices for things are.
|
|
#
?
Mar 25, 2018 14:27
|
|
|
It's happening https://www.theregister.co.uk/2018/03/23/tls_1_3_approved_ietf/
|
|
#
?
Mar 25, 2018 14:52
|
|
|
News headline at some point. "England bans all encryption in a despite fight to stop child porn"
|
|
#
?
Mar 25, 2018 15:03
|
|
|
Fashy right-wing governments and technology they don't understand just don't get on well
|
|
#
?
Mar 25, 2018 15:50
|
|
|
I can’t wait to use it in 10 years when people finally implement it.
|
|
#
?
Mar 25, 2018 16:59
|
|
|
All (some? most?) of Cambridge Analytica's code was discovered available on an unsecured private git repository. https://www.upguard.com/breaches/aggregate-iq-part-one quote:On the night of March 20th, 2018, UpGuard Director of Cyber Risk Research Chris Vickery discovered a large data warehouse hosted on a subdomain of AIQ and using a custom version of popular code repository Gitlab, located at the web address gitlab.aggregateiq.com. Entering the URL, Gitlab prompts the user to register to see the contents - a free process which simply requires supplying an email address. Once registered, contents of the dozens of separate code repositories operated on the AggregateIQ Gitlab subdomain are entirely downloadable. They just left the registration completely open for anybody 
|
|
#
?
Mar 27, 2018 07:05
|
|
|
Now that's something I'll admit I've never seen in court -- does a properly functioning registration process imply authorization to access data, especially on a site where data sharing is the MO?
|
|
#
?
Mar 27, 2018 11:07
|
|
|
When I walk up to a door and someone asks me to register my email and gives me the key, was that reasonably-implied right to use?
|
|
#
?
Mar 27, 2018 11:09
|
|
|
Potato Salad posted:Now that's something I'll admit I've never seen in court -- does a properly functioning registration process imply authorization to access data, especially on a site where data sharing is the MO? if it doesn't, registering on amazon.com would be just as illegal.
|
|
#
?
Mar 27, 2018 12:34
|
|
|
Truga posted:if it doesn't, registering on amazon.com would be just as illegal. I think a better comparison would be like if I was able to register an me@amazon.com email address by going to email.amazon.com or whatever, and then being able to see everybody's calendars and appointments and schedules. Did I do anything wrong by going to email.amazon.com? No because it's a public facing website that anyone can visit. Did I do anything wrong by registering an Amazon corporate account? No because it's not my fault that they didn't have proper security to ensure that I couldn't register. Did I do anything wrong by looking up Bezo's calendar appointments? No because the account I registered had the proper permissions. I dunno, it feels like it's entirely their fault for allowing me to register on a public facing website without checking for say my IP address (VPN) or checking that I was an actual employee.
|
|
#
?
Mar 27, 2018 13:50
|
|
|
On the flip side of that, didn't Google get in trouble for logging data transmitted on open WiFi networks their cars observed? Data that's literally being freely broadcast to anyone in the area? I agree that if it's open, even unintentionally, that's the problem of those who wanted it closed and not those who accessed it. Unfortunately there are a lot of people, especially non-tech-savvy lawmakers, who will happily believe what a company tells them about how it's supposed to be private and only an evil hacker could discover that a company had a major software package exposed at <packagename>.<companyname>.<tld>
|
|
#
?
Mar 27, 2018 14:18
|
|
|
wolrah posted:On the flip side of that, didn't Google get in trouble for logging data transmitted on open WiFi networks their cars observed? Data that's literally being freely broadcast to anyone in the area? Was it actual legal trouble? Or just a conviction in the court of public opinion? I remember the kerfuffle it caused, but not necessarily the outcome.
|
|
#
?
Mar 27, 2018 14:36
|
|
|
Proteus Jones posted:Was it actual legal trouble? Or just a conviction in the court of public opinion? Looked it up and they did get sued a bunch, a few class actions were merged, and they lost. They tried to take it to the Supreme Court but were denied. https://www.wired.com/2014/04/threatlevel_0401_streetview/
|
|
#
?
Mar 27, 2018 14:54
|
|
|
I think it's a situation of intent mattering. If you're on wifi, you're not intending for all your traffic to be broadcast, that's just how the technology was designed. Even if it's encrypted, it's still broadcast. If someone puts up a repository, they had the option of making it private in many different ways, so as a third-party, you'd be safe to assume if you can access it through a standard registration then the owning party doesn't care.
|
|
#
?
Mar 27, 2018 14:58
|
|
|
Avenging_Mikon posted:I think it's a situation of intent mattering. If you're on wifi, you're not intending for all your traffic to be broadcast, that's just how the technology was designed. Even if it's encrypted, it's still broadcast. 1. That basically then requires you assume it's private unless told otherwise. Go to your favorite restaurant and see "<restaurant> WiFi" SSID wide open? Unless there's a sign up saying "Free WiFi" or you're told by the server, you can't know their intent, they might have just made a mistake when setting up the device. 2. Idiots gonna idiot. Anyone who was using FRS/GMRS radios when they became a big thing has probably come across people who believe the CTCSS "privacy codes" actually provide any form of privacy and will whine about how you're on "their" channel. Those people had the intent to have a private conversation, and were even led to believe they could based on the marketing descriptions of the product's features. That still doesn't mean it'd be reasonable to charge someone who happened to be recording the FRS spectrum with wiretapping. The peak of CB radio was before my time but I've heard many stories of the same sorts of things happening then, where people would be having a "private" conversation broadcast openly over a huge distance. The fact that someone else assumed it was private when it really wasn't should not be relevant to the law. That's their mistake, not a wrongdoing of the person passively monitoring the airwaves. quote:If someone puts up a repository, they had the option of making it private in many different ways, so as a third-party, you'd be safe to assume if you can access it through a standard registration then the owning party doesn't care. How does this differ from WiFi? They had the option of making it private in many different ways, so as a third party you'd be safe to assume if it's being broadcast to you in the clear then the transmitting party doesn't care.
|
|
#
?
Mar 27, 2018 15:44
|
|
|
wolrah posted:I don't think intent should matter for two reasons: Good thing the law specifically takes intent into account, so you're wrong.
|
|
#
?
Mar 27, 2018 15:47
|
|
|
In actuality it's up to the prosecutor if they want to make an example out of someone or not, like most federal laws.
|
|
#
?
Mar 27, 2018 17:13
|
|
|
See Aaron Swartz
|
|
#
?
Mar 27, 2018 17:24
|
|
|
Avenging_Mikon posted:Good thing the law specifically takes intent into account, so you're wrong. Good thing the law says this: quote:(g) It shall not be unlawful under this chapter or chapter 121 of this title for any person— In the Google case, the actual legal problem they had is that they also logged encrypted traffic. They obviously couldn't decode that traffic (well actually they probably could in most cases because they have a lot of CPU power and most wifi passwords suck, but that's another matter) but the courts decided that logging even the encrypted traffic was against the law. Had they only logged unencrypted traffic they'd have been fine. I don't disagree with that conclusion. Intent does sort of still matter, but only when such intent is actually demonstrated. You could use WEP64 and it'd still be considered private according to the law even if it's trivially broken and not really private, kinda similarly to how CSS encryption on DVDs is still considered to "effectively control access to a work" under the DMCA. The law basically says "as long as you tried". For the standard analogy to a business, it's the difference between having your doors wide open and having a screen door latched with one of those bent nail things. The actual security difference is basically zero, but the latter demonstrates intent to keep others out where the former does not.
|
|
#
?
Mar 27, 2018 17:55
|
|
|
are you guys going to check where the countries the companies you are arguing the law about reside? or take into account the context of a criminal enterprise with an ongoing investigation being the potential victim?
|
|
#
?
Mar 27, 2018 17:59
|
|
|
wolrah posted:Good thing the law says this: I like how you’ve constructed these elaborate posts when I said in my first post "even if you encrypted it, it’s still broadcast, so just broadcasting isn’t enough for someone to legally record it." So you’re strawmanning really hard here to now say "you could even use wep." Learn to read.
|
|
#
?
Mar 27, 2018 18:47
|
|
|
https://blog.frizk.net/2018/03/total-meltdown.htmlquote:Did you think Meltdown was bad? Unprivileged applications being able to read kernel memory at speeds possibly as high as megabytes per second was not a good thing. 
|
|
#
?
Mar 28, 2018 04:31
|
|
|
That can only be intentional to get business off 7? Right? 
|
|
#
?
Mar 28, 2018 04:38
|
|
|
Merriam-Webster dumpster fire noun Definition of dumpster fire US, informal : an utterly calamitous or mismanaged situation or occurrence : disaster
|
|
#
?
Mar 28, 2018 07:31
|
|
|
Zil posted:That can only be intentional to get business off 7? Right? Genuinely would not be surprised. gently caress I hope it works
|
|
#
?
Mar 28, 2018 07:46
|
|
|
|
|
#
?
Mar 28, 2018 12:50
|
|
|
Where were you when tower 7 collapsed?
|
|
#
?
Mar 28, 2018 13:02
|
|
|
That’s a 500 IQ secfuck holy poo poo
|
|
#
?
Mar 28, 2018 13:51
|
|
|
That's hilarious but it's already been patched (un)fortunately. Very small number of computers will ever be affected by it.
|
|
#
?
Mar 28, 2018 14:39
|
|
|
What if that patch introduces an even bigger secfuck?
|
|
#
?
Mar 28, 2018 14:56
|
|
|
You can ask that about any patch, really.
|
|
#
?
Mar 28, 2018 15:09
|
|
|
Cup Runneth Over posted:That's hilarious but it's already been patched (un)fortunately. Very small number of computers will ever be affected by it. Lol if you actually trust the subsequent patches for this just lol
|
|
#
?
Mar 28, 2018 15:13
|
|
|
Kassad posted:What if that patch introduces an even bigger secfuck? What if your posts cause even worse posts?
|
|
#
?
Mar 28, 2018 15:17
|
|
|
|
| # ? May 25, 2024 02:50 |
|
|
CLAM DOWN posted:Lol if you actually trust the subsequent patches for this just lol I trust the report that was linked on the vulnerability that says that the vulnerability has been patched
|
|
#
?
Mar 28, 2018 15:18
|
|