|
DeaconBlues posted:Nice thread topic! http://forums.somethingawful.com/showthread.php?threadid=3723583 Read this. And yes. You'll want a password manager. Theris posted:What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass. You're giving horrible advice. Here's a presentation I gave on Wednesday on why you don't use MD5 for these things: https://afreak.ca/content/share/OWASP%20-%20November%202015.pdf
|
#
¿
Nov 20, 2015 18:43
|
|
|
|
| # ¿ Apr 28, 2024 08:47 |
|
|
DeaconBlues posted:No it doesn't help. This helps: Learn a bit about password strength here. How about we look at some random examples here using results from KeePass's entropy to quality alogrithm: password (11 bits/8 characters) 1234567890 (6 bits/10 characters) SomethingAwfulDotComForums (60 bits/26 characters) 1320 West 4th Street (74 bits/20 characters) 654635489476516489475321 (64 bits/24 characters) CorrectHorseBatteryStaple (96 bits/25 characters) To achieve 96 bits like the last example, you'd need have a truly random number in order to not end up with it being guessed. Hell, 96-bits is not even something you'd want as if you're actually interested in being reasonably secure, KeePass suggests aiming for 128 bits or higher. This is why we're pouncing on "using random numbers" here because you're never going to get suitable password entropy. Here's a phrase that exceeds 128-bits: "DietCornFlackMcDonaldsSushiGross!". This is 33 characters long and would be quite difficult to guess. And guessing is where the idea of using an address you know is a bad idea. If you are in a situation where law enforcement wants access to an encrypted file vault of yours, they're going to build up a dossier on who you are and what you do. In one case, it was someone's cat but that is what the FBI and others will do: they'll learn your life and form lists of possible passwords and such. Don't do random numbers that you can recite off of your head and actually come up with something you can remember and has enough entropy. It doesn't matter if you're doing key stretching here as if the fruit is low enough, it'll be guessed.
|
|
#
¿
Nov 20, 2015 22:25
|
|
|
dougdrums posted:I'm tired of seeing the phrase "don't roll your own crypto". Yeah it's good advice if I'm trying to make web 2.0 mobile next big apps or whatever, but it's really loving annoying when you're learning about cryptography and some pile of meat stuck to a mouse replies with, "don't you know better than to ask There's a difference between writing an application that uses pre-existing libraries in a safe manner and writing your own cryptographic libraries (where "rolling your own" comes from). Two examples of where people have rolled their own failed crypto include Cryptocat (read details here) and another where someone implemented RSA using PHP. Of course, the developer posted it to Github (said developer removed it so I just have a tweet) and then its terrible implementation was rolled into other projects. You get great comments like this in the code too:  Any basic understanding of prime numbers would be enough to not let you wonder about why these are the largest pairs. I am not going to explain what is wrong in this code because if you're asking this then you shouldn't dare think about writing such. When those of us who work in the security industry say "don't roll your own", what we're saying is use the libraries that have been tested and vetted. We do have examples of those failing but they're typically going to fail in other ways than what you will do. DeaconBlues posted:2. SHA256 of E207HVT=baff2ddde4043bfcfe6dbf67ecfca2b5f8a3a90e7b4939632ce82565c3fe25b2 Not really. Don't do it this way for reasons I just posted. You're spending too much time making it more complicated than necessary. Antillie posted:For the specific case you mentioned why not use something like VeraCrypt? It was designed specifically for the situation you just described and its free. First of all, don't link to Sourceforge if you're going to suggest a security tool. They've bunded adware with projects that they claimed were "abandoned". Second of all, anything derived from TrueCrypt should not be trusted. Lain Iwakura fucked around with this message at 23:28 on Nov 20, 2015 |
|
#
¿
Nov 20, 2015 23:25
|
|
". It makes me think that the person who states it actually knows nothing about cryptography and is trying to cover up their personal insecurity with some cultist utterance.
|
Antillie posted:Well Sourceforge is the official place to get Veracrypt and Veracrypt isn't abandoned so I don't think there is anything wrong with getting it from them. Sourceforge was never the official place to get GIMP. Also the results of the code audit of TrueCrypt prove that it and by extension its open source derivatives are solid and can in fact be trusted. Stop spreading FUD. I too have read the report and actually believe that the cryptography is likely sound. I have no reason to refute that as there were many talented people going over its code to see what flaws there were. Minus some minor ones that can be and have been corrected, overall it's fine. However, you were quick to cite that report and then fail to look at what is outside of the cryptography which is how it works within the OS. Here are two vulnerabilities released this past September: https://code.google.com/p/google-security-research/issues/detail?id=538 quote:The Windows driver used by projects derived from Truecrypt 7 (verified in Veracrypt and CipherShed) are vulnerable to a local elevation of privilege attack by abusing the drive letter symbolic link creation facilities to remap the main system drive. With the system drive remapped it’s trivial to get a new process running under the local system account. https://code.google.com/p/google-security-research/issues/detail?id=537 quote:The Windows driver used by projects derived from Truecrypt 7 (verified in Veracrypt and CipherShed) are vulnerable to a local elevation of privilege attack by checking process of impersonation token which allow a user to inspect and potentially manipulate other users mounted encrypted volumes on the same machine. These were not included in the original audit as they did not pertain to the cryptography. The original TrueCrypt developer(s) said that the software likely had some unfixable vulnerabilities and whether or not that can be confirmed, it can be confirmed that we have some code sitting within that is likely to rear its ugly head as more people descend on it. For this reason, I cannot put my faith in TrueCrypt (and its derivatives) not because of "FUD" but because we already have enough evidence to support that position. Oh. And here's another security tool that was taken over by SourceForge.
|
|
#
¿
Nov 20, 2015 23:47
|
|
|
Inspector_666 posted:Could you maybe explain it to those of us who are interested? Or is this thread just for people who are already so smart they don't need to actually discuss anything because holy poo poo you guys are gooning it up so loving hard. RSA like many other ciphers rely on large prime numbers. When we talk about large prime numbers within RSA, we're talking taking two that are very, very far apart. In this code example, the smallest prime number is 4507 and the largest is 9533. They're both not what RSA is looking for nor are they very far apart--when we talk "large prime", we're talking of a prime that would of more or less 150 digits (the larger the better). We know based on this PHP array that there are only 570 prime numbers to choose from, meaning that there would only be something like <1,000,000 possible keys (I am doing ballpark numbers here and it would be between 100,000 and 1,000,000 so take it as it is). It wouldn't take long to run through all possible keys to decipher what was encrypted regardless of what key sets you're using. I think that this article is probably worth a read: http://doctrina.org/How-RSA-Works-With-Examples.html Lain Iwakura fucked around with this message at 23:59 on Nov 20, 2015 |
|
#
¿
Nov 20, 2015 23:56
|
|
|
Inspector_666 posted:Right but why is 9521, 9533 the last pair in that guy's code? It's because the developer didn't know what they were doing and decided to choose from a static list of primes <10,000. The prevailing thought in some circles for why the NSA is able to break so much cryptography isn't because they're looking for backdoors in the algorithms but instead poor implementations of prime numbers. PHP isn't a language suited for doing such tasks anyway.
|
|
#
¿
Nov 21, 2015 00:06
|
|
|
Antillie posted:On the subject of the NSA breaking crypto; Take a look at this paper. Specifically section "4.2 Is NSA Breaking 1024-bit DH?". It looks like most 1024 bit DH implementations use only two or three common sets of prime numbers. And it is plausibly within the capability of the NSA to have performed number field sieve precomputations for at least a small number of 1024 bit DH groups. Since most DH implementations use the same sets of primes the NSA could easily break IPSec or TLS sessions protected with such a common 1024 bit DH exchange. Yeah. It was linked to in the article I shared. wyoak posted:Anyway this is neither here nor there but it kind of boggles my mind that computers can figure out if a 150 digit number is probably prime within a matter of microseconds and also that the 'probably' apparently isn't important. It's not exactly that instantaneous.
|
|
#
¿
Nov 21, 2015 00:28
|
|
|
via posted:Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five? If the software doesn't have any detection and just keeps allowing password attempts, then that is the reason why. It used to be common that someone would just hammer some basic accounts (usually service-related) on a UNIX server, log in, grab the passwd file, log off, and then later come in with an account that has more permissions as they've run a dictionary against the passwords. Clifford Stoll's "The Cuckoo's Egg" is worth a read if you're curious how things used to be.
|
|
#
¿
Nov 24, 2015 00:03
|
|
|
Mr Chips posted:Can you explain the mathematics for the first bit for everyone else who's interested in understanding why? In terms of why a large prime number is needed or how all of RSA works here? I am not a cryptographer so explaining RSA properly is not going to go well here--I do understand it and can give an explanation here but it's like me trying to explain my house's electrical system as if I have a plumber's perspective. I do recommend reading this page to see how it all works. If we're talking about large primes here, it's quite simple: computers can't quickly factorize numbers. The problem that classical computers face right now is that calculating the factors of a number is quite intensive and that as numbers get larger the ability to determine all factors takes significantly longer (see this Wikipedia article for further elaboration). This is why finding prime numbers has over time taken longer, but if you want to see the problem first hand without a computer, see how long you take to count completely in primes and you'll start to understand that you're running into a similar problem. [edit] Just read this post: http://forums.somethingawful.com/showthread.php?threadid=3750534&pagenumber=2#post453102981 quote:As for Truecrypt forks, if we're going to apply that level of paranoia consistently, what can we use? We can't do public code reviews on commercial, closed source FDE tools like Bitlocker and PGP. We can't rule out government intereference in Truecrypt, nor can we rule it out with commercial offerings (MS removed the Elephant diffuser from Bitlocker If your concern is that you cannot do commercial code review of your closed source FDE (such as Bitlocker), why are you using Windows overall? Truthfully I am more worried about how the OS and FDE interact rather than the cryptography. If you're at this level of paranoia, use Linux with dm-crypt. Lain Iwakura fucked around with this message at 18:06 on Nov 24, 2015 |
|
#
¿
Nov 24, 2015 17:00
|
|
), or undisclosed vulnerabilities that malicous actors are also exploiting etc etc
|
ExcessBLarg! posted:Prime numbers exist above 10,000, so the claim that 9533 is the largest prime is pretty laughable. As for why, I'm not a Mathematician so I won't explain it in a rigorous way, but intuitively there's nothing particularly special about "10,000" to think that there aren't prime numbers larger than that. This is far better than what I had posted. 
|
|
#
¿
Nov 24, 2015 17:24
|
|
|
deep impact on vhs posted:also, seems that a new POS malware that is extremely sophisticated is making the rounds: https://thestack.com/security/2015/11/24/modpos-retail-malware-is-not-the-work-of-script-kiddies/ Not particularly special in terms of its capabilities, but it has been floating about for a while it appears. Here's some links to look at: https://www.virustotal.com/en/ip-address/130.0.237.22/information/ https://www.symantec.com/security_response/writeup.jsp?docid=2014-121211-5404-99&tabid=2 I can't share the report directly as it's tied to my work account, but I can share excerpts: quote:iSIGHT Partners has been tracking a sophisticated malware framework with individual modules that are difficult to detect and are typically packed kernel drivers, suggesting the malware author’s sophistication level is high. It should be noted that it has probably been picked up in the wild by an AV vendor well before this report came out (as per my previous links) but iSIGHT is the first team to figure out what is going on here. quote:This driver contains the actual POS scraper code that collects credit card track data from memory. We believe the malware authors target specific POS software processes; however, in one sample we observed the malware injecting code into credit.exe and hooking the “__vbaStrCopy” function. Stolen credit card data is AES-256 encrypted and stored in the Windows Installer directory using random characters for the filename and a “.bin” filename extension, such as C:\WINDOWS\Installer\{GUID}_<random_characters>.bin. Lain Iwakura fucked around with this message at 00:23 on Nov 25, 2015 |
|
#
¿
Nov 25, 2015 00:20
|
|
|
wyoak posted:How common is DNS-based command and control / data exfiltration at this point? Does it only show up in APT-level attacks or has it started to filter down to more off-the-shelf type malware? Here's a question for you: what is an APT and why do you use that term?
|
|
#
¿
Nov 25, 2015 19:14
|
|
|
deep impact on vhs posted:facebook refuses to pay out bug bounty based on arbitrary, unwritten rules: http://exfiltrated.com/research-Instagram-RCE.php Uh. Did you read the article? He did get paid.
|
|
#
¿
Dec 17, 2015 23:37
|
|
|
Rakthar posted:You can substitute the word "targeted attack" for APT when you see the term if you want to: Yeah. No. You're not answering the question correctly. How did you come to this conclusion that those two answers are acceptable?
|
|
#
¿
Dec 18, 2015 00:53
|
|
|
Rakthar posted:I seem to be able to understand that guy's question, and you seem to be struggling. Is there a reason for this? No. You do not understand the guy's question nor did you answer mine. Again, answer my question: how did you come to the conclusion that APT stands for what you have described to me? Do you know the origins of "APT" for that matter?
|
|
#
¿
Dec 18, 2015 00:58
|
|
|
Rakthar posted:Would either of you august gentlemen care to weigh on whether you think DNS based C2 communications are typically used in more targeted attacks as opposed to say malware that uses HTTPS based callbacks? What about malware that uses google blogs and fake webpages for C2? Or are we still ignoring that guy's question as if it can't possibly be answered? Okay. First off all, stop talking as if you're getting hurt by my asking questions about your inability to understand that "APT" doesn't mean "targeted attack". If you had any clue about what you were talking about, you'd understand that "APT" was a term created by Mandiant to describe a group that was a "state actor", not a "targeted attack" or some other nonsense that you picked up from some marketing brochure at a lovely vendor event. I am not trying to malign your ego here by making you state your credentials as if you had any reading comprehension skills, you'd have noticed I did not once ask that. All I asked is if you understood what "APT" means and just like a lot of people out there, you do not. Only one vendor is allowed to use "APT" and that is Mandiant/FireEye, as they use it to describe what they suspect as state actor groups. The term is misused just as much as "0-day". So unless you are describing a state actor, an "APT" is not a loving targeted attack. Now to answer your question: what the gently caress are you trying to get at? Targeted attacks will use any means to get out with whatever level of obfuscation. Any malware author engaging in a targeted attack will have scoped out your network enough to determine whether or not they need to communicate over DNS, HTTP, or the hell of it, UUCP. If I am going to target your organization, I sure as gently caress am going to use whatever means to get out. This seems like an un-researched question really because if you had any clue about "targeted attacks", you'd not be asking how they'd engage in them.
|
|
#
¿
Dec 18, 2015 01:53
|
|
|
Rakthar posted:So doesn't that seem like a really useless definition of APT? "The proper, empirical definition of APT is that this one company made up a specific term for state actors but you can only use it in their original, intended way." It was coined in a specific way, but it gets used generally. No. I am giving you the definition based on the organization that actually created the term "APT" (which if you are unsure because so far I believe you are, stands for "Advanced Persistent Threat"). You're giving the definition of APT based on how you've been marketed to. I am not sure why you're trying to refute this unless you're in marketing for an anti-virus firm or some company that claims to be "next-generation" [insert poo poo box here]. When people (like you and many others) throw the term "APT" around, they mean that "they have no clue what they're talking about but have bought into the hot new buzz word to try and push their poo poo products". When someone says that they offer "APT protection", they're just offering protection from threats. No specific product is going to protect you from a targeted attack because as the statement reads: it's a targeted attack, meaning that you've been scoped out, researched, and they've crafted their attack specifically at you and nobody else. This is the sort of thing that a vendor will have a hard time defending against because of the fact that whatever protections you have in place could become meaningless because the aggressor has taken that poo poo into account. Throwing around "APT" generally means you have no clue and probably shouldn't be talking as some sort of expert in here. Unless you work for FireEye/Mandiant, you have no loving business using that term. quote:And yes, in general, I do feel there is a correlation between the evasion techniques being used and whether an attack is targeted or not. "Good enough" is the motto for obfuscation and, in general, obfuscation techniques are not used where they will add unnecessary complexity or where they threaten to burn a technique through common usage that is not worth coming up with countermeasures for. You have no clue how a targeted attack works. quote:You should not expect to see any DNS based C2 communication with things like cryptolocker. If you are seeing DNS based C2 communication, you probably aren't dealing with cryptolocker. Why are we talking about this in relation to CryptoLocker? By the way, why are you bringing up malware from 2013 in relation to a targeted attack? Or are you going on unrelated tangents in some feeble attempt to demonstrate knowledge in something? quote:So I think this answer is worth clarifying. Using UDP 53 for large data transfers is basically unheard of, yes. However, using DNS queries to both send and receive commands to compromised hosts is quite common and effective, simply because there's so many DNS queries to hide in and most DNS servers do not (did not) log queries due to performance and disk issues. OK. Great. Why are you going on about this in relation to targeted attacks?
|
|
#
¿
Dec 18, 2015 03:16
|
|
|
Mr Chips posted:If no-one ITT works for them, can we stop talking about it? Absolutely.
|
|
#
¿
Dec 18, 2015 03:37
|
|
|
Alereon posted:Lastpass is compellingly better than the alternatives [...] doesn't want to buy an app once for every platform they own. KeePass doesn't cost money and works on virtually every platform out there. It works great with Dropbox and works fine for autists and non-autists alike.
|
|
#
¿
Dec 21, 2015 18:00
|
|
|
Inspector_666 posted:I feel like if you think LastPass is insecure "just throw your entire password DB into Dropbox!" isn't really much better... Please explain how you have come to this conclusion. You're (mostly) in control and provided that you don't set your KeePass file to some dumb password, putting it on Dropbox or some other hosting service is far better than trusting that the algorithm used on LastPass isn't being hobbled by any inadequately written software. Hell, you can combine it with a keyfile if you're even less trusting of this method. You can at least inspect how KeePass is treating your passwords whereas you're trusting a blackbox with LastPass that has had a number of problems in the past five years.
|
|
#
¿
Dec 21, 2015 21:04
|
|
|
Inspector_666 posted:Last time there was a discussion about this the overwhelming opinion from goons was that Dropbox was a security joke and your data might as well just be publically accessible. Dropbox security is a complete joke because as the data is stored in plaintext when at rest. There is no argument from me on this at all. However, you're telling me that is worse than trusting that LastPass, a service that stores passwords for millions of users? A service that has been in a supposed targeted attack in the past year? A service that has had issues with credentials being stolen from the browser last year? A service that has had its users change their master password in the past? And we're going on about Dropbox being insecure because someone could read the password file on your system? At least if you're saving the KeePass (or 1Password) file via Dropbox that you don't have to be as concerned about someone modifying the application to allow others to read the data. The type of attack on Juniper's VPN source-code is far more likely with LastPass than with KeePass to say the least. Have you given any consideration to this?
|
|
#
¿
Dec 21, 2015 21:17
|
|
|
Alereon posted:KeePass is worthless for average users because it requires you to roll your own db storage and synchronization solution. Saying "just use dropbox" is great for autists who want to live independently, but it's absolutely not a solution that Just Works in the way Lastpass does. You're a smart guy, you know all this, so I don't get why you won't accept that LastPass offers the best balance between security and usability for most people. My post above adequately demonstrates why using LastPass is a terrible suggestion and should be avoided at all costs. If you're the kind of person that has come to the conclusion that LastPass is necessary, you're the kind of person that is capable of setting up a cloud-based file distribution service.
|
|
#
¿
Dec 21, 2015 21:21
|
|
|
Alereon posted:Your post describes some very vague and not-at-all-compelling reasons why people should be cautious about trusting their data to Lastpass. And yes, any security professional (or someone who plays one on the Internet) is perfectly capable of setting up their own cloud-based db synch solution, but those security professionals aren't asking for advice on how to manage their passwords. Someone who asks security professionals what password management solution to use should be directed to Lastpass. quote:Here's the problem. Convenience is so vastly more important than your theoretical security concerns that I am stunned we are still having this discussion. How can we have this discussion about "people who play as a security professionals on the Internet" yet then turn around and go on about "convenience [trumping] security"? Here's what we can easily tell about KeePass and a cloud-based file distribution service:
Now that we have established the things we know about KeePass, what can we say about LastPass?
If you think that your accounts are not important, then fine, use LastPass. But don't go around saying that it has adequate security because as I have already demonstrated it has been rife with problems that would otherwise not exist if we were to just use a file-based password manager.
|
|
#
¿
Dec 21, 2015 22:06
|
|
|
PBS posted:Is there ever a valid reason for the PasswordNotRequired AD attribute to be set to True? Microsoft has terrible documentation on this but its purpose is not for the user but for the administrator to set a blank (null) password. With this flag, users cannot change their passwords to blank but passwords can be set to blank by an administrator.
|
|
#
¿
Dec 23, 2015 04:16
|
|
|
Jeesis posted:Anyhoo, any advice for someone trying to get into the security field? make friends and don't poo poo on their advice
|
|
#
¿
Dec 25, 2015 07:08
|
|
|
Subjunctive posted:Hmm. The blog entry itself posted:Thanks to David Howells, Wade Mealing and the whole Red Hat Security team for that fast response and the cooperation fixing the bug.
|
|
#
¿
Jan 19, 2016 23:59
|
|
|
DeaconBlues posted:https://www.dyne.org/software/tomb/ Sure. quote:However we strongly encourage people in need of strong encryption to not use Winslows, or at least to not generate encrypted partitions with it, since it can contain backdoors in the random number generation, as pointed by Bruce Schneier and Niels Ferguson in this short essay about the Dual_EC_DRBG. Why would you want to use an encryption tool that is not cross-platform and with authors who write "Windows" as if they're infantile? To add to this, they lay claim to "certain backdoors in the [RNG]" which is interesting because it cites a problem in Windows 2000, an operating system old enough to be able to drive a car. Also the paper it cites from 2007 (which you can read here) makes zero mention of it being a backdoor or otherwise being intentional. Lastly, the problem affected XP as well (due to the similar code base), but Microsoft fixed it in Service Pack 3. I am not going to rant or discuss this part further because this topic goes beyond what I am comfortable to talk about but the guys who wrote this Tomb garbage appear to be willing to jump to conclusions. quote:Steganography helps here. Tomb offers the possibility to bury and exhume keys from jpeg images: if steghide is installed on a system then Tomb will offer this commands in its command-line help. Steganography is dumb and shouldn't be even hinted at if you're trying to be serious about a cryptography product. https://github.com/dyne/Tomb/blob/master/tomb Also it's a glorified shell script that is basically a wrapper for GPG, meaning that it isn't revolutionary. I haven't the chance to further look at the code, but I don't have much faith considering how it's written and the stupidity on the website. Seriously, don't just suggest a random cryptography tool like this. Not only is it written by individuals who cannot write "Windows" without turning into children, they preach the use of idiotic deception to hide your keys. If you need a tool to share files amongst machines, use 7-Zip or something that actually is cross-platform and isn't written by someone trying to create some uninformed narrative. If they're serious cryptographers, they'd not cite a 9-year old paper on an attack on Windows 2000/XP that has since been fixed as evidence of a supposed backdoor within WIndows. Lain Iwakura fucked around with this message at 17:01 on Jan 22, 2016 |
|
#
¿
Jan 22, 2016 16:49
|
|
|
TheQat posted:http://www.ibtimes.co.uk/john-mcafee-i-can-hack-san-bernardino-iphone-fbi-apple-backdoor-like-giving-our-enemies-1544651 I don't think that he's worthy talking about here. With that said, I have met him when I was last at DEFCON and he smelt like smokes and bourbon yet not an ounce of regret was on him.
|
|
#
¿
Feb 18, 2016 18:32
|
|
|
ming-the-mazdaless posted:A year ago, I did a Proof of Concept for insider threat detection in a hospital group. Talk to a lawyer; health care is one of those things that could get you sued to all hell. Are you American? Did you do this as an individual or are you working for a firm that was hired to do the PoC? Do you have any NDAs with them? As much as health care organizations need reform, full public disclosure may work very much against your favour.
|
|
#
¿
Mar 4, 2016 16:23
|
|
|
Dex posted:you clearly know what shodan is, so why not just use it? It is also inexpensive to get access to extra features.
|
|
#
¿
Mar 21, 2016 04:49
|
|
|
Seconding this. If you're running a website in 2016 without SSL, you're a buffoon.
|
|
#
¿
Apr 6, 2016 17:39
|
|
|
PBCrunch posted:That was remarkably easy; I feel dumb for not having that working before. While I cannot comment on the Apache authentication specifically, I can tell you that having your LE certificate checked every week automatically is the right thing to do.
|
|
#
¿
Apr 6, 2016 20:22
|
|
|
Someone having physical access to your device generally means all bets are off.
|
|
#
¿
Apr 21, 2016 14:46
|
|
|
spog posted:The article suggests that the messages were accessed while the crime happened, not after the fact. quote:I guess the question is how they attacked the phones without the user's knowledge. Can you push software onto a phone without alerting the user? I think you just answered your question. You can push apps to a Blackberry device.
|
|
#
¿
Apr 21, 2016 15:31
|
|
|
ohgodwhat posted:It doesn't have to do anything obviously nefarious if the protocol is poo poo and/or improperly or poorly implemented. Okay. So have you ever looked at the code yourself? Do you understand the difference between a "poo poo" protocol and one that is not? Can you cite any examples or are you just theorizing?
|
|
#
¿
Apr 22, 2016 04:00
|
|
|
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.
|
|
#
¿
Apr 23, 2016 18:24
|
|
|
dpbjinc posted:I would like to point out that the NIST curves everyone uses used some arbitrary value for the generator seed, so there's no telling if the NSA tampered with them or not. Until this draft becomes an RFC or TLS 1.3 comes out and Curve 25519 support becomes mainstream, you're better off using RSA. Curious: how do you think the NSA has tampered with them?
|
|
#
¿
Apr 25, 2016 05:38
|
|
|
FlyingCowOfDoom posted:Anyone a SIEM analyst/administrator here? If so what solution do you use and do you like it? We currently use Qradar but with some planned business expansion we're gonna have to shell out some big bucks to keep up with EPS and FPS so my boss gave me the ok to look around at other options. Not-quite-a-SIEM-but-almost-good-enough but Splunk has a cloud solution.
|
|
#
¿
Apr 27, 2016 23:03
|
|
|
EVIL Gibson posted:Splunk can be difficult to set up to pull in data from various logtypes, and massaging it correctly so it doesn't run the peg the CPU by indexing all the time, but once it's going it goes great especially when running correlations. Learning regular expressions makes Splunk bearable, but you are correct that the data collection part is really the chore. The nice thing about Splunk is that it's useful for other things. We've been using it in a DFIR setting as of late as in taking data from FireEye HX outputs and then using that to compare machines. I rarely say nice things about specific vendors but Splunk is the only product I've ever used that I can actually stomach suggesting its use. It's useful if you decide to use it alongside an actual SIEM because you can forward the data off from that and just use Splunk as your collection service. Also the cloud solution works great if you don't want to deal with the scaling headaches.
|
|
#
¿
Apr 28, 2016 03:26
|
|
|
|
| # ¿ Apr 28, 2024 08:47 |
|
|
ItBurns posted:Noted. Why bother using the Internet if your ISP can log your encrypted connections and tie them with other information?
|
|
#
¿
Apr 28, 2016 19:43
|
|