SSO software – where is symmetric key stored? In SSO software (Oracle E-SSO …), I heard about (primary) key encrypting user’s credentials, but I can’t read anything about how this key is managed ?

When using smartcard, I can understand that this key is encrypted/decrypted using another key pair on the card, but when smartcard is not part of the scheme, how does it work ?

It depends a lot on the software and SSO protocol.  There are a wide variety of "keys" and "secrets" in play when dealing with SSO.

For the sake of contrasting different keys, consider your example of a smart card.  Usually this is used for authenticating the user.  A system would generally know about the user's public key already, and issues a challenge to the smart card which it digitally signs and returns to the sign-on system.  That system can then use the previously known public key to verify the user's digital signature.  Only the smart card can produce a valid digital signature because only it holds the private key.

SSL is not a form of SSO, but for the sake of conceptual understanding, the above is similar to how SSL works.  There are two aspects of SSL, encryption and authentication of the remote server.  Lets' just speak in terms of authentication.  When you go to stackexchange.com, how do you really know that it is not a fake server pretending to be Stack Exchange?  SSL involves the server holding the private key, and you are able to verify the digital signature it produces with that private key, because you hold the public key of the authority that issues the certificate(such as Verisign, which is installed in your browser).  There's a lot more to it, but usually on the server side you install your private key certificate into a certificate store which is only accessible by administrators with sufficient access to the server.  The actual implementation of a certificate store is dependent on the operating system we are talking about.

(While I stated SSL is not SSO, it is often used are part of the SSO process to secure communication between parties.)

In SSO, often there are 3 parties involved.  The user who wants to login, the server who knows who that user is, and the server who wants to verify that user's identity(the server the user wants to log in to).  Depending on the particular SSO implementation, one or both servers may store one or more shared secrets that are used in the process to allow the servers to verify that one-another are authenticate, or sometimes used as part of a key generation process to establish an encrypted connection.

I say all this to emphasize that there is not always a stored symmetric key.  Some processes use asymmetric keys to generate a symmetric key on the fly, so you don't have to store a symmetric key.  Some process use a shared secret as part of a hash to generate a post from the user, which prevents tampering with the post.  In such an SSO scheme there may be no need for a symmetric key at all.

Where are symmetric keys stored?

Often times if you are the programmer implementing one side of an SSO process, then it is up to you how you store shared secrets and/or keys. It is often best to do so in a way the minimizes any potential access from employees. Follow the best practices of your platform.  For example, if certificates are involved, then store them in the OS's certificate store and ensure only the most minimum number of employees have permissions to that certificate store.  Ensure your server's are physically secure.  There are a lot of best practices that assume your servers are physically secure.  Unfortunately there is no perfect answer when it comes to securing keys on a server, because usually the software involved in the SSO process at some point has to access the key as part of the process, meaning the software must have permission to access the key.  Keys/certificates can be encrypted with a password, but every time the server restarts you'd have to re-enter the password.

C# apps, for example, provide ways to encrypt configuration data, where you could store such keys.  But the encryption uses another key stored on the local machine, so anyone with sufficient permissions to the machine, and/or physical access, can with enough effort decrypt that config and get the shared secrets.

Hardware Security Modules (HSM)

I do not know much about these, but the idea is that the key is stored in this piece of hardware, and does not expose the key through any network interface.  Instead you send requests to the HSM for the steps which involve the key, and it performs whatever crypto processing is necessary and returns the result.  For example, during SSL when the certificate's private key is used to generate a session key.  It is usually in the form of a rack mount piece of hardware, or some sort of PCI card.  The impression I get is they are only useful for certain functions, since they have to perform all of the cryptography functions, then if you are doing something custom this probably won't work for you.

Very similar in concept to a smart card, in that the key never leaves the device and performs the request crypto operation.  But of course providing many more functions besides just signing, and usually with alot of additional security features as well as accelerated performance.  That is based purely on what I have read about them though, so don't consider that an endorsement.  In theory though they sound like a great idea and seems like mission critical operations like banks/finance use them.


Can the location of a cellphone be pin-pointed? If a person uses a SIM card that is pre-rica registered (meaning it is not registered on his name but the supplier), can you pin-point where a particular message or call was made from? For example: the person was at 2 Simon street @ 18:00 on 5 September2015 when the making the call or sending the message.

.. can you pin-point ...

This depends who 'you' are and how exact you need the location.
A mobile phone needs to connect to a nearby base station in order to send the message. Each base station can serve a number of users in parallel and also has a limited reach, which is even more limited in cities because of all the buildings. If you know which base station the phone is connected to you can tell the area where the phone currently is (accuracy can be 50m in cities).

The operator of the network does know which mobile phone is connected to which base station. It will also store these information for a while and will usually provide law enforcement with this information. But as a normal user you don't get access to these information.

For more information see wikipedia:mobile phone tracking.


PKI certificate validation graphs, trees and cross signing I am just trying to get the basics of PKI and TLS and understand how it works. I came across Mozillas post about pkix where they mention that the new library allows graph processing and hence it handles cross-signed certificates, which is difficult via prior libraries since they use trees. This also removes the requirement of using AKI (authority key info).

Can anyone please elaborate what this means, what cross-signing is and details about AKI ?

Thanks

AKI :

Authority Key identifier which is one of the certificate extension in PKI , through which we can identify the CA public key hash. It can be 160bit hash or 60 bit hash depends upon the CA who signs the certificate.

Cross - signing :

When cross-signing is implemented, the certificates are logically chained to the trusted

root CA of the organization that is evaluating the presented certificate.


Intercepting business calls and forwarding them back to me My sister recently went on a sales call and when she told them what company she worked for they were upset.  They told her that the company she works for is stealing their customers by intercepting and forwarding their phone calls.

Sure enough when my sister dialed their number it was going to her company!

I have looked all over the internet and no luck in finding an answer. How is this possible and how would this company stop this other company from doing this?

It took me a while to understand this question. I believe that the problem is "Dialing the number registered to Company A connects the caller to Company B".

Ultimately, this is an issue that can be resolved with systematic troubleshooting.

1) The caller is making a mistake (dialing the wrong number). Some phone exchange systems may expect particular prefixes or suffixes that require the caller to modify the number they input.

2) The phone provider the caller is using is misdirecting the call somehow (deliberate or accidental). You can rule this out by repeating the call from a different provider (use a difference cell phone company, or a pay phone).

3) Company B does actually own the number being called; the error is in the caller thinking the number belongs to Company A.

I very much doubt that any "call intercept" is being performed here. It's difficult to do unless you have significant access to the telecommunications network - it's the sort of thing that we would expect only government agencies to be capable of doing. Tampering with the phone system is usually illegal in any country, and doing so in this way would immediately lead investigators to their prime suspect.


Best practice for using Veracrypt on Dropbox I have a Dropbox account subscription so I have a lot of space to use and I basically put everything there. There are somethings (personal health / finance) that I want to keep protected myself so I want to use Veracrypt.

What are the best practices I should follow for keeping Veracrypt files on Dropbox? Should I use one large Veracrypt container and put everything there? Should I split up my files into smaller containers? Is there a difference? Is there significant security loss for having an encrypted file that is changing often and it's history is potentially recorded by Dropbox?

Unfortunately, I think the answer should be: Don't use a VeraCrypt container with Dropbox, at all.

According to https://www.veracrypt.fr/en/Modes%20of%20Operation.html

  The mode of operation used by VeraCrypt for encrypted partitions, drives, and virtual volumes is XTS.

And also

  In 2010, XTS mode was approved by NIST for protecting the confidentiality of data on storage devices [24]. In 2007, it was also approved by the IEEE for cryptographic protection of data on block-oriented storage devices (IEEE 1619).

However, Dropbox is not a regular "storage device" or "block-oriented storage device"!

In conclusion, as long as VeraCrypt is using XTS, it shouldn't be used with Dropbox. Also, see this question Is it safe to have a TrueCrypt container file synced with DropBox? as well as the blog post You Don't Want XTS.

To quote from the latter mentioned blog post:

  Remember that disk encryption is designed to counter an attacker with very limited capabilities. That’s why it falls to “Evil Maids”: the threat model doesn’t really accommodate attackers with multiple bytes at the (physical) apple. But whatever margin of safety XTS gets you on physical media probably goes out the window when you stick a Truecrypt volume on Dropbox. From the vantage point of Dropbox, attackers have far more capabilities than the XTS designers planned for.


Theoretical and practical limits on adblocking Not sure if this is the right SE, feel free to migrate if necessary.

My question is simple: the only way for a web server to detect if you are adblocking is to see if the ads were actually served, since once they're client-side it's trivial to just not show that part of the html. Right?

I understand why adblocking software doesn't download the ads: it would be very wasteful. But what I don't get is, for sites like Forbes that force you to turn off your adblocker, why not just have a mode where you can download the ads anyway and just not show them? As opposed to having to turn off the adblocker.

If I download the ads but don't display them, is there any way the web server could detect I'm adblocking? Like with client-side JS or something? What are the theoretical limits and practical limits on adblocking?

Taken to the extremes it could deteriorate into an arms race which the client (person reading the site) could always win.

Yes the publisher can check that the reader is showing their ads, they can examine the DOM and return is the ad is visible.

Then the adblocker could modify this call to all ways return true to the publisher.

Then the publisher could require the client to return a hash of the content and the DOM model.

Then the adblocker could calculate this hash itself.

Then the publisher could do a advertising CAPTURE to ensure a human has read and understood the ad.

Then the adblocker could outsource solving of captures either to low paid human contractors or AI.

Etc etc.

As the adblocker is in control of the client it would be hard to defeat. Well before this level has been reached it will become uneconomic for one or both of the parties to continue.


Master Password vs Passphrase About a year ago, I tried using LastPass but found the user experience very lacking, and went back to my tried-and-true method of just having a bunch of different passwords (some password reuse, but I've never ran into problems with it) and my email has a unique, non-reused passphrase of 30+ characters and I reckon I could just password reset any service eventually hijacked.

I know this is not good, and I understand the consequences - this is not about that.

I recently decided to "hey, let's give password managers another shot" and this time went with Firefox Sync (& Master Password).

From what I've noticed, it encrypts the locally stored cryptoblob  using a key, which is in itself encrypted using the master password. The passwords stored on their server is (for some reason) encrypted using my Firefox Sync password (which is, of course, stored in the cryptoblob).

Full disclosure: My Firefox Sync password is not as strong as my master password. If someone stole it, they could theoretically download an unencrypted copy of my password blob to a new device simply by logging into my account. However; this requires me to confirm the login from my e-mail. The password to my email is, at current date, the same passphrase I use for my firefox master password.

Now, to the question: Is there something inherently less secure in using a long, humanly memorable passphrase (my master password) for my e-mail (which is required to download my cryptoblob) than having it be a data-secure password stored in said cryptoblob?

It depends on how you generate your passphrase.

A passphrase derived from a story, or a song lyric, or a book or poem quote, is inherently insecure. Crackers are already using quotes from publicly available works, and common transformations of them (like taking the first letter of each word) to guess passwords.

A passphrase you made up yourself is better, but it is still inherently less secure than a fully randomized password. It will have sentence structure, probably will favor commonly chosen words, etc. How much less secure is very hard to quantify; there have been studies that figure out entropy of passphrases character-by-character. Still, it's a better than a publicly available phrase, and a lot better than a single-word password with or without transformations.

But you could also make a fully random passphrase, Diceware-style. With enough words, these can be made as secure as you like; a diceware passphrase with N words tends to be about as secure as randomized, mixed-case with digits and special characters password with 2N characters. With a random passphrase, there is nothing inherently insecure about it; you can use this method whenever the service allows enough characters for 6-8 words.


Encrypt then checksum or vice versa? This is probably a naive question, but here goes: What is better for security over TCP/IP?

Encrypting the payload and then adding a checksum?
Checksuming the payload and then encrypting it?
Checksuming the payload and then encrypting it, then checksuming again?
Something else entirely?

And by security, I mean bad guys can't read the payload, replay the messages, inject their own messages, or modify the messages in transit without detection.

For the practical answer, what's best for security is to avoid reinventing the wheel. Designing a secure protocol for data transport is a daunting task (it's easy to make it work, it is hard to know whether it is "secure"). There are already a few known protocols which have been studied a lot, and are available as ready to use library. Foremost of which is SSL/TLS. You might want to use DTLS if you want to protect individual packets (DTLS is to UDP what TLS is to TCP).

For the scientific answer: when it comes to encrypting some data and protecting its integrity, best idea is to use an encryption mode which does both (GCM and EAX are the usual suggestions). If you have to rely on separate algorithms for the encryption and for the integrity check (what you apparently call a "checksum" but is better known as a MAC), then the correct way is to encrypt first, then compute the MAC on the encrypted data (not forgetting the IV and some other stuff, as explained in this question).

But let me point out that this is only part of the protocol. Doing encryption and a MAC on a "payload" assumes that sender and receiver already share a common high-entropy secret value which they can use as key for the encryption and MAC. You also need some more features to avoid replay attacks, and, more generally, defeat attackers who would try to drop packets, duplicate packets, and reorder packets. Authentication (one-way or mutual) is yet another tricky area.


Isn't openid with http an issue? Many openid enabled sites default to http identifiers, even if the openid provider supports https (such as myopenid.com).

Does this pose a threat beside the identity being exposed? The second step of the openid authentication includes a verification of the signature provided by the identity provider. But couldn't a rough identity provider just sign anything? I mean is there a step in the openid protocol that verifies the provider is valid for the entered openid?

Edit: This question is about consumers such as Stack Exchange, not identity providers. Stack Exchange only uses https for Google, and unencrypted http for all other openid providers. I know that myopenid.com does support https, but Stack Exchange does not use it. The same is true for other sides, even ones that usually take security more serious than Stack Exchange, e. g. Source Forge.

In general, there are several security issues with OpenID, but also many different scenarios for its use. So depending the threat model you may or may not want to rely on it, and users may or may not want to use it for authentication.

As you note, possible exposure of your credentials is a problem, e.g. if you choose an OpenID provider that authenticates with passwords and doesn't require https.  That goes for any site that asks for a password over a connection other than https.  But note that identity providers not only can use https, but could also authenticate via more secure hardware tokens or one-time passwords.

Problems with phishing are particularly challenging when the user doesn't properly use a carefully-designed user interface for authentication, which is one thing that led to the development of the client component in CardSpace.

OpenID 2.0 is a bit better than 1.0, but issues like privacy and trust remain.  Alternatives include SAML (e.g. via Shibboleth) and CardSpace.

Here are some links for more info:

Stefan Brands: The problem(s) with OpenID

If you want an answer specific to Stack Exchange policies, ask on https://meta.stackexchange.com/


Using javascript, is it possible to iterate through all cookies saved in the user browser and send them to me? Again, I am new to the programming and security world.
I should mention that it is just a theoretical question so I can anticipate this kind of attack.

Using javascript, is it possible to iterate through all cookies saved in the user browser and send them to me?

You can only iterate through cookies associated with the site the javascript is executing from.  And you can only iterate through cookies that are not marked as server only (newer browsers only though).

This is a form if Cross Site Scripting (XSS). http://en.wikipedia.org/wiki/Cross-site_scripting


Are IDE DMA attacks possible and is it possible to prevent them purely with software means without any IOMMU or other special hardware I mean if it possible to safely plug a PCMCIA card into a PC without IOMMU? Such computers are very widespread, every digital TV or receiver has a CI+ slot, which is PCMCIA, and people insert there cards they don't control and which they haven't audited. I wonder if the ones doing it give ultimate control on their hardware to the entity responsible for card firmware.
Is it possible to create an universal rooter for TVs and receivers based on a custom PCMCIA card? Or can it be that all the TVs are backdoored by backdoored CI modules?

The IDE interface itself does not allow DMA, but PCMCIA does.

DMA requires a feature of the PCI bus called the bus master enable bit set by privileged software that recognizes the DMA-capable device and enables it. A hardware driver can enable bus master for any PCI device with DMA capabilities. This is what happens to both the internal IDE hub (in the ICH) and the PCMCIA card. The IDE protocol itself does not support DMA. The main difference is that the ICH is internal and trusted, whereas PCMCIA is external and untrusted. Because of this, connecting a new PCMCIA card is far more risky than hooking up to an untrusted IDE device.

  is it possible to prevent them purely with software means without any IOMMU or other special hardware

It is technically possible to prevent this in software, assuming no ugly bugs in implementations of the PCI specifications. However, it would require modifying the driver software to not grant bus master capabilities to that interface when a device is plugged in which would most likely completely prevent the card from functioning. At the very least, it would limit it to the obscenely slow PIO mode for IDE, rather than the much faster UDMA mode that, as the name implies, requires DMA. PIO is slower because it needs to involve the CPU for every data transfer, which is very inefficient. If PIO is not supported and DMA is disabled... well then the PCMCIA card will not function at all.

  Is it possible to create an universal rooter for TVs and receivers based on a custom PCMCIA card?

This depends on whether or not the TV or receiver is running an architecture that supports DMA and does not have an IOMMU or any other protections against rogue direct memory access. A TV or receiver is an embedded system and might not behave like the familiar IBM-style x86 PC.

  Or can it be that all the TVs are backdoored by backdoored CI modules?

This is not something anyone can know without auditing all the TVs. I would hazard a guess and say no, simply because it would be so easy to detect (and so hard for a single malicious card to support a reliable attack against a large number of presumably heterogeneous TV models).

DMA and PIO are the two ways to do I/O. PIO is significantly slower than DMA.

It might be useful to understand why DMA exists and how it works. When DMA is supported, a dedicated region of memory is set up and the controller (whether the ICH or PCMCIA) directly writes the data read over IDE to that memory region (using the DMA-based UDMA or MDMA protocols). From the CPU's perspective, it issues a command to read data and then can go do its own thing, knowing it will be asynchronously alerted with an interrupt as soon as the process has been finished, with the requested data waiting right there in memory for it. Likewise if it wants to write over IDE, it can simply populate that memory region with the desired data and tell the controller to take it. Just like when reading data, the CPU is free to go off and do its own thing without needing to micromanage the transfers. It will be alerted with an interrupt as soon as the task is completed. This is why transferring data to and from devices (GPUs, NICs, storage devices using IDE or SATA, etc) can be made so fast and require so little CPU to perform.

Taking advantage of DMA to perform such optimizations and get out of the CPU's hair requires DMA actually be supported. After all, how can a device avoid bothering the CPU with every transfer if it's not given raw access to the same memory the CPU has? Normally, the device is simply trusted to only write to that memory region and nowhere else. An IOMMU, if present, can force it to use its dedicated memory region and nothing else (a process called DMA remapping, using DMAR tables hardcoded in the BIOS that specify the memory regions to use for each device). If DMA is not supported, then transfers can only happen over the much slower PIO mode.

There are two forms of PIO (Programmed I/O). They are MMIO (Memory-Mapped I/O) and PMIO (Port-Mapped I/O). They are similar in that they both require active interaction from the CPU. With MMIO, a special address range is set up that looks like memory from the CPU's perspective, but the bits have different functions when they are set, meaning it is not regular memory. With PMIO, data is loaded into a register and an instruction (such as OUT) is called. This instruction writes the data over a certain "port" number that specifies its destination. Some older technologies still use this, such as the PS/2 keyboard. However for large transfers of data, it is very inefficient. It requires the CPU load a small register of only a few tens of bits in size with data to write before issuing an instruction and waiting until the instruction finishes before it is able to do any more work. This has to repeat over and over. It is woefully inefficient, to the point where the maximum speed is only a few MiB/s and maxes out the CPU in the process. It makes the CPU the bottleneck.


Sharing a JWT between devices in close proximity of each other Setup:

iPhone (let's assume 6 and newer for the sake of this question).
Raspberry Pi 2.

The Raspberry runs a REST web service which the iPhone queries. The web service uses JSON Web Tokens for authentication and authorization. I am trying to find an as-secure-as-possible way for the iPhone to obtain a JWT from the Raspberry without too much hassle for the user -- but security is of greater importance than ease of use.

The two devices will operate in close proximity of each other, so token exchange over a physically constrained channel seems like a good solution as an attacker must be physically present prior to (e.g. leaving behind a device that can sniff and relay the information using a different channel) or during token exchange.

As the iPhone does not offer developers access to the NFC chip, this is not an option (I've also read elsewhere that it is vulnerable to MITM attacks at a range of up to 10 meters).

Bluetooth Numeric Comparison seems like a possible option as it has been proven secure (at least for v2.1).

Q1: Is this still valid? Can Bluetooth Numeric Comparison be considered secure in Bluetooth 4.x?

Having to pair devices is not ideal though as an iPhone will only interact with the Raspberry for a few days and then be replaced by a new iPhone interacting with the same Raspberry Pi. I would like to avoid having to clean up the Raspberry's list of paired devices daily.

I have been thinking of a custom solution in which I would generate a (secure) random value which would be displayed on a display connected to the Raspberry Pi. This would serve as a shortlived token that the iPhone user would manually input, and the application would send an auth request to the web service using this value. The web service would keep a timer to make sure that the shortlived token could only be exchanged for an actual JWT within a short timeframe (say 5-10 minutes) to prevent brute force attacks. We can assume that a PKI can be used to setup an SSL connection between the Raspberry Pi and the iPhone such that exchanging the short-lived token for a long-lived JWT will be performed in a secure way.

Q2: I know that designing custom security solutions is a horrible idea and should be left to security experts. However, the proposed strategy seems very simple, yet it must be flawed, and I would like to know why it is flawed.

Answer to Q2:

You are not really inventing something here as far as I can see. You are using a very simple One-Time-Code generator.

Generate the code locally on the Pi, keep it valid for a constrained amount of time (a few seconds maybe), require it to be entered into the phone and once used invalidate it immediately.

Use the Pi as a local Wi-Fi AP with appropriate security and it should be more than enough for the quick in and out you need. Even if someone gets onto the Wi-Fi, as long as the rest is secured with HTTPS and your OTP, it should be fine.

To save yourself a load of work and avoid the local invention problem, use a standard set of libraries on the Pi. Node.JS with ExpressJS and standard modules such as Passport, Helmet, Lusca or similar can handle the login and app security. A locally generated certificate should be enough for HTTPS.

This seems like a nice simple, standard and reasonably secure approach.


Do US companies have citizenship requirements for security-related employees? Do U.S. based companies or corporations generally have policies restricting their security staff to certain nationalities or are they generally open to all qualified persons regardless of citizenship?

The only situation where such a citizenship requirement would typically apply was if the SE position was with a Federal Government contractor, and the position required a USG security clearance. Since those are granted to US citizens, a non-US citizen would be ineligible for it.

That being said, in the private sector, I know of no such requirement, other than to say that if one requires a US work visa, some companies may not have the ability or desire to sponsor a candidate for one, and would not respond to the application.


Does using the same mail and web server increase a risk of DDos due to IP exposure? I use the same server for sending my emails and web hosting. I send user registration and support forum mails from my server and occasional marketing mails or newsletters.

I read on a CloudFlare blog that if I use the same server for email and web hosting the headers of the mails sent will contain my IP which will make me exposed to DDos attacks but my hosting provider says that there is no such threat with IP's in mail headers.

I am confused if it's okay to use the same server for both web and mail and does having my server's IP in the mail header really does increase the risk of DDos.

You can use CloudFlare to hide your server's real IP address. This article is saying that if you use CloudFlare and send email from your web server, it could expose your real IP. Assuming that you are not using CloudFlare or another similar service, the risk described in the article is not relevant to your situation and can be ignored.


Can I decrypt an OpenPGP message with only the passphrase, without the key? I have encrypted a file using OpenPGP Studio and lost access to the key after an operating system crash. However, the encrypted file is with me and I know the password. I would like to know if there is a way to decrypt the file without the key.

You cannot retrieve your plain text without the key. This is by design.

Unfortunately your file is gone unless you have a backup of your key stored somewhere. (Hint: secure storage of your key for circumstances such as these is a good idea)


Is a salt necessary for PBKD when the hash is used as an encryption key? I'm generating a key from a password to encrypt data with AES256. Since the generated hash is not stored, would I need to use a salt? If I use a salt and it is made public, is my encrypted data any less secure?

I don't see a need to protect against rainbow attacks since the generated hash is never saved but instead just used as an encryption key and there is no central repository for the encrypted data.

Updated answer based on new info:

Passwords/Passphrases have low entropy

Humans aren't very creative when it comes to password. This makes these passwords a poor choice as seeds to generate encryption keys (which should have a high entropy). Quoting from a study:

  Burnett did an analysis of 6 million username and password combinations last year, and found that 91 percent of users had used one of the 1,000 most common passwords—with 99.8 percent using a password from the 10,000 most common. And "password" was the leader of them all, in use by 4.7 percent of user accounts.

Dictionary (and not rainbow) attacks are what you should be worried about

Given the statistics above, its likely that you are dealing with a very miniscule subset of total possible encryption keys ( a couple thousands or millions!). A 256 bit AES key has a address space of 2^256. In such a case, you should be worrying about the dictionary attacks.

Consider a following PBKD function:

The PBKDF above uses does c iterations of a hash function H over the (password||salt) combination

Also, consider a password dictionary of 1M passwords and that our application has 100 users

Without salt

When there is no per user salt, the PBKDF function above reduces to:

All attacker needs to do is to calculate a dictionary of 1M AES keys corresponding to each password in the dictionary.

The number of times a user needs to run the KDF function = 1M.

With salt

Now that each user has a salt, a generic 1M list of AES keys will not work. An attacker will now need to do 1M KDF operations per user to create a specific set of possible AES keys for that specific user.

The number of times a user needs to run the KDF function = 100M.

PBKDFs, like bcrypt and scrypt, are deliberately slow functions just to ward off dictionary attacks like these.

Finally

It is advised to use a salt with PBKDF functions to make sure that the resultant keys have more entropy and an attacker needs to compute a dictionary per user to do a dictionary based brute force attack. Since PBKDF functions are designed to be slow, creating a per-user dictionary list is a order magnitude slower than a single list.

Old Answer

Salts will be useful in the scenario where two different users have same passwords and the same data. If a deterministic encryption is used, the resulting cipher texts will be same (since the encryption keys derived using PBKDF will be the same) thus opening up vectors for cryptanalysis. If passwords are salted, the resulting cipher text will be different in the aforementioned case.

Salts are not a secret. You don't have to encrypt/hide the salts. They should be unique for each user though.

Also if you don't have a concept of users/passphrases, then you don't need to use PBKDF to generate keys. As Lucas mentioned, you can use a secure random number generator to create random keys directly.


How to prevent corruption from ruining synced backups I thought I was being clever keeping my password database stored on dropbox. This is because it's synced to the cloud and multiple computers. But when one got corrupted, I lost everything. (Ok I exaggerate, I got it back, but if I wasn't lucky I may not have.)

How can such situations be guarded against where a) corrupted data is backed up and the old backup was disposed of or b) the backup process itself somehow corrupts the target. I guess in corporate environments that can support it, this is why they store more than just the most recent backups.

What is a practical solution for a home user to backup a frequently modified password database?

By the way, my hunch is dropbox was responsible for the corruption in the first place.

Try using a private Git repository - automate the push every night. If you want, you can even host this repo on a private server to ensure that no one else has access to it. Or save the KeePass DB to a veracrypt file and encrypt that file before pushing.


Invisible, Non-invertable, public, robust, replicated watermarking scheme? Is there a watermarking scheme for images and audio that is:

Invisible - should be imperceptible for a human.
Non-invertable - cannot be removed by any means without the original.
Robust - in order to destroy the watermark you have to spoil the image or audio perceptually.
Public - the data embedded in the image or audio can be read by anyone without requiring any information other that watermarked image or audio.
Replicated - the data is replicated all over the file such that only a small chunk of the file is needed to read the watermark with reasonable confidence.

Quick answer: not easiliy.

Your requirement #1 is in opposition to the others.

Let's look at a counter example.  #1 requires the changes to be imperceptible to humans.  That means you cannot add to, take away from, or modify the visible image.  For starters, that opens the "analog hole", where a photo of the screen masks the watermark data.

Requirement #3 says it needs to be robust.  Developing a scheme to remove or obscure a watermark today is done in two ways.  You can compare a watermarked file to an original in hopes of deriving a way to reverse every change made by the watermarking process, allowing the attacker to write a tool to "unsign" the images.

But that's not the only valid attack.  The attacker can compare two watermarked files against each other.  Remember, the attacker doesn't need to remove the watermark data to be successful.  All he has to do is introduce enough doubt that you can't prove if the file came from the image distributed to client A or the image distributed to client B.  In a courtroom, the content producer is suing client A for copyright infringement, but he can only collect from A if he can conclusively prove it came from A and not B.  (The success rate of this attack grows even further when the attacker incorporates more watermarked copies than just two.)

If I could issue visibly different media to A and B, then the info could not be removed so easily.  Let's say it's an animated video where I have a scene with a background shelf cluttered with household stuff.  I can render it with a blue teapot in video A, and a red vase in video B, and repeat this concept in as many scenes as necessary to help with #5.  (The same concept could perhaps be done with a percussion instrument in a music track.)  Any copy will uniquely identify the two, but requirement #1 says they cannot be perceptibly different.


Is it possible to sign a DVD? I work on a project where DVDs with configuration files and software updates are delivered periodically to end users, and our software loads those discs. For example, we might load a disc with an updated set of hostnames and IP addresses when the network topology is updated, or we might get a disc with virus definition updates.

Is there any way to sign those discs with GPG or similar such that they could be verified in an offline environment? The systems in question don't have Internet access. Ideally I would like to embed the GPG signature on the discs so they can be self-verifying.

When I look at how this is typically handled, folks like Debian and Ubuntu will provide a GPG signature alongside their ISO. It's not in the ISO; it's a separate detached file. That doesn't work for us since we deliver physical discs, not ISOs.

Currently we sign individual files on the DVDs. It works, but it's not ideal on a DVD with tens or hundreds of files.
My understanding is that embedded signatures only work with file formats that are designed for them, such as RPM. ISOs don't have such a mechanism. Is that correct?
I suppose we could tar up the contents of the DVDs and store a tarball and signature on the discs instead. Is that the best answer? Any better ideas?

I'm open to non-GPG-based solutions. If there's a way to embed a SHA-2 checkum, for instance, that could also work.

Normally, you'd just run a good hashing algorithm on all files, generate a list of file hashes, put that along with your files, and then just cryptographically sign that. So, procedure:

GPG

your recipients need to have a public key of yours that they can trust, pre-shared¹
cd path/to/files/to/end/up/on/CD; sha256sum --tag **/** > hashes.sha256
gpg --output hashes.sha256.sig --sign hashes.sha256
burn all these files on your DVD
the recipient:

Verifies the hashes' signature: gpg --verify hashes.sha256.sig hashes
If that succeeds, they verify the hashes themselves sha256sum --check --strict hashes.sha256

I might add that I don't like GPG (although it's very well-suited for this kind of task) due to its complex CLI and its versatility that often lead to accidental unsafe usage.

 ¹you could also let them have the public part of a keypair whose private key is used to sign your key, but building a root of trust with signing keys might be a bit over the top in flexibility here...

signify

You can do very much the same with OpenBSD's signify tool (which is available for most operating systems), which is much, much lighter, only does exactly this, and whose public keys are not any less secure, but much shorter, so that you are able to hand them over much easier e.g. in printout form.

your recipients need to have a public key of yours that they can trust, pre-shared²
cd path/to/files/to/end/up/on/CD; sha256sum --tag **/** > hashes
signify -S -s signingkey.sec -m hashes -e
burn all these files on your DVD
the recipient:

Verifies the hashes' signature, and then automatically checks all the hashes signify -C -p signingkey.pub -x hashes.sig

²Since fewer people have used signify than GPG: Create a keypair with signify -G -c "Your Name <your@email.com>" -p signingkey.pub -s signingkey.sec.


Is Segregation of Duties a Requirement? In our environment. Developers have full rights and privileges in the dev, test, and production environments. This gives them the ability to create, manipulate, and promote code associated with financial transactions. To our security department, this represents a segregation/separation of duties issue. But the developers don't agree, they say that there is nothing that requires it. Aside from putting in our company policies, is there anything we can reference?

As the O'Reilly book, DevOpsSec details in chapter 2, Separation of Duties (SoD) is a major component of the information-security standards: ISO 27001, NIST SP 800-53, COBIT, ITIL, etc -- and part of the regulatory requirements for (at the very-least): FFIEC, Sarbanes-Oxley Section 404, SSAE 16, GLBA, MiFID II, and PCI DSS.

Developers do agree that read-only environments such as Immutable Infrastructure (i.e., the "No-SSH Movement") are best-practice. You will even see developer heroes such as Martin Fowler directly prescribe the PhoenixServer concept, if not the full ImmutableServer model.

However, in an org where the Three Lines of Defense (3LoD) are instilled (e.g., financial services companies or anywhere that has an internal and/or external audit function), even read-only functionality may not be enough to meet the requirements (and pass an audit).

The DevOpsSec book makes the following recommendations beyond Immutable Infrastructure and SoD (which it also recommends):

Limit access to nonpublic data and configuration.
Review logging code carefully to ensure that logs do not contain
confidential data.
Audit and review everything that developers do in production: every
command they execute, every piece of data that they looked at.
You need detective change control in place to track any changes to
code or configuration made outside of the Continuous Delivery
pipeline.
You might also need to worry about data exfiltration: making sure
that developers can’t take data out of the system.

Another compensation control is Rotation of Duties (RoD), which often goes along with SoD. If you rotate people out every-so often and avoid situations of collusion, then this can compensate and back up the other strong controls. A final piece would be two-party integrity where a full checks-and balances system includes the ability to prevent trusted insiders via the "No Dark Corners" paradigm.

Here also are some fresh perspectives from Ben Tomhave, an industry expert on DevOps and application security -- http://www.newcontext.com/devops-and-separation-of-duties/


Can a website use my debit card details for further transaction? I bought a bracelet from Buzz Bargain(Sorry for advertisement) and it deducts 2.99 from my account and then they send me an email saying that we will deduct 49.9 USD after a month for a subscription to which I didn't subscribe.

Now they ain't replying me. So I want to ask will they deduct me that 49.9 USD without my permission? If yes, what am I supposed to do now?

I bought a bracelet from buzzbargain (Sorry for advertisement)

Not much of an advertisement given the rest of your post :)

  then they send me an email saying that we will deduct 49.9 USD after a month for a subscription to which I didn't subscribe.

They state it within their Terms, specifically 8.1 - 8.3.  Effectively, you weren't just purchasing a bracelet; you were subscribing to their site which permits you to purchase the bracelet at their low price.  And by default, it looks like you had their package b:

  (b) 12-month membership: - no initial charge; then £49.95 on the 45 th
  day after the day you purchase your subscription; and then £49.95
  every 365 days.

This is not an uncommon scam, er, "business model."

  So I want to ask will they deduct me that 49.9 USD without my permission?

Very likely, unless you cancel.  (Not completely unlikely, even if you do - so pay attention!)

  If yes, what am I supposed to do now?

Those same terms indicate the procedure for cancellation:

  8.5 Your right to cancel your subscription. You can cancel your subscription at any time by calling [1-855-984-9495] or emailing us at
  [support@buzzbargain.com]. If you contact us to cancel, we will
  terminate your subscription within [2] working days and your access to
  our VIP store will terminated. We will also discontinue any future
  charges to your payment card for any future product shipments but
  please note that you will still need to pay for any products that have
  already been shipped prior to cancellation. If a billing period has
  already started, you will be charged pro rata for the relevant period
  up to the date of cancellation.

I recommend calling and emailing them, and keeping records of both - time of call and name ("Bob") of whoever you speak to, and your email and any responses.  Make it clear that you are cancelling, that you were not aware this was a subscription, and that you will initiate a chargeback dispute if the annual fee is charged despite your attempt to cancel.

Print that email out.  Wait.  Watch your statement.

If they do charge you, take the printout to your bank and file a chargeback..  I have had to do this in your exact situation, and I got my money back.

And if your cancellation email/phone is calm and clear, it's likely the merchant won't even try - they lose money on chargebacks, and it's not worth their time to charge someone where they know they'll likely be contested and lose.

I don't know of a way to block a transaction before it happens - and I asked last year, when someone managed to start charging their Netflix to my card.  The bank said all they could do was chargeback the charges once they cleared.  Netflix was able to chargeback them from their end, which saved me the paperwork.


Is it dangerous to use the same key (RSA) for both encryption (PGP) and authentication (SSH)? Alice wants to send an encrypted message to Bob, but she also wants to connect to Carol's server. Are there any dangers associated with using the same RSA key for both PGP and SSH (other than a lack of anonymity)?

In a PGP setup, encryption occurs with the recipient's public key. In SSH authentication, this is (internally) a signature with the client's private key. If Alice sends a message to Bob and also connects to Carol's server, then Alice will use Bob's public key to encrypt, and here own private key (from a distinct key pair) to sign. No problem here.

A trickier case is when Bob wants to both receive encrypted messages from Alice, and connect to Carol's SSH server. In that case, Bob uses his private key to decrypt incoming messages (from Alice), and also to sign things sent by Carol (the authentication challenge within the SSH handshake). Using the same private key for two distinct algorithms is, generally speaking, a bad idea, because possible interactions between the two usages are a poorly explored area. Also, normally want to keep a backup of any encryption key, and not keep a backup of any authentication/signature key (see this), so making the two keys the same means that you are doing things suboptimally.

For that matter, a normal PGP setup already entails having several key pairs (a "master key" that can revoke the sub-keys, and sub-keys for encryption and signatures). Having an extra one for SSH should be no hardship.

(Not counting the fact that PGP implementations like GnuPG, and SSH implementations like OpenSSH, have distinct formats for encoding keys, so using the same key for both would need some effort.)


Can someone explain how sshd does privilege separation? I'm confused about how sshd drops privs for incoming connections. I found this page which was very informative on a high level:

http://www.citi.umich.edu/u/provos/ssh/privsep.html

But I don't understand how the child of privileged sshd is unprivileged.

In my debug below privileged sshd is 28389 and calls clone() to create 29266, the unprivileged child. When I use ps to display the UID/EUID of the pids 29268 is UID 1002 as expected, but 29266, the unprivileged child of sshd, is zero, which seems to contradict the link above which says 'This is achieved by changing its uid/gid to an unused user'.

woOt@host:~$ sudo strace -p 28389 -e trace=clone
Process 28389 attached - interrupt to quit
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb7076d5a90) = 29266
^CProcess 28389 detached
woOt@host:~$
woOt@host:~$
woOt@host:~$ ps auxf | grep sshd
root     28389  0.0  0.0  49944  1244 ?        Ss   18:15   0:00 /usr/sbin/sshd
root     29266  0.0  0.2  54576  3308 ?        Ss   18:37   0:00  \_ sshd: test [priv]
test     29268  0.0  0.0  54576  1440 ?        S    18:37   0:00      \_ sshd: test@pts/2
woOt@host:~$
woOt@host:~$
woOt@host:~$ ps -eo pid,uid,euid | egrep 'PID|28389|29266|29268'
  PID   UID  EUID
28389     0     0
29266     0     0
29268  1002  1002
woOt@host:~$
woOt@host:~$
woOt@host:~$ grep 1002 /etc/passwd
test:x:1002:1003:,,,:/home/test:/bin/bash
woOt@host:~$

edited question to correctly illustrate:

unprivileged child (2406) of monitor process (2405)

root      2370  0.0  1.1  55592  5524 ?        Ss   00:12   0:00 /usr/sbin/sshd -D
root      2405  0.0  1.1  59008  5720 ?        Ss   00:12   0:00  \_ sshd: test [priv]
sshd      2406  0.0  0.6  56936  3072 ?        S    00:12   0:00      \_ sshd: test [net]

and user privileged child (2419) of monitor process post-auth:

root      2370  0.0  1.1  55592  5524 ?        Ss   00:12   0:00 /usr/sbin/sshd -D
root      2405  0.0  1.1  60224  5756 ?        Ss   00:12   0:00  \_ sshd: test [priv]
test      2419  0.0  0.7  60224  3888 ?        S    00:12   0:00      \_ sshd: test@pts/1

appreciate the answers, thanks

29266, the unprivileged child

This one is the privileged one, as the process title shows sshd: test [priv], the 29268 is unprivileged postauth child (user is already test instead of root).

But the main place where you can use privsep is before authentication:

root     11759  0.0  0.0  69928  6056 ?        Ss   Feb07   0:00 /usr/sbin/sshd -D
root     10071  0.2  0.0 119280  7096 ?        Ss   10:56   0:00  \_ sshd: unknown [priv]
sshd     10072  0.2  0.0  71272  3016 ?        S    10:56   0:00      \_ sshd: unknown [net]

There you see the privileged process running under root privileges (10071) and net-child (sshd: user [net], running under sshd user, and usually under some sandbox which prevents most of the privilege escalation attacks, it there was a hole in the code.

So as already mentioned by tylerl, or you setuid is used to drop/change privileges from root to sshd or your user. But note that you need to point out to the correct process when trying to understand this constellation. Image is usually more than thousands words:

Where in the image corresponding to your example:

the first privileged is sshd daemon (your pid 28389)
the second one privileged is monitor (your pid 29266)
you don't have in your ps unprivileged network child (mind pid 10072)
the user privileged is child (your pid 29268)


How much information/access could the owner of the router and Internet connection have (using his Wi-Fi with his permission)—and how to stop it? I just moved to a new apartment/room and I'm using my roommate's brother's Wi-Fi connection (almost 3 times faster and 3 times cheaper than if I would get my own Internet). He has access to the router.

How much information could the owner of a connection/router—if moderately knowledgable—access (i.e., check in the settings or actually hack) regarding...

Online banking?
Websites visited?
Email?
Passwords?

Can an owner of a connection/router—again, if moderately knowledgable—hack your computer and get access to your files?
If not, what would be the level of difficulty, when owning the router, be to get access to the above mentioned information/files?
What protection would make sure that everything mentioned above—banking info, websites visited, passwords and files—would almost be 100% unaccessible (when using someone elses Intenet connection, with his permission, and he has access to the router)?

Let's assume your roommate's brother has the intent to spy on you and he has some basic computer and networking knowledge...

By performing a man-in-the-middle attack with the right tools he could easily see which websites you've visited by capturing your DNS queries. He could also capture other sensitive information. For example, if you visited insecure websites over HTTP or if you choose to ignore the following warning during a website spoofing attack:

It is also worth mentioning that these types of attacks don't require direct access to the router.  Anyone on the LAN could perform this attack.

Since you do not trust the users of this wireless network, treat it as if you are using public WIFI and use a VPN.


Is using RC4-MD5/RC4-SHA as SSL ciphers enough for most purpose? In the AWS ELB, I have uploaded a cert and only selected "RC4-MD5" + "RC4-SHA" as the ciphers and scored A in the ssltest [1]

If I using the default ELB setting, I can only score a C

Since I am not doing a PCI compliant site, so by using only the above two ciphers, is it enough for most purpose? (by enough I mean wide range of browser support)

[1] https://www.ssllabs.com/ssltest/

Short answer: yes, things will be fine.

RC4, MD5 and, in some minor measure, SHA-1 all have some known shortcomings, but none of them will make your Web site weak. To be accurate: if using a RC4-MD5 cipher suite makes your Web site significantly weaker, then it is otherwise extremely solid -- more solid than seems to be practically reachable, indeed.

However, you might want to throw in a few more cipher suite, e.g. with support for 3DES and/or AES, so as to accommodate restricted clients. Some people got the messages wrong, panicked, and deactivated RC4 altogether from their browsers.

The "score" in ssltest is nigh meaningless. Don't read too much in it. It is like reputation in security.SE: it more relates to the efforts invested in obtaining a high score than to real security.


Is it safe to receive (One Time Password) OTP to the Mobile where the online banking application is installed? Assume a customer of a bank is using online banking facility and he is using an online banking application on mobile (android).

There could be a possibility that particular mobile could be compromised and the purpose of having dual factor authentication could be void. The attacker could initiate online transaction through installed online application and he will receive the OTP to same mobile.

Is it safe to receive OTP to the same mobile where the online application is being used? Or any other alternate way of ensuring purpose of dual factor authentication?

Sensitive services' OTP to a mobile is not a good idea. Banks should use hardware OTP or other else.
The typical attack vector for OTPs are three types.
Gaining control of the phone
Well. Literally.
Mobiles, though not so often these days, are easily compromised. Especially, Android applications can freely access the SMS messages(of course with permission).
Exploiting the SMS spam block feature
Most carriers now support automatic spam block, which blocks spam before entering user's phone. Users can log in to the spam control system, set spam numbers, and view spam SMSes.
The attacker uses credientials from breached data, sets the target(ex. bank)'s number as a spam number, and successfully gain OTP data from the spam control system.
SIM Swap/Copy

One particular vulnerability that has gained popularity with hackers is SIM card fraud. This is basically an attack that essentially dupes your telco into swapping your line of communication to a different SIM card that the hackers have in their possession.
This allows a culprit to take over your phone line. Every time you call your GSM provider with any sensitive request, they’ll ask you for some personal data that helps them identify you as the true owner of the line. This is where hackers come in. Armed with personal information on you, a fraudster has the ability to request a SIM change.
Source: https://www.standardmedia.co.ke/business/article/2001296918/sim-card-fraud-why-it-hurts-when-it-hits


How can I tell if a DNSSec zone is protected using NSEC3 (versus NSEC) This answer describes how DNSSec might permit "Zone walking"... where a bad guy can extract all the DNS records from a DNSSec enabled zone.  NSEC3 is an update that prevents this. (See bottom of this article)

How can I determine (externally) if a zone is using NSEC or NSEC3?

If you're willing to rely on an online service (and don't mind one that is pretty picky), the DNSSEC Checker will warn (among other things) about zones that don't use NSEC3.

To check by yourself, simply query a non-existent domain and look for either an NSEC or NSEC3 resource record in response.  An example query would be dig +dnssec -t any xyzzy14.sdsmt.edu (for a zone using NSEC3) or the same query at xyzzy14.berkeley.edu to see NSEC records.

Also, note that NSEC3 does not fully protect DNS zones from being enumerated.  Indeed no DNS server has ever been immune to that, since attackers can always do a dictionary attack by just querying for names they think might be there.  Use of NSEC3 allows an attacker to speed up the dictionary attack and do it more privately offline.  They retrieve all or most of the NSEC3 records by querying for non-existent domains, and thus get the hashes of all the hosts in the zone.  They then do an offline brute-force attack on the hashes.  Tools even exist to do that, e.g. nsec3walker. But NSEC3 is still much harder to enumerate than NSEC, and you can set the iteration count for the hash to a high value if you want to make it more expensive.


If a digital camera can be "hacked" in the ransomware sense, how best to protect it? Increasingly, I hear of hackers gaining control over digital devices for their own gain or merely to be a nuisance.

I don't know but suspect that when tethered to another device such as a computer, malware can be unknowingly passed. Blue Tooth might also be a conduit to the camera logic. Maybe something is hiding in the "cloud" to be downloaded? Either way, I've decided to repatriate anything in the cloud to something back here on Earth.

Has anyone knowledge or experience if this is a distinct possibility? I'd be interested.

UPDATE: My brother sent me this link to checkpoint software pwning a camera over wifi in less that a few seconds.

Tags suggestions appreciated.

From the OP's link… or more precisely from the security report the tweet is linked to - Check Point Research Reveals Modern Cameras’ Connectivity to Wi-Fi Make Them Vulnerable to Ransomware and Malware

  Here are some things camera owners can do to avoid being infected:

  Make sure your camera is using the latest firmware version, and install a patch if available.
  Turn off the camera’s WiFi when not in use.
  When using WiFi, prefer using the camera as the WiFi access point, rather than connecting your camera to a public WiFi network.

That third point is the one - if your camera is the access point, then before you can even start to try to hack it you first need to hack into the access point. WPA2 is not impossible, but certainly not easy to hack. Once past that you would need to try to side-load the specific hack for that specific model of camera.

All the time you were doing this you'd have to be within 15m of the photographer.

Defcon does this kind of thing every year - it exposes weaknesses to make manufacturers change their practices, long-term. The thing is that you get good brownie points for finding a new exploit. It doesn't have to be one that's easy or even likely, it just has to be possible.
Cue crowds of cheering pen-testers.

As with all good white hat hackers, CheckPoint first told Canon about the exploit they had found & didn't make it public until after it had been patched.
Canon - Regarding the security advisory for Canon digital cameras related to PTP (Picture Transfer Protocol) communication functions and firmware update functions


Password reset system code system vs long hash I'm building a password reset system at the moment and I've come across a dilema.

Currently we have a system which creates a long md5 has (16 characters) and emails a link to a customer which they then click on and can reset their password.

However now we want to step away from putting links into email and make customers aware of this to counter phising attacks.

My solution is to create a 5-6 digit pin number and send that in text to a customer via email.

However this feels as though we are increasing security by moving away from links in email but decreasing security by making a security token easier to guess.

Does anyone have any recomendations or views on this?

The token is just to verify that you received the email, that you own the account.

Password reset links in emails are a convenience that provide proof that you own the email account and allow you easy access to the password reset workflow.

These tokens don't have to live anywhere for long term and you can invalidate them after some missed attempts if you feel like it. So you don't need huge entropy the same way MFA tokens don't.


Can a Firefox add-on or plug-in access the user's websites' saved passwords in decrypted mode? Going deeper into the previous question on Firefox plugins and add-ons malware risks: Could a Firefox add-on potentially decode and capture the encrypted websites' passwords saved in the browser?

In Firefox: Yes, absolutely.  Nothing about the Firefox architecture prevents them from doing so.

While the passwords are in theory "encrypted" while stored on disk, the decryption key is also stored on disk.  Therefore, any software with access to the filesystem will find it trivial to decrypt the stored passwords and access them.  (If you don't want to take my word on it, here is one simple way to convince yourself that this is possible: The Firefox browser can decrypt them without prompting you for any secrets.)

In Firefox, plug-ins can run native code, so they can access the filesystem.  Therefore, they can grab and decrypt all your stored passwords.  They can also exfiltrate them out over the network, if they choose.

In Firefox, extensions can run arbitrary shell commands and access the filesystem, so they too can grab and decrypt all your stored passwords, and exfiltrate them over the network.

There is a light review process for populara Firefox extensions, which might make it harder for unsophisticated extensions to mount such an attack.  However, this review process can be easily subverted by malware: extensions can dynamically load code from external sources (e.g., via <SCRIPT SRC=...> or eval), and the attacker can arrange for that externally-loaded code to be benign during review and malicious during execution.

Therefore, there is nothing that really prevents a malicious Firefox plug-in or Firefox extension from mounting such an attack.

(Interestingly, Chrome's extension system has better protection against this kind of attack, for extensions.)


In GoldenEye, what does 'strikes deferred' refer to? Using GoldenEye to launch a DOS attack on a web server, the terminal output reads:

12928 GoldenEye strikes deferred. (0 Failed)

What does 'strikes deferred' refer to?

According to the developer's repo:

  "Strikes Deferred" variable saying what number of strikes was blocked
  or crashed. In brackets says what number of connection timed out was
  responded (or responded error 500).

You would have to read the code carefully to work this out and it is not obvious or in any of the documentation.


Best practice for authenticating resend email requests I have a Node.js/Express 4/JWT user authentication service using Passport.js, with Sequelize and MySQL for database.
In my service, upon signing up/resetting a password, the user will be redirected to a page telling them to

click the link in the email that was just sent, or
click a button to resend the email (if they did not get it)

In the database I have a dynamic_urls table for activate/reset links.  The dynamic_urls table has a cap of 5 resend attempts before they are directed to contact the admin (obv. incremented with every resend).  The URL itself is generated via JWT, with a payload of the user's id, password hashed password, with their account creation date, and a private key of a long "secret" string.  It is then stored in the database until it is clicked or expires.
I have a few questions for best info sec practices with JWT, namely:

Should I even care about having the resend button have a random URL?
I assume that I must, because the resend request has to correspond to the correct dynamic URL, which requires user information, which must not be leaked.

And if so:

What should I use for in the payload when creating the dynamic URL of the resend button?
I assume I shouldn't use the same/similar payload that I used to make the email link.  UUID maybe? (but then I'd have to presumably stash the UUID in the database as well, no?)
Should I renew the resend URL with each resend attempt.
(E.g. each resend lands user on new page with new unique resend link)

Thank you in advance!
EDIT:
Passwords are hashed with bcrypt; for new users that hashed password is immediately used to make a temporary URL from a JWT, a la
jwt.sign( { data: newUser.id }, newUser.login_pass + "-" + newUser.account_created)
which gives something like
http://domain.com/activate/eyJkYXRhIjoxMDI1LCJpYXQiOjE1ODU5MzAwNTd9.Y2BYzfc0oETn9kbzQ_ek_0FYTV8WDPoRBT4jmAQeQ68

First of all I have an important question why do you have the user's password. A password should be hashed and never encrypted or in plain text you should't know the password. (Argon 2, SCrypt, Bcrypt PKDF2 are all excellent "password Hashing" functions). Secondly what JWT algorithm do you use?  By default JTW payload is NOT encrypted whatever you put inside there can be seen by any one having the JWT(remember emails are not the most secure). Personally I wouldn't recommend  putting the password or the password hash in there. In fact a lot of data are not needed. Just the userId and a expiration date of the JWT seems more than enough for me. Remember what you want to achieve. By presenting the JWT to the server you can be certain the user has access to the email account, job achieved.  As for storing urls in the database I'm a little confused isn't the hole idea of JWT that you don't need to bother the database? Can't you simply get the userID is from the JWT and check if the expiration date is still valid? Then allow the password reset? (remember payload data can be trusted the server singed them)

To answer  the first question isn't the JTW random enough and also unique at the same time? If you want to make it even more random ad an extra field time JTW was created.
Why bother creating new dynamic urls? re sending the same JWT isn't good enough? Having   different JWT valid at the same doesn't seem as a good solution it adds unnecessary complexity.

The bellow url is an example of what you should go for in my opinion.
https://your_site.co/account/reset-password?token=jwt.goes.here


Are browser wrappers in software bad for users? These days I see a lot of browser wrappers in software. For example:

when you purchase something in the Steam desktop application and use PayPal, you enter your PayPal security details in a browser frame provided by Steam.

when you log in on the Figma Desktop App with Google, you enter your Google credentials in a browser provided by the Figma Desktop App

Like trusting my browser, I trust these applications to not mess with the website or frame in any way. For example injecting javascript, showing a phishing page, showing HTTPS when there's no secure connection.

What I'm worried about is users getting used to this kind of presentation. They're exposure to these kinds of browser wrappers might give them the idea that it's OK to trust these kinds of wrappers and freely enter any kind of information there. Not knowing that hijacked or malicious applications could trick users into giving up their details.

Question: am I missing something here or is this a trend that needs to be put to halt? (and instead just serve webpages in the users' preferred web browser)

Web wrappers within an app has become quite common among applications and is not going to change anytime soon. The following measures will be helpful for securing the account used here

Login without password - For example, Google allows you to login using your phone, Microsoft allows you to authenticate from it's authenticator app. This will prevent anyone tracking your password.
Use Two Factor Authentication - Even if the entered password is compromised your account will be safe.
Don't reuse password of this account anywhere else.
Change password frequently (at-least once in six months).

  is this a trend that needs to be put to halt?

While the wrapper popup brings in some nice user experience, there are quite some alarming things such as hiding the location bar. Developers really need to stop hiding URL in authentication prompts. How am I supposed to know that I am on the right site.

Response to comments

  but that isn't any different from any web browser.

You cannot hide the URL bar in modern browser popups.[1]

References

StackOverflow - Hiding address bar in browser


Intel AMT vulnerability - How is it a local threat? INTEL-SA-00075 describes a vulnerability in the Intel AMT/ISM/SBT firmware. From Intels own bulletin this is a threat both locally and remotely.

How is a threat in the local scenario? I understand the threat at the network level, but Intel states, this vulnerability remains a threat at the local level.

From their bulletin:

  An unprivileged local attacker could provision manageability features
  gaining unprivileged network or local system privileges on Intel
  manageability SKUs

I don't understand how this presents a threat. If the service is not provisioned, then there is no threat, and in order to provision the service, a user needs administrative privileges (or needs to have physical access). If a user has admin privileges already then exploiting this buys them nothing (and physical access implies root privileges anyways, ala usb attacks among others). Am I missing something?

As @polynomial explained above: "If the [LMS] service isn't running, it can't be exploited."

However, in terms of a local environment, it would be more accurate to state: "As long as the service is not running on the target computer or any computer with permissions to manage that computer" then the is no exploit to be had.

For example, if the DC has LMS running, but the CEO's computer did not, the DC could be compromised, and group policy could be used to install LMS on the CEO's computer, and then AMT could be accessed.


Quick Security Mitigations to Impending attacks Suppose you are the sysadmin, and you know of an impending attack that just started or about to start soon. You can either wait it out, or try a few tricks and quick mitigation to fend off attackers and try to reduce the attack vector or damage that could be done.

This is definitely not the right way to securing an environment, but when you have attackers at the gate, it's not the time to argue with staff, but to focus on just fending off all the goblins down the gates, with whatever technical or psychological trick you can come up with.

What kind of mitigation steps can I do in such case?
Can I quickly Install and configure ModSecurity quickly to protect (to an
extent) the web apps?
What Hardening IIS/Apache quick configurations can I apply?
Any web filtering libraries (like antiXSS) that I can install quickly?

Bit of a wide open question really as steps should be taken at multiple levels to increase the security posture of your environment. This can include hardening operating systems, secure network design, strict firewall rulesets, hardened databases, software developed with a good SDLC and security in mind throughout, etc etc.

That said if you know of an attack or one has just started the simplest way would be to block traffic from the source IP address and look to fixing the actually vulnerability as soon as possible.


How to do forensis MBR hex dump? I take OS first 512 hexdump using dd command. what kind of information extract using that and what are the tools or command(linux) can be used for analysis ?

I take copy bytes dump using my Ubuntu os(MBR sector) following command.

dc3dd if=/dev/sda of=x cnt=1 ssz=512 hash=sha256 mlog=hashes

And I convert it to hexdump using following command.

hexdump x > hex_x

Here is a nice visual explanation of the MBR : http://www.nixhacker.com/explaining-the-magic-of-mbr-and-its/.

Except you have to be aware of the LSB or MSB output of the tool. hexdump -C or xxd's output may be easier to read depending on what you're used to, your hexdump output shows the proper byte arrangement as it actually appears in memory with the least significant byte first.

See : hexdump always uses the platforms endianess

The nixhacker link above will be the most useful with xxd's output (or hexdump -C), we have to manually flip the bytes of your output to make sense of it.

1be : 00 00 : 08 would be bootable, 00 is not bootable, 00 Is the Starting Head

1c0 : 01 00 : 01 Starting Cylinder, '00 Starting Sector'

1c2 :  ee feffff : ee Partition Type - EFI GPT Disk (https://en.wikipedia.org/wiki/Partition_type), feffff - ending Head Cylinder Sector values

1c8 : 00 00 10 00 : LBA address of the starting sector (4096)

And so on.

From a quick search you can find MBR parsers that seem to work well:

https://raw.githubusercontent.com/gleeda/misc-scripts/master/misc_python/mbr_parser.py


How secure is OPAL 2.0? I basically cannot find any credible information online as to how secure OPAL 2.0 drives are, and so I don't really know how much, or in what cases, I can trust their encryption to keep my data safe if the drives get into the wrong hands.

Do they do proper encryption? Do they store the keys securely? Have they been cracked before? Do they have backdoors? Are these known to differ across vendors? etc.

The specs themselves are fine, but there is always the issue that the vendors will not implement it correctly, which is unfortunately not uncommon. There are also security issues that are not even addressed, for example the kind pointed out in Hardware-based Full Disk Encryption (In)Security. From the abstract:

  We show that, depending on the specific hardware configuration of the system, (1) for most settings in which a known attack on software-based FDE exists, there exists a successful attack against SEDs. These scenarios include DMA-based attacks, cold boot attacks, and evil maid attacks. In this sense, hardware-based full disk encryption (FDE) is as insecure as software-based FDE. We also show that (2) there exists a new class of attacks that is specific to hardware-based FDE. Roughly speaking, the idea of these attacks is to move an SED from one machine to another without cutting power, i.e., by replugging the data cable only.

  Do they have backdoors?

How can anyone even answer that? No, the specification does not require the insertion of backdoors. Whether or not a given vendor inserts one requires careful analysis of the individual firmware. More likely, they are just full of bugs, and no backdoor is needed to exploit a weakness.


A query about SSL pinning So I have been reading about SSL pinning in context of a requirement where we have to interact with a web service operated by a partner of ours. We have an Android App and we would be making network calls to their service in a WebView(embedded web browser) and while SSL pinning has been labeled as the solution to verify identity really, I am still not clear on the fundamentals.

Say, I am interacting with Google. Firefox shows me their certificate details. If I were to be able to try out a MITM for a request to Google, can't I just copy Google's certificate(which seems to be a public information) and provide that as my certificate?

I don't see pinning help any identity cause. What have I left out of the story?

Say, I am interacting with Google. Firefox shows me their certificate details. If I were to be able to try out a MITM for a request to Google, can't I just copy Google's certificate(which seems to be a public information) and provide that as my certificate?

You can copy the certificate all you want, but you can't copy the private key that corresponds to the certificate. The private key is the (only) secret of the system, and closely guarded by the webserver.

The basic TLS handshake means that the server sends it's certificate, and proves it by using the corresponding private key to sign a nonce:

  Server's digital signature: The server uses its private key to encrypt the client random, the server random, and its DH parameter*. This encrypted data functions as the server's digital signature, establishing that the server has the private key that matches with the public key from the SSL certificate.

Thus, when a client uses the certificate (the public key) to encrypt something, you have no way of decrypting it, and the TLS handshake will fail. This handshake normally happens before any data is exchanged.

You should probably read up on public key infrastructure which describes how the model works.

This is also why Heartbleed was a huge thing; it allowed extraction of the private keys from webservers.


Checking client hello for https classification I need to detect https packets in network traffic . Until now I were marking all "443" as https but I don't want to use port information for these any more .

Will it be enough to check client hello message like :

//Check 22 and version info 0300 0301 or 0302
if (packet->payload[0] == 0x16 && packet->payload[1] == 0x03
  && (packet->payload[2] == 0x00 || packet->payload[2] == 0x01 || packet->payload[2] == 0x02)

{
    int temp = ntohs(get_u16(packet->payload, 3)) + 5;//Get lenght
//Check lenght is valid and 6th byte is client hello(which is 1)
    if (temp < packet->payload_length && temp > 50 && packet->payload[5]) == 1)
        MARK AS HTTPS
}

Because of my project design, I can't check more than one packet . Can you please advise if just checking client hello like above is ok or not ?

In SSL/TLS, messages are sent as part of records. What should be expected is that the client first send a ClientHello message which itself is contained in one or several records.

Record format is:

record type: 1 byte (0x16 for "records contains some handshake message data")
protocol version: 2 bytes (0x03 0x00 for SSL 3.0, 0x03 0x01 for TLS 1.0, and so on)
record length: 2 bytes (big endian)
then the record data...

For the first record (from client to server), the client will first send a ClientHello message which is a type of handshake message, hence encapsulated in a record as shown above (the first byte of the record will be 0x16). Theoretically, the client may send the ClientHello split into several records, and it may begin with one or several empty records, but this is not very probable. The ClientHello message itself begins with its own four-byte header, with one byte for the message type (0x01 for ClientHello), then the message length over three bytes (there again, big-endian).

Once the client has sent its ClientHello, then it expects a response from the server, so the ClientHello will be alone in its record.

So you could expect a payload which begins with the following 9 bytes:

0x16 0x03 X Y Z 0x01 A B C

with:

X will be 0, 1, 2, 3... or more, depending on the protocol version used by the client for this first message. Currently, defined SSL/TLS versions are SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. Other versions may be defined in the future. They will probably use the 3.X numbering scheme, so you can expect the second header byte to remain a 0x03, but you should not arbitrarily limit the third byte.
Y Z is the encoding of the record length; A B C is the encoding of the ClientHello message length. Since the ClientHello message begins with a 4-byte header (not including in its length) and is supposed to be alone in its record, you should have: A = 0 and 256*X+Y = 256*B+C+4.

If you see 9 such bytes, which verify these conditions, then chances are that this is a ClientHello from a SSL client.

Some non-very-recent SSL client may also support an older protocol version, called SSL 2.0. These clients will emit a ClientHello which follows the SSL 2.0 rules, where messages and records are somehow merged. That SSL 2.0 ClientHello message will state that the client also knows SSL 3.0 or more recent, but it won't begin with the 9-byte sequence explained above.

SSL 2.0 ClientHello structure is explained in appendix E.2 or RFC 5246. Although such clients are rarefying (there is a RFC about prohibiting SSL 2.0 support altogether), there are still many deployed out there.

Your code has a few problems:

It does not detect a SSL 2.0 ClientHello message.
It checks that the third header byte (X in my description above) is equal to 0, 1 or 2, which rules out TLS 1.2. This is too restrictive.
It assumes that the whole ClientHello will be in a single record (which is a reasonable assumption) and that this ClientHello will be encoded in a single packet (which is a much less reasonable assumption).
It does not try to look at the length in the handshake message and corroborate it with the record length.

Correspondingly, evading detection will be easy (by using a SSL 2.0 ClientHello, by using a record tagged with TLS 1.2 version, by making a big ClientHello message which does not fit in a single packet... the method are numerous); and some existing deployed clients will not be detected: not only one can avoid detection on purpose, but it is also possible unwillingly.


ssh-keygen won't print '=' symbol in sha256 of pubkey, but python will When I run

ssh-keygen -lf my_key.pub

I get a fingerprint of the type:

something

When I do it to the same base64 encoded public key, but in python, with the code

    def to_sha_256(b64pubkey):
        sha256 = hashlib.sha256()
        sha256.update(base64.b64decode(b64pubkey))
        hash_sha256 = sha256.digest()
        return hash_sha256
    def to_base_64(plaintext):
        return str(base64.b64encode(plaintext), 'utf-8')

    fingerprint = to_base_64(to_sha_256(b64pubkey))

I get

something=

What is that = in the end and which one is correct?

base64 uses equal signs for padding if the number of encoded bytes is not a multiple of 3.
However, the padding is not always  mandatory and its use varies between implementations:

  In theory, the padding character is not needed for decoding, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations, the padding character is mandatory, while for others it is not used.

(Source)

For example, since this string has only 7 bytes, == is appended to pad the value to a multiple of 3:

$ echo -n "1234567" | base64
MTIzNDU2Nw==

So both variants are correct. If in doubt, use the padded one.


Is it possible to do research in both Computer Architecture and Security I just finished with my MSc in Computer Science and Engineering (Security study-line) with a thesis on cache timing attacks on virtualized environments. I also have an MEng in Electronic and Electrical Engineering. I am interested in both Computer Architecture and Security from a hardware perspective.

I am now considering taking an academic path, probably starting with some research assistance and then doing a PhD. Is there a point where these research fields meet? What topics represent a good mesh between the two fields?

Are there companies that are combining these fields?

I think the most interesting work, academically, is at Cambridge (check https://www.cl.cam.ac.uk/research/security/capsicum/documentation.html)

ARM is doing research into this, as is Intel and Apple, but there are fewer citations to start digging into.


Definition of Software Security I'm looking for a theoretical definition of Software Security. And I need to quote some book in an article.
Most of the books starts already assuming that the user knows what that is, and they're probably right.

My question is the most accepted definition of software security.

The definition by Gary McGraw:

  Software security is the idea of engineering software so that it continues to function correctly under malicious attack


XKCD #936: Short complex password, or long dictionary passphrase? How accurate is this XKCD comic from August 10, 2011?

I've always been an advocate of long rather than complex passwords, but most security people (at least the ones that I've talked to) are against me on that one. However, XKCD's analysis seems spot on to me.

Am I missing something or is this armchair analysis sound?

I think the most important part of this comic, even if it were to get the math wrong (which it didn't), is visually emphasizing that there are two equally important aspects to selecting a strong password (or actually, a password policy, in general):

Difficulty to guess
Difficulty to remember

Or, in other words:

The computer aspect
The human aspect

All too often, when discussing complex passwords, strong policies, expiration, etc (and, to generalize - all security), we tend to focus overly much on the computer aspects, and skip over the human aspects.
Especially when it comes to passwords, (and double especially for average users), the human aspect should often be the overriding concern.
For example, how often does strict password complexity policy enforced by IT (such as the one shown in the XKCD), result in the user writing down his password, and taping it to his screen? That is a direct result of focusing too much on the computer aspect, at the expense of the human aspect.
And I think that is the core message from the sage of XKCD - yes, Easy to Guess is bad, but Hard to Remember is equally so.
And that principle is a correct one. We should remember this more often, AKA AviD's Rule of Usability:

Security at the expense of usability comes at the expense of security.


Non-software individual password management solutions I am interested in knowing if/what 'solutions' exist for password management in cases where people do not want to use a password manager (for whatever reasons they may offer...)

Let's assume:

The person can remember one complete password.
The person cannot write/store any actual password (of course!) - though 'triggers' can be written and stored.
The person needs to remember 10-100 passwords (picked this range because it covers most cases).

Our goal is to ensure security while maximising convenience for the user.

To give an example, one might suggest having a "master password" (easy to remember, hard to crack, xkcd's post being a good starting point) and then a caesar cipher stored in multiple locations (online drive, phone note, piece of paper at home) for each login.

This is fine, but isn't fantastic for at least four reasons:

The task of rotating is not particularly natural/simple for humans. With practice/frequency some would be easy for but non-everyday logins it would likely be cumbersome.
The passwords are intrinsically linked so if one of the passwords is cracked the others only take 36 (assume we don't want to demand the user rotates more than lowercase letters[26] and numbers[10]) guesses at most to crack (this also assumes that the hacker can recognise that the passwords are constructed using a cipher technique which is unlikely so this isn't a huge problem, but also not totally unreasonable).
Passwords become non-unique from 37th password onwards.
Our cipher key information has a nasty trade-off. We have to store it multiple locations because losing it implies incredible inconvenience, but the more places we store the more chance there is of it being discovered (not critical because the master password is still needed to make it useful, but still a negative characteristic).

Does anyone know of any better/standard alternatives?

P.S. When I say 'non-software' I mean specifically password manager - you could of course write information in a text editor or use some programming language to rotate your master password, etc. if that forms part of your method.

Knowing and memorizing a credential pair for computer access is just a fact of life.

Same thing applies to the "real world". Imagine if all the owners of a Honda vehicle could just put their keys in any Honda and drive off. Wouldn't be a very good system would it?

Things you may want to look at:

Something you have, a Smart Card/Token
Something you are, biometics
Somewhere you are, an assigned work station behind a keyed/locked door
Single Sign On (SSO), seen with larger corporations or universities

Unless you intend to access public websites, smart cards are a perfect solution for an intranet.

This requires users to remember a PIN, but could store a single certificate or many for various logins. A numeric PIN is much easier to remember, and certificates are much stronger than a simple password.

Sharing credentials is uncommon, but seen in some corporations with temporary workers, sharing a crediential pair for use on a single system is acceptable. The reason for this is because they work on alternate work days, you can track who was in that day, and only 2 users are aware of the credentials. This is done on a system-by-system basis to simplify management.

As for writing passwords down and such, this is perfectly acceptable if you are unconcerned about a local attacker. Many are probably aware of their elderly family member(s) doing this. The concern is minimal because it's much more likely someone to attack their accounts from the web than locally in person.

Doing this in a corporation/enterprise however, under PCI compliance or HIPAA is likely to land you in some legal troubles or voided agreements at the minimum.

The other issue arises is that writing down credentials changes the game. Authentication, having a user prove their identity, no longer exists as anyone could walk up and enter the credentials. By having a written credentials turns things into authorization, proving a right to a resource.

Single Sign On allows the user to enter their credentials once, and access many other resources by sharing a secure token to said resources. This is not common in smaller enterprises due the shear work involved in setup/maintenance.


Are FIDO U2F keys (like dual Yubikeys or dual Google Titan keys) undermined by the Google account recovery process? According to the Google information page here: https://support.google.com/accounts/answer/6103523

If you don’t have another second step or forgot your password
Note:
2-Step Verification requires an extra step to prove you own an
account. Because of this added security, it can take up to 3-5
business days for Google to make sure it’s you trying to sign in.
Follow the steps to recover your account. You'll be asked some
questions to confirm it's your account. Use these tips to answer as
best you can.
You may be asked: To enter an email address or phone
number where you can be reached. To enter a code sent to your email
address or phone number. This code helps make sure you can access that
email address or phone number.

This seems to indicate that even if I have two Google Titan keys (two are required for Google's Advanced Protection Program), someone can just fill in a form to claim that the keys are lost, and then gain access if they can intercept access to texts sent to my mobile phone number. This seems to indicate that the attacker can just wait until they think I'm on vacation and not paying attention, and then gain access to my account?
Is there any way to lock the account down so that my cell provider is not the weakest link?

After all Google decides to recover your account or not. So from a logical stand point you can not lock down the account, because you do not have the ultimate control over the account.

You can answer a lot of security questions and hope that google or the google helpdesk will ask all questions and decide wisely. But after all it is not in your hands.

It does not seem like google would allow to have an account unrecoverable.

So yes, authentication and also two factor authentication is only as good as the processes - in this case the recovery process. And if you have a poor recovery process, then the 2FA is poor, too.


how to update GPG private key that Pass uses I've setup up Pass with a GPG key. That key expires at some point in the future. In preparation for this event, how would I update Pass to use a new Key? Do I just manually update the key id and password file that Pass uses?

After looking closer at the man page you can update the public encryption key with:

pass init [ --path=sub-folder, -p sub-folder ] new-gpg-id


If TLS compression is not supported is a site still vulnerable to attacks such as BREACH? I have read that BREACH was a side channel compression attack against TLS however focuses on HTTP response compression. If a site has disabled support for TLS compression does that still mean it can be compromised by an attack such as CRIME, BREACH, etc...using HTTP compression/HTTP responses?

Also, does this type of attack require compression support from both the browser and the server to be successful?

BREACH and CRIME don't compromise sites, because they are attacks on clients, not on servers. The server is still involved in that, for instance, TLS compression won't be used unless the server agrees; so that, even if the CRIME attack targets the client, the server can refuse to use compression and this indirectly protects vulnerable clients.

Both attacks relate to the same general principle: encryption hides data contents, but not data size. Compression makes data size dependent on data contents. Therefore, compression can leak information on data contents that encryption won't protect. If the attacker is in a position where he can inject some data of his own along with the data that he tries to recover (formally, a chosen-plaintext attack), then he wins.

CRIME was an application of this concept to TLS-level compression in a Web context. The Web allows for Javascript, that can be hostile and issue requests (subject to some constraints in the case of cross-site requests); this is how the attacker can achieve a CPA situation. Deactivating TLS-level compression fixes the issue, and it was not really fixable in any other way, because the compression-induced data leakage is a very generic concept. Note that HTTP-level compression does nothing for or against CRIME, since CRIME concentrates on the header (the request path and the cookie).

BREACH is another application of the concept, this time on HTTP-level compression. HTTP-level compression is performed only on request bodies, not on the HTTP headers, so BREACH is harder to pull off (while CRIME worked whenever a cookie was involved, BREACH requires the site contents to be amenable in some way to the attack). Disabling TLS compression will do nothing for or against BREACH.

Anyway, compression (be it for TLS or only for HTTP request/response bodies) will be applied by any machine only if it is reasonably sure that the machine at the other end of the connection will understand it -- because of some prior indication to that effect (in the TLS ClientHello message for TLS, in a request header for HTTP). There will be no compression, hence no attack, unless both client and server support it and agree to use it. This is how mitigation for attacks on clients can be applied on the server.


How did a bug like CVE-2018-10933 (libssh authentication bypass) happen? How did a bug like the recent libssh vulnerability come to exist?  Exactly what is the nature and root cause of the bug?

From libssh's website:

  libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate (sic) without any credentials.

To me, this just raises more questions to me: why would the server trust anything from the client?  Why does SSH2_MSG_USERAUTH_SUCCESS even exist at all?  Is it part of the ssh protocol?

The underlying issue that caused this bug and many bugs like it is a false assumption.  namely that a certain message (SSH2_MSG_USERAUTH_SUCCESS) would only ever be sent by a server to a client...libssh failed to consider that a malicious client might send this message to a server.  Based on this failed assumption the library had a single state machine (shared by client and server implementations) that clicks to on (as in connection accepted) when this message arrives.  It is generally false assumptions that create security holes.