The Stack Overflow podcast is back! Listen to an interview with our new CEO.
111

You can't. To securely send information over an unsecure channel, you need encryption. Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*]. That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, ...


109

You can't, plain and simple. If you don't trust the hosting company, you don't host with them. This is law #3 from 10 immutable law of security: Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore. The hypervisor always have privileged position over your virtualised machine, you can't protect yourself ...


108

Option 1 is more secure. In option 2, we can guess each word seperately. When we guess "amazing", we get confirmation that this word is correct and we can continue to the second word. In option 1, we have to guess all four words at the same time. You may think that one GPG offers some security, and four GPGs offer four times that security, but it doesn't ...


102

Disclosure: I work for one of vendors participating in NoMoreRansom. Most modern ransomware indeed implements proper cryptography. Earlier versions were using rand() for key generation, seeding the random generators with variants of time() - this is why it was important for successful decryption to know when exactly the infection happened; ideally down to ...


100

Your most recent edit indicates that your pictures are procedurally-generated, so your key size will therefore be bounded by the amount of state required to generate an image. Yours seem to be parameterized by four floats for the initial conditions (and fixed output image size, camera location, point light location, convergence conditions, etc). Those 128-...


94

If you’re designing a cryptosystem, the answer is No. Kerckhoffs's principle states “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.” Restated as Shannon's maxim, that means “one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.” Making the ...


78

Without access to the key, then the problem for attackers is the same as if there was no backdoor key: the attackers would have to break the encryption itself. But ... If we assume that the private key of the base station is secure Your base assumption is the one that requires challenge. That there is a key is the problem. key handling key misuse key ...


64

Sparks stores your account credentials on their systems. This is also described in their privacy policy: INFORMATION WE COLLECT AND HOW WE USE THIS INFORMATION Auth login or mail server credentials: Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages and other ...


63

Any encryption is vulnerable to brute force attack, for example AES-256 has 2^256 keys, and given enough hardware we can “easily” brute force it. The problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. The fact that encryption can be bruteforced doesn’t mean that this will happen ...


50

It is just a cost/gain question. Ransomware developers generally do not want to build a security tool with all the involved reviewing. They just want the less expensive tool that will allow them to get more money than it cost. Of course, they are probably breakable, but who cares? Provided some of the first victims have paid what they were asked, the ...


48

At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK. When changing the password, the DEK is simply encrypted with a new KEK ...


48

tl/dr: Your selected version of the JWT doesn't encrypt anything, it merely encodes it for easy transport. The data in the payload is not meant to be a secret. You have a JWS (JWT with signature). What you are looking at is simply the base64 encoded data payload. A JWS contains 3 parts: The base64 encoded header The base64 encoded data A cryptographic ...


46

TLS is really the only way to do it. But what if I encrypt it with JavaScript? The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered. Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts. Glad you're using modern tools to help ...


46

In practical terms, no, as John's answer neatly explains. Hypothetically, if you had enough secure encryption methods to choose from, you could potentially select one method at random and use it to encrypt the data using – for example – a 256-bit key. The choice of algorithm used would need to be "added" to the key and become part of the "not to be revealed ...


35

Realistically, no you cannot. AES is very resistant to known plaint text attacks like most block ciphers. It's lucky you didn't lose any information and have the original database backup because your only real option would be to try brute force the encryption, which is likely to take longer than the length of the universe (unless you can greatly narrow down ...


30

Proton Mail uses an encryption format called OpenPGP. It is only designed to encrypt the message. Unless the subject is put in the message and the subject field is left blank, the subject will be kept unencrypted. The e-mail sender and receiver fields, on the other hand, need to be unencrypted for proper routing to occur. This is all a limitation in the ...


29

This doesn't add security, but makes it easier to guess the passphrase one word at a time (N⁴ vs. N+N+N+N, where N is the symbol count of the word list). Even when you encrypt a file or a message to multiple recipients using PGP, the payload is encrypted only once using symmetric encryption, and then the key for that is encrypted separately for every ...


28

Having an encrypted text file with passwords in it is certainly better then having common/reused passwords or an unencrypted file. A good password manager is, however, incrementally better, in the following ways (off the top of my head) Better memory management - it can prevent passwords being left in computer memory which can be snaffled by other ...


27

While I agree that every point of schroeder's response is true, there are two deeper issues that make it so much more dangerous than the current model of security. Right now, if you install an encryption key on a system, that key only controls your system and can only be accessed by the people you trust to access your system. Breaking into any system is ...


27

Letting your database handle the encryption/decryption is probably for the best: You don't need to write any encryption/decryption code and risk breaking your own security by accident. This also means, as Guntram Blohm pointed out, you won't have to prove your own security to be secure, if it comes down to it. And proving your custom software secure is as ...


27

There's a bit of confusion of terminology here. JWT defines the basic format of the claims, and some standard claims. It specifies that the JWT Claims Set should either be the payload of a JWS or a JWE structure. JWS defines a structure for some payload with a signature. While the payload is almost always JWT in practice, this is not a requirement of the ...


26

While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange. It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password....


25

Theoretically, there's no limit on the number of times you can encrypt a file. The output of an encryption process is again a file, which you can again pass it on to a different algorithm and get an output. The thing is, at decryption side, it will have to be decrypted in LIFO (last in, first out) style, with the proper passwords. For example, if your file ...


23

A picture is far too large to use as an encryption key directly, you'll want to run it through a KDF first. It also depends entirely on the picture whether it will have enough entropy to be useful. You could have a 1000x1000 image that's solid white, but it would be useless as a key as it contains no entropy. Pictures from cameras tend to have a fair amount ...


21

The obvious answer is that no criminal would want to interact so directly with their victim. "send the encrypted private RSA key to the attackers" requires a consistent point of contact. In the current model, all the communication is one-way and fungible: malware displays a screen instructing the victim to deposit bitcoins (no direct contact) ...


20

Didn't veracrypt creators know about this issue? (Not having brute-force protection) As Andrew Morozko notes in his answer, they have addressed this – as far as it is possible – by using a secure key-generation function (PBKDF2) and high iteration counts. This severely limits the ability to brute-force (assuming the password is long- and random-enough1)...


19

Imagine a Hollywood film where they're cracking a password or a security code, with all the spinning digits on a fancy UI, and they have elite hackers who crack one digit of the code at a time, and the good guys have to work to blow up the hackers' computer or something before they crack that last digit. Of course, in real life it isn't like that — for ...


19

so that it would not be economically viable to spend time & resources to get them. I hate to break it to you, but you simply aren't that important. No-one knows you or your web app. So it's already not economically viable. Consider the cost-benefit. For the hosting company, if this happens once, they'd hemorrhage customers. So they're going to have ...


18

Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application. The ...


18

If there's a backdoor, it will be abused. The question is when, not if it will be abused. There are too many actors that could compromise such a system, and no easy way to plug the holes. If a private key leaks, it's done. It's cheaper to all involved to ignore the leak until there's a high profile case blowing to the press. Changing every key on every base ...


Only top voted, non community-wiki answers of a minimum length are eligible