|
 THREAD MASCOT quote:Don't roll your own crypto. recommended resources: SecLists.Org Security Mailing List Archive attrition.org r/netsec r/crypto conferences/gatherings: BSides (check for one local to you!) Black Hat DEF CON ShmooCon recent news: HardenedBSD ends their call for donations on a successful note Let's Encrypt begins closed beta CISA is revealed to not contain Senator Whitehouse's CFAA amendment more resources: VulnHub - Vulnerable By Design OverTheWire SmashTheStack RISCy Business fucked around with this message at 14:52 on Dec 18, 2015 |
#
?
Nov 8, 2015 02:00
|
|
|
|
| # ? Dec 5, 2024 03:55 |
|
|
reserved just in case
|
|
#
?
Nov 8, 2015 02:00
|
|
|
on this topic, if anyone needs/wants an invite to keybase, i have 5 left- send me a pm or an email (root[a]reverie.pw) with your email address and i'll get you squared away
|
|
#
?
Nov 8, 2015 02:05
|
|
|
hey, remember Linux.Encoder.1? turns out it sucks http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/ quote:We mentioned that the AES key is generated locally on the victim’s computer. We looked into the way the key and initialization vector are generated by reverse-engineering the Linux.Encoder.1 sample in our lab. We realized that, rather than generating secure random keys and IVs, the sample would derive these two pieces of information from the libc rand() function seeded with the current system timestamp at the moment of encryption. This information can be easily retrieved by looking at the file’s timestamp. This is a huge design flaw that allows retrieval of the AES key without having to decrypt it with the RSA public key sold by the Trojan’s operator(s). 
|
|
#
?
Nov 13, 2015 16:15
|
|
|
hmmm wow I just hmmmmmm I mean go on wow this is so interesting tell me more
|
|
#
?
Nov 16, 2015 04:40
|
|
|
mindphlux posted:hmmm wow I just hmmmmmm I mean go on wow this is so interesting tell me more i love watching literal mongoloids post so thank you for this opportunity
|
|
#
?
Nov 17, 2015 05:14
|
|
|
some shady poo poo coming out of the marketing world (again): Beware of ads that use inaudible sound to link your phone, TV, tablet, and PC quote:Cross-device tracking can also be performed through the use of ultrasonic inaudible sound beacons. Compared to probabilistic tracking through browser fingerprinting, the use of audio beacons is a more accurate way to track users across devices. The industry leader of cross-device tracking using audio beacons is SilverPush. When a user encounters a SilverPush advertiser on the web, the advertiser drops a cookie on the computer while also playing an ultrasonic audio through the use of the speakers on the computer or device. The inaudible code is recognized and received on the other smart device by the software development kit installed on it. SilverPush also embeds audio beacon signals into TV commercials which are "picked up silently by an app installed on a [device] (unknown to the user)." The audio beacon enables companies like SilverPush to know which ads the user saw, how long the user watched the ad before changing the channel, which kind of smart devices the individual uses, along with other information that adds to the profile of each user that is linked across devices. some of the stuff that can be transmitted:  it can also trigger a recording as seen here code:RISCy Business fucked around with this message at 15:56 on Nov 17, 2015 |
|
#
?
Nov 17, 2015 15:39
|
|
|
How is it going to record that data on any of your devices though? You'd have to be stupid to install their software on your phone or am I missing something here and they're exploiting something? Ah I see, some apps might be using their SDK. I wonder how long before we get someone writing a program that can check for the SDK being used. I'm sure it has to have some form of normalized API calls.
|
|
#
?
Nov 17, 2015 16:00
|
|
|
Stanley Pain posted:How is it going to record that data on any of your devices though? You'd have to be stupid to install their software on your phone or am I missing something here and they're exploiting something? yeah, it doesn't have to be THEIR app, just one utilizing their SDK. and what is pulled and sent is up to the whim of whoever runs that app. it would be possible to sniff out calls using wireshark if you're curious and think you may have such an app, since it seems a lot of them[citation needed] use the same url schema, you could use: http.request.method=="POST" and http.request.uri contains "/oapi/getAd"
|
|
#
?
Nov 17, 2015 16:06
|
|
|
Is this the thread where I can learn to be Anonymus and pwn noobs over the internet ?
|
|
#
?
Nov 20, 2015 00:22
|
|
|
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 16:52
|
|
|
Nice thread topic! I'd like an effective and relatively simple way of turning a short password into a hash type string to use as a passphrase for AES encryption please. In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password! I looked at PBKDF2, which seems ideal for stretching a simple password into an indecipherable string and then found out that there are better alternatives, such as bcrypt which has more expensive overheads if someone attempted to reverse the data. The problem with bcrypt (and scrypt, I believe) is that they are geared toward storing passwords for web services and produce a more complicated output than I desire. I just wanna derive an encryption key from a simple string. PBKDF2 looks the sort of thing I'm after but there doesn't seem to be a standardized implementation of it. I want to encrypt something with the knowledge that I can decrypt the file in maybe 5 years time, possibly using a different OS (it will still be Linux based, though) or platform. At least MD5 and SHA256 are both standardized algo's and produce the same result over all platforms. What do you guys use to manually scramble your passwords? Please don't suggest keepass2: I'm looking for simplicity. Thanks.
|
|
#
?
Nov 20, 2015 17:23
|
|
|
DeaconBlues posted:In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password! 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. Don't make this more difficult than it has to be, just use md5. Edit: Holy poo poo you guys, this post was joke response to a post that I'm still pretty sure is itself a joke. I mean I called Keepass "super complicated and hard to learn," because he said "Please don't suggest Keepass, I'm looking for simplicity," after asking for help with a hilariously convoluted method of creating passwords. I don't think anyone who actually thinks Keepass is super hard would be able to find the "Post" button. Theris fucked around with this message at 18:57 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 17:37
|
|
|
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 17:43
|
|
|
DeaconBlues posted:Nice thread topic! 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.
|
|
#
?
Nov 20, 2015 17:51
|
|
|
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 18:17
|
|
|
Antillie posted: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. 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.
|
|
#
?
Nov 20, 2015 18:23
|
|
|
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. seems legit
|
|
#
?
Nov 20, 2015 18:34
|
|
|
Wow. I was considering throwing "What is wrong with you? Just use keepass." in spoiler tags, but it really seemed like he was joking so I just went with it. Poe's law is a bitch. 
Theris fucked around with this message at 18:44 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 18:42
|
|
|
poe's law
|
|
#
?
Nov 20, 2015 18:45
|
|
|
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 18:48
|
|
|
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. Just use a password manager you doofus. KeePass is free.
|
|
#
?
Nov 20, 2015 18:48
|
|
|
Antillie posted: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. Sorry, I misread your previous post and thought you were backing up the user data yourself.
|
|
#
?
Nov 20, 2015 18:58
|
|
|
don't joke about my insecurity
|
|
#
?
Nov 20, 2015 19:03
|
|
|
It wasn't a joke post. Yep, I do use a password manager (LastPass) but I knew there'd be people recommending Keepass so I mentioned I don't want to use it. In my case I want to stretch a simple, easy to remember password into a long key. Whoever suggested that I am using multiple instances of this technique are wrong. 99% of my passwords are unique and are stored in LastPass (with 2FA via YubiKey, so don't get smart on me and keep mentioning Keepass). The point is that I want to stretch an easy to remember brain password into a long key for use with AES encryption which I will only use on a couple of files that are important to me.
|
|
#
?
Nov 20, 2015 20:16
|
|
|
DeaconBlues posted:It wasn't a joke post. Yep, I do use a password manager (LastPass) but I knew there'd be people recommending Keepass so I mentioned I don't want to use it. Does that help?
|
|
#
?
Nov 20, 2015 20:26
|
|
|
No it doesn't help. This helps: Is the use of a long string of pseudo-random digits as a key for AES encryption more secure than a short password that one can remember? Answer me that and you'd be helping. x
|
|
#
?
Nov 20, 2015 20:37
|
|
|
Please stop ruining the security thread
|
|
#
?
Nov 20, 2015 20:42
|
|
|
DeaconBlues posted:No it doesn't help. This helps:
|
|
#
?
Nov 20, 2015 20:45
|
|
|
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 21:30 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 21:14
|
|
|
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 21:25
|
|
|
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  ". 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.It's about ethics in cryptography.
|
|
#
?
Nov 20, 2015 21:29
|
|
|
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 21:36
|
|
|
Thanks for the last few replies. Entropy is an interesting concept. I'll keep my particular case simple. Here's what I think I should do: 1. Hash the simple password that's only in my head. Lets say my password is this car registration: "E207HVT". 2. SHA256 of E207HVT=baff2ddde4043bfcfe6dbf67ecfca2b5f8a3a90e7b4939632ce82565c3fe25b2 3. Encrypt the file using AES using the hash of simple brain password and store the file onto SSD/USB/whatever. I get burgled and the thief is quite good with computers, but no genius. The thief now has to try and brute-force a 64 character string, rather than a 7 character string. Am I doing it right?
|
|
#
?
Nov 20, 2015 21:38
|
|
|
Right, perhaps not if you are producing a product, but it is good to have an understanding of its use. It's a matter of trust in that regard. I understand how RSA and AES and SHA work, but not when it comes to using ECDH or different padding or something. I trust those (and their implementations) by virtue of my understanding of them, and by knowing the situations of where they do start to unravel. But I've only ever had to implement ElGamal, and it was not fun and it would had been easier to use a proper one. I dunno, I had an argument with some developers of some open source crypto application over not using the NIST curves or EC at all as the default scheme simply because none of us were actually well versed in how they work. They're faster, sure, but that's not the point ... dougdrums fucked around with this message at 21:54 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 21:52
|
|
|
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 22:00 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 21:53
|
|
|
For serious things I use a nonsense sentence, or a dumb joke I haven't told anyone, and remember it and the steps I use to manipulate it. Sometimes this involves Cyrillic or Chinese characters if allowed. I'm pretty sure that's the best any human can do.
|
|
#
?
Nov 20, 2015 22:00
|
|
|
What you've mentioned there, dougdrums and Antillie, were my concerns about just using a hash. Particularly about the thief knowing about hashing and trying various hash algo's during the brute-force attempt. From the bits and bobs I have read, PBKDF2 and bcrypt are better than simple hashing because they utilize CPU and RAM more when doing a calculation. So if the attacker's PC is capable of performing a SHA256 hash in 0.001 seconds it might take the same PC 0.1 seconds to perform a PBKDF2 function. When you consider the number of permutations that the attacker has to generate before he/she finds the key that can make a major difference in time. I can only guess, but the difference between using a simple hash and PBKDF2 to find a 20 character password might be a difference of taking a few hours to a few years if each calculation is 100 times slower.
|
|
#
?
Nov 20, 2015 22:12
|
|
|
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 22:28 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 22:25
|
|
|
|
| # ? Dec 5, 2024 03:55 |
|
|
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 22:37 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 22:33
|
|