|
I thought this was a thread were we could discuss whether or not it should be best practice to disable TLS 1.0 on web servers that also support TLS_FALLBACK_SCSV. Or maybe what a good lifetime value would be for a HTTP Strict Transport Security header and the pros and cons of including the preload option in said header. But for some reason we are talking about a new form of advertising tracking that is supposedly only being used in India.
|
#
¿
Nov 20, 2015 17:52
|
|
|
|
| # ¿ Apr 27, 2024 19:43 |
|
|
When I need to encrypt something in Python before I write it to disk I use the simple-crypt module. Despite its use of PBKDF2 with a 256 bit random salt I still tend to use the SHA256 of some random phrase as the initial password. In my specific use case I am trying to protect data that a user might backup to some sort of external drive or dropbox account. So if the USB drive is lost or the dropbox account is compromised all the attacker gets is a pile of AES encrypted gibberish since the python program that contains the password is stored elsewhere and not backed up by end users.
|
|
#
¿
Nov 20, 2015 19:17
|
|
|
Scikar posted:Your use case seems better suited for public-private key crypto rather than symmetric key like AES, and PGP already exists to do this for you. If I ever need to change things so that each user's data is encrypted with a unique key then I would certainly go with 2048 bit RSA and generate a unique public/private key pair for each user. However at the moment each user only has access to their own data in their home directly due to filesystem permissions and anyone with root can already see the data I am trying to protect anyway. I suppose I could replace the current way I am doing things with a single public/private key pair but I don't see what that would do other than slow things down. Or am I just not understanding your suggestion correctly?
|
|
#
¿
Nov 20, 2015 19:48
|
|
|
DeaconBlues posted:No it doesn't help. This helps: Well if you are using AES-256 then you must use a key that is exactly 256 bits in length. So whatever you are using to perform the encryption must expand the password that you give it to a 256 bit value. This is generally done with some form of hashing. Exactly how this should be done and why is highly complex and beyond my limited knowledge of encryption. As I see it, if the attacker doesn't know how you expanded your password into a 256 bit value then they are left trying to guess the key which is basically impossible with AES. But if they do know how you expanded your password into a 256 bit value then all they have to do is guess the password. So I would say that in the latter case, a long string of pseudo-random characters would be more secure than a short password. I think that PBKDF2 and bcrypt are probably the best ways to do what you are wanting. The downsides you mentioned are just side effects of these methods not being terrible. I suppose if you are going to go with a hash then SHA256 is probably the way to go as it syncs up nicely with AES-256's key size. Although reading through OSI bean dip's presentation using a straight up hash like this is apparently a bad idea when talking about storing passwords. I am not sure if or how that applies to symmetric encryption keys. I guess it probably depends on your specific use case and how often you change the key but I don't really know. As I said earlier, I feed a SHA256 hash of a long random phrase to Python's simple crypt module as a password to encrypt things. But the simple crypt module itself employs PBKDF2 to generate the actual encryption key. My reason for this is that it is very easy to tell if something has been encrypted using simple crypt. So in my case an attacker knows exactly how I expanded my password into the encryption key and therefore I need to use a very long and pseudo-random password. Antillie fucked around with this message at 22:30 on Nov 20, 2015 |
|
#
¿
Nov 20, 2015 22:14
|
|
|
I don't think there is anything wrong with rolling your own crypto for the purposes of learning about crypto. But if you are going to do something important you should always use an established and well vetted encryption system instead of trying to come up with something yourself. Of course you can always just study existing encryption systems to learn about crypto and save yourself the time of trying to write your own for learning purposes. I imagine that writing an implementation of RSA or AES would be quite educational. If only to teach me how not to implement an encryption system as I am certain that I would screw something up in the process of writing the implementation.
|
|
#
¿
Nov 20, 2015 22:36
|
|
|
Well its better than no encryption but I am not an encryption expert. However if the thief realizes that you are using a SHA256 hash for your AES key then all he has to do is guess the string that you initially fed to the hash function. And 7 characters is pretty drat short when you are talking about guessing a password. 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. OSI bean dip is right about passwords, they need to be long. "LowFatCrudeOilPopTartsWithGraniteWaffelsAndAntifreeze" is where it's at. Antillie fucked around with this message at 23:00 on Nov 20, 2015 |
|
#
¿
Nov 20, 2015 22:53
|
|
|
OSI bean dip posted: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". I guess you can get Veracrypt from Codeplex instead if you are worried about that sort of thing. Sourceforge was never the official place to get GIMP anyway. 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. Antillie fucked around with this message at 23:37 on Nov 20, 2015 |
|
#
¿
Nov 20, 2015 23:33
|
|
|
Wiggly Wayne DDS posted:Are you loving serious? Back up those claims. I was incorrect about VeraCrypt. It is in fact hosted at codeplex. However I did back up my claim about TrueCrypt with a link to a summary of the audit results. So yes. I am loving serious.
|
|
#
¿
Nov 20, 2015 23:49
|
|
|
OSI bean dip posted:Good info about TrueCrypt. Interesting. Still those are things that can be fixed. Serious flaws are found in software all the time. I don't see how finding OS level flaws in TrueCrypt makes it harder to trust than Firefox or Chrome. Even Bash has had serious issues over the years.
|
|
#
¿
Nov 20, 2015 23:53
|
|
|
Wiggly Wayne DDS posted:Well when the dev backs away from the project going "Don't touch this with a 10 foot pole" it changes the situation somewhat. The TrueCrypt devs simply said that they were done. They never said why. Maybe they just got tired of working on the project. Maybe there is some horrible as yet unfound bug. Some bugs have been found and fixed. This is no different than any other software project. There might be some terrible remote code execution bug in Chrome right now but that isn't going to stop me from using Chrome. I guess it just comes down to how paranoid you are. Antillie fucked around with this message at 00:05 on Nov 21, 2015 |
|
#
¿
Nov 21, 2015 00:02
|
|
|
OSI bean dip posted: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. 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, SSH, or TLS sessions protected with such a common 1024 bit DH exchange. You guys probably already know about this but in the circles I tend to move in most people aren't aware of it. Antillie fucked around with this message at 00:16 on Nov 21, 2015 |
|
#
¿
Nov 21, 2015 00:13
|
|
|
OSI bean dip posted:Yeah. It was linked to in the article I shared. Now that I have had time to read it I see that. Very nice. This is actually the reason why I am pushing for clients to use ECDHE instead of DHE (in addition to traditional RSA) on their HTTPS web sites as the devices we use for TLS termination do not support DHE exchanges larger than 1024 bits. The fact that ECDHE is also much faster is just a nice bonus. In fact I generally recommend the following cipher suite order when asked: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA I know 3DES is getting pretty long in the tooth but some people still need to support TLS clients that can't do AES because Antillie fucked around with this message at 00:50 on Nov 21, 2015 |
|
#
¿
Nov 21, 2015 00:44
|
|
|
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? I see SSH, RDP, and FTP servers get hit with brute force attacks all the time. Mostly because most people, including many sys admins, are bad a picking good passwords and/or don't bother to turn on account lockout policies. Systems with port 22, 21, or 3389 open to the world and poor passwords are low hanging fruit. And they are common enough for it to be worth letting a script look for them. Brute force attacks are very easy to prevent. But the "it won't happen to me" mentality is quite common among the general sys admin population so there are a lot of systems out there that don't have any of the basic brute force mitigation methods configured. The same goes for web applications with badly written SQL queries and people installing Wordpress (and random Wordpress plugins) and then never updating it.
|
|
#
¿
Nov 24, 2015 16:53
|
|
|
Mr Chips posted: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 For the truly paranoid the only real option is to roll your own solution. But I think we all know how well that tends to work out if you aren't an expert in cryptography and number theory. However the second major audit of TrueCrypt, which includes more than just the cryptography functions audited previously in April, was recently completed. Ars Technica has a nice summary. The important part is that you have to realize what TrueCrypt and its derivatives are for. Securing data while it is at reset. That is, when the encrypted volume is not mounted. Wiggly Wayne DDS and OSI bean dip will probably disagree but I feel that VeraCrypt is a reasonable alternative assuming you aren't in a position to spend millions of dollars to develop your own solution. And honestly I feel that titaniumone makes a very good point. If someone breaks into your car or house and steals your laptop they aren't going to try and break any crypto, even terrible crypto, to try and find information about you. They are going to hawk it at the nearest pawn shop who will in turn throw a fresh Windows install on it and put it up for sale. Now I suppose if someone broke into my car in the office parking lot and stole my laptop there is a small chance they might be someone looking for information on our company or our customers (such as private keys for TLS certificates, passwords for internal systems, ect...) and they may look around on my laptop for such information. I think that VeraCrypt would be perfectly capable of thwarting any such attempt. It might have some hidden flaw that would prevent it from keeping the NSA from extracting information from my laptop. But groups with the resources of a nation state aren't my main adversary. That said, I think that TrueCrypt/VeraCrypt, if properly used, would still give the NSA a serious headache. Antillie fucked around with this message at 17:39 on Nov 24, 2015 |
|
#
¿
Nov 24, 2015 17:12
|
|
), or undisclosed vulnerabilities that malicous actors are also exploiting etc etc
|
So its not just one, but three rouge root certs that Dell has been installing on every laptop that it has sold for the past while. What really floors me is that they also included the private key so anyone can sign TLS certificates or executable code with this root cert and Dell PCs will trust the result automatically. Hooray for OEM stupidity.
|
|
#
¿
Nov 24, 2015 17:51
|
|
|
I don't see much reason to bother splitting data up between multiple encrypted volumes if each of them is going to use the same encryption and have a password of equal complexity. I guess having multiple volumes would force an attacker to try and break each one individually but breaking just one should be essentially impossible anyway. And if some flaw in VeraCrypt/TrueCrypt allows an attacker to break one volume easily they would be able to break multiple volumes the same way anyway. For me the question would be whether or not to have a separate or even an unencrypted volume for the OS. If I have an unencrypted volume for the OS then I can boot the machine and use it for basic things like web surfing and email without needing to mount the encrypted data volume. This allows other people to use the PC without needing to know a password and it keeps your encrypted data safe and unmounted when you are not using it. The downside of course is that you, and other people, can use the PC without needing a password and poke around on the OS drive all they like and look for stuff that you might have accidentally saved there and forgotten to move to the encrypted volume. If you encrypt the entire drive, OS and all, then you would need to enter the password for the encryption every time the machine boots up. This is nice for keeping people from using your PC but it could get annoying if you ever have to reboot frequently for any reason. It also means that your data is mounted and accessible at all times when the machine is running. This is convenient but also reduces the security of your data as VeraCrypt/TrueCrypt are intended to secure data at rest when the volume is not mounted. I think the best of both worlds would probably be to have the OS on one volume and your data on another volume with both volumes encrypted with very different passwords. That way you can give out the OS volume password to people who you want to allow to use the PC and it keeps random people from poking around on the OS drive without the password. And your data is still safely unmounted when you are not using it but simply checking your email or whatever.
|
|
#
¿
Nov 25, 2015 17:39
|
|
|
DeaconBlues posted:I wouldn't have a clue what to look for in a bunch of decompiled c, so the basis of my assumption is sociological: Facebook is part of the status quo, and makes a pretty penny from being there. Why would they want to upset that balance by offering 'true' unbreakable end to end private messaging and also open up possibilities where they have to defend themselves against gov/FBI/yadda? Well if the encryption is truly unbreakable by themselves after the fact and no logs of the data or keys are kept then that is all the defense they need. If you can get experts to testify before a judge that something is truly impossible then the judge will generally accept that as a good reason to not issue an order to do that something or as a good reason for not complying with such an order. Now that doesn't stop the government from forcing them to implement logging of the keys or data with a law or court order or something. But that would only help with all transactions from that point onward. Older stuff would be safe forever. With Startcom and Lets Encrypt handing out trusted certs for free left and right there is no reason not to encrypt literally everything on the internet with solid not-breakable-after-the-fact crypto. TLS 1.2, ECDHE, and AES-GCM. Done. In fact if I go to facebook.com in Firefox this is the exact cipher suite they are using. Trendy crypto nerds can use ChaCha20 and Poly1305. They even have have TLS_FALLBACK_SCSV enabled and a proper HSTS header and HSTS preloading in all major browsers. Baring some secret government warrant/fisa court order I would say that they are pretty serious about crypto. Now if only there was some group handing out trusted ECDSA certs for free I would be a happy happy nerd. Antillie fucked around with this message at 16:22 on Apr 22, 2016 |
|
#
¿
Apr 22, 2016 15:49
|
|
|
It is definitely not stupid to question if a service really is completely private. In fact I would say that it would be stupid not to. I haven't examined WhatsApp at all but my cursory look at facebook's web site gives me the impression that they know what they are doing and are serious about doing crypto right. I would hope that this same mentality crosses over to the group responsible for the WhatsApp crypto. Does it prove anything about WhatsApp? No. But its an encouraging fact none the less. Antillie fucked around with this message at 17:38 on Apr 22, 2016 |
|
#
¿
Apr 22, 2016 17:36
|
|
|
Well the days of RSA are numbered even if only for performance reasons. The super common 2048 bit RSA keys used by most https web sites these days only provide about 112 bits of effective security. That's enough, but it won't be enough forever (good till about 2030 probably). The problem with RSA is that to get a linear increase in effective security you have to increase the key size exponentially. If we go up to 3072 bit RSA keys for 128 bits of effective security then RSA key exchange slows down almost to ECDHE key exchange performance levels. If we increase the key size further to 4096 bit then ECDHE ties RSA for speed. The problem with RSA is that it does not scale well from a performance perspective so RSA in general has a finite lifetime in the TLS ecosystem. Hopefully this will encourage people to migrate to ECDSA certificates as ECDHE_ECDSA is actually ~29% faster than ECDHE_RSA when RSA is using a 2048 bit key and ECDSA is using the effective security equivalent. As the key size increases the performance lead of ECDHE_ECDSA only gets larger at an exponential rate. As for the NSA having tampered with the curves... I am both optimistic and paranoid. Optimistic that they in fact strengthened them like they did with DES back in the day. There was a similar "They backdoored it! Don't use DES!" reaction back then as well. However I am not naive, they may very well have done something sneaky. So I push for people to adopt ECDHE_ECDSA now. Just getting devices upgraded to support ECDHE_ECDSA at all is a HUGE task by itself. Often you are jumping major versions on your web server software/server OS/load balancer firmware/firewall firmware and the upgrade is not a trivial thing. But once you are in the major version train that supports ECDHE_ECDSA adding new curves via a patch or minor point release is usually pretty trivial. Reissuing certificates with a new curve also isn't a big deal. So my mantra is to upgrade to ECDHE_ECDSA now, then, if needed, add better curves as they become available. Antillie fucked around with this message at 22:04 on Apr 25, 2016 |
|
#
¿
Apr 25, 2016 21:33
|
|
|
Swagger Dagger posted:For the people asking about learning infosec, I think you could do a whole lot worse than reading through these: https://www.humblebundle.com/books/no-starch-hacking-books That looks really nice. I may pick that up. I was quite impressed with Bulletproof SSL and TLS. Its more a set of best practices accompanied by well written explanations but it also has a number of very interesting stories of how PKI has been breached in the past. Sometimes via actual malicious acts and sometimes just through incompetence. Its specific to just one protocol. But given how incredibly common TLS is on the internet I feel its worth picking up. Antillie fucked around with this message at 16:13 on Apr 28, 2016 |
|
#
¿
Apr 28, 2016 16:01
|
|
|
Boris Galerkin posted:Is let's encrypt actually worth taking the x minutes to set up? I remember ready somewhere that all having a cert from them says is "this guy has a cert from us" but doesn't actually mean/do much else. Could be wrong though. Considering how much your average internet user knows about certificates, PKI, and encryption, this about all that any cert from any CA does. Even the EV ones. Antillie fucked around with this message at 22:13 on Apr 28, 2016 |
|
#
¿
Apr 28, 2016 22:06
|
|
|
ultramiraculous posted:"Computer security is hard and I'm willing to admit I don't understand everything about it/pr0zac might know more than me." Sure.
|
|
#
¿
Apr 28, 2016 22:54
|
|
|
Subjunctive posted:My company has > 10K end-user machines and we don't run AV. Must be nice to work in an industry that isn't subject to PCI, HIPAA, GLBA, US Government Contracting, or UK Data Protection Act regulation. It must also be nice to not have any clients that are subject to any of those things either.
|
|
#
¿
Apr 30, 2016 18:56
|
|
|
Rufus Ping posted:Which part of the Data Protection Act mandates AV? The part where the compliance auditor tells you need to have it on all of your workstations. Whether or not its actually a legal requirement means very little if the auditor won't pass you without it. I have seen this happen many times. Its a strange mixture of encouraging, puzzling, and stupid. Antillie fucked around with this message at 18:18 on May 1, 2016 |
|
#
¿
May 1, 2016 18:08
|
|
|
Subjunctive posted:The HIPAA Security Rule has malicious software protection as Addressable rather than Required, and certainly doesn't mandate lovely consumer AV. There are definitely HIPAA compliant shops that don't install AV on end user PCs. And HIPAA auditors look for some way that you have addressed the risk posed by malicious software. Most of them take this to mean that you need AV. You can meet the requirement in other ways. But those tend to be a pain in the rear end. (But so is AV, so meh.) Not talking about consumer grade AV here btw. I have seen hundreds of clients forced to install AV because a PCI auditor told them he wouldn't pass them unless they did. But some auditors overlook it totally every now and then. Its really odd. I will admit that my experience with government contracting is pretty thin. The one client I had that was in that field swore up and down that AV was an absolute requirement. He also had a bunch of other wacky requirements, like only US citizens could work on his stuff, and only after they had been though a background check, so I don't know. Antillie fucked around with this message at 18:22 on May 1, 2016 |
|
#
¿
May 1, 2016 18:15
|
|
|
I haven't run AV on my personal machines for about 4 years and have not had any problems. Mostly because in the previous 12 it only ever caught two things. Both of those were direct results of me doing things that I knew full well I shouldn't have been doing. In my experience AV is slow, costs money I would rather spend elsewhere (only $35 for one year of Kaspersky on three machines, but still), and doesn't provide much actual protection. Not being an idiot is far more useful for the security of your machine than any AV ever will be.
Antillie fucked around with this message at 14:28 on May 2, 2016 |
|
#
¿
May 2, 2016 14:26
|
|
|
Daman posted:...but for most products when the bug is found it has pretty fast response time to patch... I will admit that this is in fact true for some vendors. The IKE buffer overflow in the Cisco ASA in February would be a good example of a super fast patch made to a number of different code trains for the same device family. (Ok, Cisco knew about the issue before the general internet did. But still.) However many many vendors are terrible about this sort of thing and take stupid amounts of time to issue patches. Even then the patches don't always actually fix the problem. You would be amazed how often a vendor will tweak something minor so that example exploit code no longer works but then someone slightly modifies the exploit code to get around the fix within a day or two because the vendor didn't actually fix the underlying issue.
|
|
#
¿
May 3, 2016 04:42
|
|
|
Wiggly Wayne DDS posted:It's heuristics with marketing, and they refuse to give anyone access to analyse it without signing a NDA Any security product that you can't test/analyse without an NDA isn't something I would want to buy. NDAs always make me think of snake oil. Independent verification is crucial in the security world. Antillie fucked around with this message at 14:31 on May 5, 2016 |
|
#
¿
May 5, 2016 14:26
|
|
|
Mustache Ride posted:Yeah, in the sit down the Sales Engineer had some intersting things to say about some of the questions I had, including, and I quote "We're not on Virustotal because we would catch everything and then the big 6 would use us as a reputation source and everyone would be using our engine." So either they are allergic to money or they don't think their product will stand up to serious scrutiny. Since they are a for profit company I find the former very doubtful. Which leaves the latter. Antillie fucked around with this message at 16:33 on May 5, 2016 |
|
#
¿
May 5, 2016 16:30
|
|
|
Thanks Ants posted:There's no doubt quite a few appliances that have expired service subscriptions running affected versions of their scan engine. Even then many organizations apply updates and patches at glacial speeds. Some don't apply them at all. This will be around for a while.
|
|
#
¿
May 17, 2016 18:32
|
|
|
EssOEss posted:I run software BitLocker on all my mobile computers and I have never felt any performance degradation. Sure copying 50 GB of files might take a bit longer but that is not even remotely part of my daily workload. With an SSD you're not really waiting behind I/O as much as you are waiting behind poorly designed synchronous software that can only do 1 thing at a time. Bitlocker totally off loads all crypto work to hardware acceleration when an SSD with said acceleration is detected. So people using bitlocker with an SSD that has a broken encryption implementation are getting effectively zero security and would never know it. Some of the performance difference comes down the mode of cipher operation. CBC for example cannot be multi threaded when encrypting but can be multi threaded when decrypting. GCM can be done multi threaded when both encrypting and decrypting. Antillie fucked around with this message at 15:29 on Nov 7, 2018 |
|
#
¿
Nov 7, 2018 15:26
|
|
|
|
| # ¿ Apr 27, 2024 19:43 |
|
|
Well at least there is a work around. I wonder how many people will just keep on trucking totally oblivious to the issue.
|
|
#
¿
Nov 7, 2018 23:45
|
|