Isn't Ubuntu's system prompt for my password spoofable?

Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect.

Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard that the recent generation of Windows is more terminal-friendly). In particular, Linux convention does a better job of sandboxing apps into users, while in Windows anything important runs as System, while the Linux GUI (X Server) sucks at security, and the Windows GUI has fancy things like UAC built-in. Basically, Linux is (and always has been) a server first and a workstation second, while Windows is the other way around.

Security Models

As far as "the OS" (ie the kernel) is concerned, you have 7 tty consoles and any number of SSH connections (aka "login sessions") - it just so happens that ubuntu ships with scripts to auto-start the GUI on the tty7 session, but to the kernel it's just another application.

Login sessions and user accounts are sandboxed quite nicely from each other, but Linux takes a security mindset that you don't need to protect a user from them-self. In this security model, if your account gets compromised by malware then it's a lost cause, but we still want to isolate it from other accounts to protect the system as a whole.

For example, Linux apps tend to create a low-privilege user like apache or ftp that they run as when not needing to do rooty things. If an attacker manages to take control of a running apache process, it can muck up other apache processes, but will have troubles jumping to ftp processes.

Note that Windows takes a fundamentally different approach here, largely through the convention that all important things run as System all the time.  A malicious service in Linux has less scope to do bad things than a malicious process running as System, so Windows needs to go to extra efforts to protect someone with admin rights from "them-self".

GUI environments and an X Server that was not designed for security throw a wrench into this security model.

Gnome gksudo vs Windows UAC, and keyloggers

In Windows, when a user-process requests privilege escalation, the kernel throws up a special protected prompt whose memory and keyboard / mouse bus is isolated from the rest of the rest of the desktop environment. It can do this because the GUI is built-in to the OS. In Linux, the GUI (X server) is just another application, and therefore the password prompts belong to the process that invoked them, running as you, sharing memory permissions and an input bus with every other window and process running as you.

The root prompt can't do the fancy UAC things Iike lock the keyboard because those either need to be root already, or require totally re-designing the X server (see Wayland below). A catch-22 that in this case is a downside of separating the GUI from the kernel. But at least it's in keeping with the Linux security model.

If we were to revise the security model to clamp down on this by adding sandboxing between password prompts and other processes running as the user in the same GUI session, we could have to re-write a great many things. At the least, the kernel would need to become GUI aware such that it is capable of creating prompts (not true today). The other go-to example is that all processes in a GUI session share a keyboard bus.

Watch me write a keylogger and then press some keys in a different window:

➜  ~ xinput list
⎡ Virtual core pointer                      id=2    [master pointer (3)]
⎜   ↳ Virtual core XTEST pointer            id=4    [slave  pointer  (2)]
⎜   ↳ Logitech K400 Plus                    id=9    [slave  pointer  (2)]
⎜   ↳ ETPS/2 Elantech Touchpad              id=13   [slave  pointer  (2)]
➜  ~ xinput test 9
key release 36
key press   44
hkey release 44
key press   40
ekey release 40
key press   33
lkey release 33
key press   33
lkey press   39
okey release 33
key release 39
key press   66
key press   31

Any process running as you can sniff the password in another process's prompt or terminal and then call sudo on itself (this follows directly from the "no need to protect you from you" mindset), so increasing the security of the password prompts is useless unless we fundamentally change the security model and do a massive re-write of all sorts of things.

(it's worth noting that Gnome appears to at least sandbox the keyboard bus on the lock screen and new sessions through "Switch Users" as things typed there do not show up in my session's keyboard bus)

Wayland

Wayland is a new protocol that aims to replace X11. It locks down client applications so that they cannot steal information or affect anything outside of their window. The only way the clients can communicate with each other outside of exterior IPC is by going through the compositor which controls all of them. This doesn't fix the underlying problem however, and simply shifts the need for trust to the compositor.

Virtualization and Containers

If you work with cloud technologies, you're probably jumping up and down saying "Docker is the answer!!". Indeed, brownie points for you. While Docker itself is not really intended to enhance security (thanks @SvenSlootweg), it does point to using containerization and / or virtualization as a forward that's compatible with the current Linux architecture.

Two notable linux distributions that are built with inter-process isolation in mind:

Qubes OS that runs user-level apps inside multiple VMs separated into "security domains" such as work, banking, web browsing.

Android that installs and runs each app as a separate low-privilege user, thus gaining process-level isolation and file-system isolation (each app is confined to its own home directory) between apps.

Bottom Line: From the perspective of an end-user, it's not unreasonable to expect Linux to behave the same way as Windows, but this is one of those cases where you need to understand a bit about how the underlying system works and why it was designed that way. Simply changing the implementation of the password prompts will not accomplish anything so long as it is owned by a process owned by you. For Linux to get the same security behaviours as Windows in the context of a single-user GUI workstation would require significant re-design of the OS, so it's unlikely to happen, but things like Docker may provide a way forward in a more Linux-native way.

In this case, the important difference is that Linux is designed at the low level to be a multi-user server and they make the decision not to protect a user from them-self, while Windows is designed to be a single-user workstation, so you do need to have inter-process protections within a login session. It's also relevant that in Windows the GUI is part of the OS, while in Linux the GUI is just another user-level application.


As a user, is using MD5-encrypted passwords on websites a good practice?

There's no question that this extra MD5 layer is better than just using the original password.

The question is whether you'd be better off using a Password Manager which simply generates random passwords and stores them in encrypted form.

I do see the elegance of your solution over a Password Manager.

Since the final password is derived, not stored, then your solution is portable. There is no need to sync passwords over the internet for multiple devices.
The 'easy to remember' password unlocks the 'actual' password for just one site. This seems better than using a 'single' Master Password to unlock the 'actual' password for any site as a password manager would normally operate.

From a server-side breach perspective, this is such an unusual (Obscure) practice that the attackers will go to easier targets.

However, it is true that a truly random password (from a Password Manager) would be more secure than one from a simple MD5 hash.

I would suggest you extend your solution somewhat.

Use a stronger hash, not MD5. Probably you should use PBKDF2, but you could be using SHA-256 or SHA-1 if it is easier for you. Stronger also means slower. So if you use a fast hash, you should add repetition. (number of Rounds)
Add some Pepper, which is stored with your hashing program, and has about 72 bits of entropy.

Input this same Pepper, and number of Rounds for the hash algorithm on all your devices, so they all can generate the same passwords. Also keep it in a file somewhere so you can always re-produce your hashing scheme should you lose the electronic copy.

vs a Password Manager

You have no Master Password, so there is no 100% loss when that password is stolen along with your device data.
If your device data is stolen, the Pepper is immediately compromised because it is stored in plain form. However, they still have to guess your 'easy to remember' password.

There will be some obstacles regarding password strength requirements. A Password Manager could store a different style password to fit the particular requirement, but your hash program will operate the same for all sites.

Tweak your hashing program to produce an uppercase letter, lowercase letter, number and some special character. This will fit the needs of most password strength requirements out there.
It might be necessary to truncate the resulting hash as some sites have a max-length. This is not a big problem. If you only take the first 20 characters of the resulting hash, the strength is not diminished. Only when you get down to about 72 bits of entropy (18 hex chars or 12 Base64) does truncation become a notable weakness.


Finding out if a series of job emails from the same person are a scam or a way of tracking/phishing?

This looks like a scam to me.

The Link to "their recruiting-site" is really a red flag for me. Not explaining the reason, why they reach out exactly to you and how they got your contact is also not professional at all.

One possible scam scheme could work like this:

Send E-Mails.
Send Follow-Up-Emails until you believe it's legit.
Make some promises about a great job and a permanent residency in Canada.
Request some money for the paperwork (visa, work permit, etc.)
Find more reasons, why they need some more money or information
repeat #4 and #5 until you give up

However there might be numerous other schemes, that could allow him to make money, gain information or your trust.

Edit: If you were to click the links or load the images in the mail, he'd probably able to identify your OS, Browser, Browser-Plugins, rough location (based on IP), validate your e-mail address. This can, in rare cases, be sufficient to successfully compromise your system, depending on patches, etc.


What you are proposing is not designed to solve the problem. What you have described is similar to what SSL/TLS, S/MIME do. It provides data privacy, but not client authentication.
For certificate-based authentication, you have to ask approved API consumers to generate CSR and sign them by your private and approved CA. Then configure web server to require client certificate and configure authentication/authorization middleware to check the certificate to be signed by approved issuer. You may need to store an identity database to map certificates to identities and audit purposes. For example, if you need to revoke access for specified user.
There are a lot of online articles on Client certificate authentication subject for very different platforms. You can just query your favorite search engine by specifying your web server product.


Where to store a server side encryption key?

Here are your possibilities, roughly in decreasing order of sophistication.

Use an external Hardware Security Module. There is an entire industry of products designed for offloading security-sensitive operations to external devices. This doesn't solve the problem so much as relocate it, but it relocates it to device that is far more secure, so altogether it's a security win. If you're doing anything high-stakes, then this is almost certainly going to factor into your solution.
Tie the encryption to your hardware. In theory HSMs do precisely this, only we tend to expect a bit more sophistication from an HSM than just hardware-backed crypto. But there are cheaper options available if you don't need the throughput and compliance that a true HSM brings to the table. TPM chips were invented in part for this purpose, and many examples exist showing how to integrate with them. Additionally, dedicated crypto hardware has become fairly inexpensive, and re-purposing devices like Open-Source U2F Keys for this is simpler than it sounds.
Tie the encryption key to your admin login (e.g. encrypt the the encryption key with your admin login). This is only marginally useful as it requires you to be logged in in order to encrypt/decrypt anything. But on the plus side, no one can encrypt/decrypt anything unless you're logged in (i.e. greater control). Much of the secure storage in Windows works like this.
Type in the encryption key when you start up, store it in memory. This protects against offline attacks (unless they capture the key out of RAM, which is tougher to do). Similar to the option above, but also different. However, the server boots into an unusuable state, requiring you to manually supply the key before work can be done.
Store the key on a different server. E.g. put the key on the web server and the encrypted data on the database server. This protects you to some degree because someone would have to know to grab the key as well as the database, and they'd also have to have access to both servers. Not amazingly secure, but an extremely popular option anyway. Most people who think they're doing it right do it this way. If you're considering doing this, then also consider one of the first two options mentioned above.
Store the key elsewhere on the same server. Adds marginal security, but not a whole lot. Most smaller operations do this -- they shouldn't, but they do. Typically because they only have one server and it runs in some cloud somewhere. This is like taping a key to the door instead of leaving it in the lock; guaranteed to stop the most incompetent of attackers.
Store the key in the database. Now you're not even trying. Still, a depressingly popular option.

Many cloud-based KMS solutions (e.g: AWS, GCP, Azure) when used most effectively will bind your encryption to your cloud VMs or environment. The unique identity of your VM is easy for the hypervisor to establish and assert, and the KMS uses the combination of that identity and the permissions you've assigned it to allow access to an HSM-managed encryption key. This is similar to a combination of options 1 and 2, modulated to account for the ephemeral nature of Cloud VMs. These KMS solutions generally also are compatible the platform's other identity mechanisms, effectively tying encryption keys to login keys; a lot like option 3.


Key exchange during IKE_AUTH phase of IKEv2

The SAi2/SAr2 payloads, together with the TSi/TSr payloads, are used to negotiate the initial Child SA. As per RFC 7296, section 1.2:

  The initiator begins negotiation of a Child SA using the SAi2
     payload.  The final fields (starting with SAi2) are described in the
     description of the CREATE_CHILD_SA exchange.

However, the key material for this Child SA is derived from the IKE key material (established with the KE payloads during IKE_SA_INIT), so there is no separate key exchange. DH groups are explicitly not included in the SA payloads during IKE_AUTH. From the same section as above:

  Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
     Thus, the SA payloads in the IKE_AUTH exchange cannot contain
     Transform Type 4 (Diffie-Hellman group) with any value other than
     NONE.  Implementations SHOULD omit the whole transform substructure
     instead of sending value NONE.

An IKEv2 implementation that supports RFC 6023 (Childless IKEv2 Initiation) can omit these SA/TS payloads and create an IKE SA without initial Child SA.

When creating or rekeying Child SAs later with CREATE_CHILD_SA exchanges the peers may optionally negotiate a DH group and exchange their public DH factors using KE payloads (if that's not done the keys for the new Child SA are again derived from the IKE SA key material). This serves the purpose of separating the IKE from the Child SA keys and the Child SA keys from each other (this is usually referred to as Perfect Forward Secrecy or PFS).


Do you need to know the filename to conduct a Directory traversal

Directory traversal is a rather broad vulnerability that can lead to a variety of attacks, depending on context.

On its own, it only means that an attacker supplies a file or directory name, and can travers to files or directories outside of the expected directory. This can facilitate attacks such as:

LFI
Reading of files outside of the desired directory
Uploading files outside of the desired directory, possibly leading to code execution (for example if the only thing preventing code execution is securing the desired directory)
moving files outside of the desired directory
Viewing directories outside of the desired directory, which may help an attacker gather information about the target system
etc

Giving your files complicated filenames could only possibly help in the case of reading out files outside of the directory, and only if you do not provide the ability to list files.

Renaming your files may seem like a good idea as defense in depth - security by obscurity should never be your only line of defense -, but it's not really worth it, as there are larger attack surfaces than reading out your PHP files.

In the case of LFI, an attacker can still read out system files which can have severe consequences. Depending on your configuration, they may be able to:

read out /etc/shadow, crack the passwords, and gain access to the system
inject code into various log files and include them, leading to code execution
inject code into proc/self/environ and include it, leading to code execution
etc

So renaming files may prevent an attacker from reading out those specific files, but doesn't really limit the damage of LFI. It also leads to reduced maintainability, making it not worth the trouble.


Text entities in HTML can't do anything interesting, and the content between span tags is interpreted as text. To do anything interesting, you'll need to inject a new entity (which is done using < and >), or you'll need your input to be injected into a non-text location (such as the parameters of an entity, or inside a <script> block, or similar). If your input isn't being reflected anywhere else, and < and > are always encoded, then you can't exploit the page via XSS.

However, there might be ways to trick the server into sending un-encoded < and > without it meaning to. One way that I've seen is to send Unicode characters that aren't <> but that the server might map down to those ASCII characters before reflecting them into the output. Consider characters like ˂˃, ‹›, ≤≥, ＜＞, all of which may get mapped to <> by a server and then not get encoded as &lt; &gt;. No guarantees, but it does happen.


How do open (no password) wireless networks deal with abuse?

Most sites with open wireless systems deal with abuse by not caring. And that's it.

When police forces need to identify some villain and know that he connected to some wireless hotspot, e.g. in a bar, they resort to what police forces have always done since police exists: witnesses. Just ask everybody if they saw someone shifty or hacker-looking. In recent times, this includes surveillance video cameras. The fundamental property at work, here, is that perpetrators of computer crimes are also human beings, with corporeal bodies, biological needs, and leaving traces everywhere.

While some attackers feel that "the game" is to be played in the computer world only, law enforcement agencies do not consider themselves to be constrained that way. If I remember correctly, Kevin Mitnick first reaction, upon being arrested, was to say that Tsutomu Shimomura had "cheated" by calling the cops instead of defeating him with "computer skills" only. (This anecdote is likely to be apocryphal, but I find it representative of the mindset of many wannabe hackers.)


Security risk: Digitally sign communications for SMB

Indeed, Microsoft Technet lists MITM prevention as the sole use of this setting. And a digital signature does just that: to prove the authenticity of a digital message. If your network is trusted and MITM scenarios are really (!) not possible, it can be disabled.

Apparently there's also a performance decrease involved when it's enabled. So, if you're disabling it for performance reasons: you're trading performance for security.


How does Bitlocker Drive encryption work and which info are sent?

If I insert a USB key encrypted with BitLocker on a different device, I can access the storage only if I have the recovery key, right?

That depends entirely on what key protectors are used on the flashdrive. A key protector is a bit of BitLocker metadata that provides a way to obtain the actual disk encryption key. Common key protectors are the recovery key, passwords (or PINs), a key file stored on another flashdrive, or (for boot volumes) a TPM.
If a flashdrive is encrypted on a system that already uses BitLocker, and is set to automatically unlock on that system, a key protector is used where the host machine will store a secret on its (encrypted) drive. If that's the only key protector other than the recovery key (which is always created by default, although it can be removed), then the only way to unlock the flashdrive on another computer is to use the recovery key, yes. However, it's pretty common for an encrypted flashdrive to also have a password key protector; in that case, you can decrypt the drive on any machine so long as you know the password, which is much more memorable than the recovery key (it's also more at risk of brute-forcing, so BitLocker will attempt to delete this key protector after multiple failed guesses... though that only works if the real BitLocker driver is running, and is able to write to the flashdrive).
Note also that the usual way to encrypt a flashdrive with BitLocker is a bit different from how BitLocker normally works. Since it's expected that a flashdrive might need to be used on machines that don't support BitLocker, the drive's main partition is shrunk slightly and a second partition is created. This second partition gets a small Windows executable that can read (though not write) BitLocker-encrypted partitions (such as the main partition of the flashdrive). For the main partition, I'm not sure if it works like a normal BitLocker volume (which contains some behavior that seems specific to NTFS) or if it works a bit differently, in some way potentially agnostic to the underlying FS.

If the USB key has been encrypted with BitLocker in a device for which the user is not admin, can the admin find out when it is inserted into a different PC?

No. Cryptography doesn't involve any sort of "phoning home" - it's just math - and there's no mechanism for BitLocker to even store a routable address to the machine where it was encrypted. Windows can, depending on configuration, automatically upload the recovery key when a drive is encrypted (either to Microsoft or to a domain controller), but as far as I know it won't automatically search for any such uploaded key - the location or even fact of the upload isn't part of the protector, so it wouldn't know where to search - and of course if the recovery key wasn't uploaded at all (or was only uploaded to a private network that the different PC isn't on, such as the controller of a corporate domain) then there wouldn't be anything to find (and thus no way to link the drive to its encrypter) anyhow.


Is it possible to create a honeytoken as an image file?

If you strip out all the extra layers about why you are pursuing this, you are left with a single function: the opening of an image to result in an automated action being performed.
That's not feasible.
It will be highly dependent on the viewer being used and the functions, or vulnerabilities, in that viewer. Just as Word files can have macros that can only be interpreted by Word and not notepad, you have the same problem with images. And there are a hundred different ways of viewing images.
A tracking pixel works because it's not about the image, but about the active link. If you can make the image a link to a resource you can control, then you can track where/when it is opened.


Why is Chrome asking for the application-specific password and my account's password every time?

I was also wondering why chrome ask every time a new application-specific password. Then I realized the reason is that the computer which chrome run on is not a trusted computer. I made it a trusted computer then chrome never asked specific password again.

Here is how to make a computer trusted, quoted from here

  You can add your computer to the
  trusted list at any time. When you sign up for 2-step verification,
  you’ll be asked if you want to trust the computer you’re using. You
  can also mark a computer as trusted by selecting “Trust this computer”
  when entering a verification code.


P12 private key vs private key file : what is more secure?

It turns out that this is pretty interesting stuff.

From the Martin Kleppmann's blog "Improving the security of your SSH private key files" (Posted 2013-06-26. Archived here. HackerNews'd here):

But how do you get from the passphrase to the AES encryption key?
I couldn’t find it documented anywhere, so I had to dig through
the OpenSSL source to find it:

1. Append the first 8 bytes of the IV to the passphrase, without
   a separator (serves as a salt).
2. Take the MD5 hash of the resulting string (once).

That’s it.

So this means that there's not much password-to-key-transformation going on. And Martin then recommends using PKCS#8 instead.

But the question was not about PKCS#8 but about PKCS#12.

And the RFC for PKCS#12 says, that there is still a compatibility mode that works similarly. And they say that you should instead use PBKDF2.

Appendix B.  Deriving Keys and IVs from Passwords and Salt

   Note that this method for password privacy mode is not recommended
   and is deprecated for new usage.  The procedures and algorithms
   defined in PKCS #5 v2.1 [13] [22] should be used instead.
   Specifically, PBES2 should be used as encryption scheme, with PBKDF2
   as the key derivation function.

Now this implies that both old and new methods can be used. And the new method is safer.

So in summary: PKCS#12 files are potentially safer than the "BEGIN RSA PRIVATE KEY" PEM files.

But: What I CAN'T tell you is how you would find out if a given PKCS#12 file has in fact used the old or the new method. Perhaps some other StackExchange member can chime in?


How can I get a fiddler-style trace of an iPhone / Android?

The easiest way is to set an HTTP proxy. On iOS you can do this in your WiFi settings and there's a similar setting in Android.

Point the phone at an interactive proxy (probably Burp or Zap) on your laptop. This gives you an interface similar to fiddler.

To intercept HTTPS, you need to install the certificate from your proxy on the phone.

Some applications will refuse to operate like this. For example, if they use certificate pinning. There are move advanced techniques to get round this.


For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used?

In order to find out which encryption method was used, the first thing you can do is look at the length of the key and ciphertext in order to limit and rank the likelihood of the possible candidates:

With a keysize of n bits, obviously only encryption schemes apply that support keys of this size. For example: if n is 168, you can be pretty sure the 3DES block cipher is used (you don't yet know the mode of operation, though); if n equals 128 or 256, the list of likely ciphers is a bit longer.
If the ciphertext length is a multiple of 128 bits (a common scenario), there is a good chance a block cipher that uses this block size (probably AES) was used in the extremely common CBC mode. When the ciphertext size is not a multiple of 128 or 64 bits, you can be pretty sure you're looking at something encrypted with either a stream cipher, or a block cipher using something like CTR or GCM mode.
Certain ciphers are very common (particularly AES-CBC), test these first.

Next, you can simply try the candidates one by one until you end up with a plaintext that does not look like random gibberish. If an authenticated encryption scheme is used, you don't even need to look at the plaintext because the algorithm tells you when it is correct.

Of course you will still need to somehow distinguish 'random gibberish' from a proper plaintext. Because the number of common encryption schemes that are commonly used is quite limited, it is probably enough to just print the decryption result to a text file and let a human look at them. If you want to check for valid plaintexts in an automated manner, you will either need to utilise some knowledge about the encrypted material (for instance, that it contains a UTF-8 encoded text or that it is a JPEG image) or run some simple statistical test. Note that you will probably not succeed at all if the plaintext is actually a sequence of randomly generated bytes not known by you.

Some matters can make this process more complicated: almost all encryption schemes require an IV or nonce that are essential for decrypting the ciphertext. This IV/nonce is probably prepended or appended to the ciphertext, but if not it might depend on the context of the cryptographic protocol. If you really have no idea what the IV/nonce might be, you could always try a few small numbers, hoping that sequence numbering is used to determine the IV.

Also note that the data you think is a ciphertext might actually contain more that just encrypted data. Besides the IV or nonce mentioned above, a MAC (message authentication code) or authentication tag may have been appended or prepended. If it is appended, it will probably not be problematic; but if your ciphertext starts with it you might accidentally start decrypting it and thus obfuscating the rest of the plaintext.

Last but not least there are also cascaded ciphers: multiple encryption algorithms with which the data is encrypted in succession. If you want to check all of them (up to a certain maximum of ciphers used), they could grow your search space significantly. However, only a limited number of different cascaded encryption schemes are used in practice, so this will probably not be much of a problem.

If all of this fails, it may be the case that an obscure cipher is used that you have no knowledge of. In this case you can hope it's crappy DIY-encryption and you can start trying to perform some actual cryptanalys on it.


Can I use a KEK to protect data as well?

It seems OK.

Key Encrypting Key (KEK) is quite a confusing name. It puts emphasis on the fact that a particular key is used to encrypt another key (which in turn encrypts data), as if this bare fact somehow increased the security. It doesn't. The additional security comes from something else, and (by me) the name of this scheme should really be Separately Encrypted Key to reflect what really is important here.

The added security comes from the fact that software modules or people or devices that can see keys or data (either encrypted or plain) can be divided. You separate some inner environment and leave the rest in the outside security perimeter. The outside:

doesn't know the most important secret (aka the KEK)
but is more accessible to outsiders, as it provides many functions and needs to accept various data inputs

The inside has to be separate from this; it needs to have exactly opposite characteristics. The inside is typically just the key encryptor (a software module), key decryptor (ditto), the storage which holds the KEK (a software module or hardware device) and people who can access these.

In your situation, I understand customer requests to add some NewData (to be KEK-encrypted). I think it is safe if and only if is not exposing the Inside to any additional risks that is:

obtaining the NewData does not involve any additional risk; that is NewData does not come from the outside app perimeter, so it is injection/overflow free
delivering the NewData to destination does not involve any additional risk; doesn't require to contact any parts from the outside perimeter
(obviously) encryption and decryption of NewData is done by the same components that already know KEK - the KEK is not put at any additional risk by leaking it to some other components,
(obviously) you use a normal cipher, like AES, which is immune to known-plaintext attacks. The keys that you used to encrypt were pseudo-random, but NewData could be known to attacker,
(obviously) the NewData does not require any additional people to have access to the Inside.

If all these don't hold true you already have some starting points to analyze and communicate the risks involved.


After How Much Data Encryption (AES-256) we should change key?

A block cipher is a Pseudorandom permutation: the key selects the function seemingly at random in the set of possible permutations of the space of block values (that space has size 2128 for the AES, since it has 128-bit blocks). Most usages of a PRP are fine as long as it looks like a Pseudorandom function. The difference between a PRP and a PRF is that the PRP will never give you two identical outputs for two distinct inputs, whereas the PRF may do so. However, a randomly selected function will give you such a collision only out of random, and it will require a lot of invocations: on average, 2N/2 invocations if processing blocks of size N.

Translation: when you encrypt more than 264 blocks with AES (i.e. 268 bytes, since an AES block is 16 bytes), AES begins to look more like a PRP than a PRF, and that's the point where you should stop. That's more than 250 millions of terabytes, which is quite a substantial amount.

It does not matter whether the said amount of data was processed as one, ten or 42 billions of whatever you may elect to call a "file". The AES processes blocks of 16 bytes and knows nothing else. On the other hand, it does not matter at all, since you will not practically reach that 268 bytes limit: AES was defined with 128-bit blocks precisely so that we could encrypt terabytes of data without worrying about a key running out of juice. When AES was specified, it was meant to replace 3DES, whose 64-bit block size was indeed worrying (232 blocks of 8 bytes, that's 32 gigabytes, which can be reached quite easily on today's machines).

Key size has nothing to do whatsoever with that matter. It is all about block size, and that's 128 bits for AES (regardless of key size).


Can Facebook break the WhatsApp E2E encryption without the customers noticing?

Facebook controls everything inside the WhatsApp environment, i.e. the applications on the phones, the web access and the transport of the messages. Because of this it could also make any changes which would decrease the security in a way that the end-user will not notice. It might also make the changes in a way that security experts will not notice unless they really know where to look.

The only kind of guarantee that WhatsApp does not do this is that it markets the E2E security as one essential feature and that WhatsApp will loose a lot of trust (and customers) if it gets public that it knowingly decreased the security. And given that someone has to actually make the necessary changes inside WhatsApp and that these changes will also have side effects of leaking information (because that's the main point they were added) it will likely only be a question of time that it will be known that such kind of backdoors are in the product.


Could an IPS have blocked an attack on a vulnerable router/firewall?

Theoretically, could a Intrusion Prevention System (IPS) appliance ... placed in between an ISP/gateway and a vulnerable router/firewall have blocked the attack, assuming a matching signature was already installed in the appliance database?

There are several parts of the attack which could be used for signatures:

The initial infection, which was maybe done by accessing the remote management interface of the to-be-infected systems. While attempted access to such interface might be considered malicious in most cases there are still valid reasons for such an access so a relevant signature might result in false positives.
The C2 communication after a successful infection. According to the available information the communication was done using Tor or SSL. The use of Tor itself might be suspicious but is also legal, so the chance for false positives is here too. SSL is hard to analyze but one might only check SSL to specific destinations  and then check for atypical client-side fingerprints (i.e. ClientHello). But again, the chance for false positives exist.

If you look at the report from Cisco you'll see at the end the coverage for this issue by Cisco products and you'll see that it seems to rely on detecting the C2 communication.

  Or–even if blocking such an attack were possible–would it have been too late if this was in fact a zero-day attack?

While the initial infection might have been zero-day (or not, since systems with known issues were attacked) the later C2 communication was not. Thus the ISP might not have been able to protect systems against infection but might (with maybe considerable efforts) be able to detect infected system and limit what they could do by informing the customers and/or limiting traffic from these systems.


How does RSACryptoServiceProvider generate keys

RSACryptoServiceProvider, like most system classes in .NET, is a thin wrapper around the older Win32 implementation (an API which was meant to be used with C or C++ -- or even Pascal, if we really dig deep). See CryptAcquireContext(). In .NET terminology, this is called "unmanaged code".

Generating a RSA key pair involves producing new random prime numbers. Knowledge of these primes is the private key, so we strongly hope that the Microsoft implementation does not simply uses a fixed list of pre-generated primes ! Conceptually, this generation is simple: produce sequences of random bits of the right size, and repeat until you find one that is prime.

In more details, if you want a 2048-bit RSA key, you will need two 1024-bit primes whose product is a 2048-bit integer. This goes that way:

Generate a sequence of 1024 random bits, such that the first two bits and the last one are equal to 1; the 1021 other bits are obtained from a strong random source (in Win32, this is CryptGenRandom() -- RNGCryptoServiceProvider is the .NET wrapper).
Interpret the 1024 bits as a big integer p. Since we set the first two bits to 1, and there are 1024 bits, then the integer is greater than 3×21022 and less than 4×21022; since the last bit is also 1, the integer is odd.
Verify that p-1 is not a multiple of the chosen RSA public exponent. Traditional exponent is 65537. There is a probability 1/65537 that p-1 is a multiple of 65537; if that is again, go back to step 1 to generate another candidate.
Test the integer p for primality. There are several methods for that; usually, Miller-Rabin primality test is used. If p is not found to be prime, go back to step 1 to generate another prime. For a 1024-bit p that we took care to make odd, you can expect to test an average of about 500 candidates before finding a prime.
Once you have generated a random prime p, do that again to get another one, which we will call q.
The modulus will be n = pq. The public exponent is the chosen e (65537 in the example above). The private exponent d and the other RSA private key components are computed algebraically from p, q and e. Thanks to the way p and q were generated (two top bits equal to 1), it is guaranteed that n will have size 2048 bits, not 2047.

The whole API is barely usable. The concept of the "default key" is aberrant; you cannot decently rely on it in any protocol, since you do not control neither its storage nor its life cycle. Also, that default key will have length 1024 bits, which is a bit too short for today's technology. If you want to obtain and use a RSA key, you should ask for its generation explicitly, and certainly not register it as a "default" that any other application may use or possible modify, export, publish or whatever.

It is also badly underspecified. CryptAcquireContext() accepts multiple options that impacts how the key, if any, is generated and stored; the documentation for RSACryptoServiceProvider does not tell which options are used. If you want to know what really happens under the hood, you have to delve into the source code.

The bottom-line is that the RSACryptoServiceProvider constructor will generate new primes, for a 1024-bit RSA modulus (hence 512-bit primes), but it will try to keep around a "default key" so that it will do that only once even if you call it repeatedly. Note that producing a new 1024-bit RSA key takes only a fraction of a second with a modern PC.


Disclaimer: IANAL

  1    is this common now?! conversely is it brand new?

First time I read of it, but I know that many online banking system propose to aggregate your other bank accounts on their site. Mine proposed to but I declined so I cannot tell exactly how they manage to prove the third party bank that the client allows them to gather account elements. The account number is certain, I do not know for other credentials. The goal is to collect all of your banking informations, because this does have value for announcers.

  2    would it actually be illegal in some way?

As already said IANAL. But I cannot imagine why it could be illegal: they ask you some information saying how they will use it. You are the information owner and can choose to share it with them or not. The only point that could be illegal would be that they declare to not store an element and actually store it. Being professional, they also have to protect your sensitive data, but provided it is not transmitted in clear text nor stored, I assume that it is enough.

  3    it seems incredible that other banks wouldn't block them once they heard of the practice, or at least complain bitterly.

Not that simple. The other bank has a contract with you allowing you a number of operations provided you can prove that you have an account, a password and a unique code sent to a device or mail address. You are responsable for securing those elements and implicitely ask them to honour any request presenting them. They would probably be more happy if you used their own system to connect to your other bank accounts, but I cannot imagine a legal point for preventing you to use any third party added value system.

Now for my opinion. On a security point of view, a secret should never be shared by more than 2 entities. So I would never post my credentials for a site on a site of a third party company, whatever the reason. I know that this will prevent me to use some sexy added value aggregators and I accept it. At least I will try to keep that security policy as long as I will be able to...


How should I respond to an unrecognized client in my DHCP logs?

You can leverage arpwatch to notify you the second it broadcasts on your network again and also use a tool like Wireshark to capture traffic and see what the device is communicating to (logging DNS queries sometimes works too). Sometimes IoT devices like thermostats, toys, equipment or even certain operating systems will call home on a regular basis looking for updates. This may help you figure out what type of device this is and make it easier to find.

Alternatively, you could get a directional antenna and a tool like Kismet next time the device is on-line and try to locate it via signal strength.


Robots trying to login to Azure VM when SSH port is closed in manager

No need to worry, these are just typical attempts to find vulnerable servers. You've Fail2Ban already installed, this way you decrease the brute force attempts.


Resetting password for stored encrypted data

What you describe is a common use case in medium to large organization: users can encrypt their sensitive data, but a copy of the key must be saved (generally in a physical safe) in case they forget their password or are no longer able to decrypt it (death, serious injuries, etc.)

Windows offers an out of the box way where an administrator can be allowed to decrypt a crypted folder. Other systems can be imagined, with the following pattern:

a symetric key is used to encrypt the data
that key is then encrypted with the user password (*) and saved that way. When the user changes its password, the keyfile is decrypted with old password and re-encrypted with the new one
a copy of the symetric key is securely stored in a physical or logical safe accessible to a security officer (or even better procedures could requires two different persons to unlock the safe)

(*) More exactly the user password is used to access the symetric key. But it can be actually encrypted with:

a hash of the user password
a public key of the user (he then uses his private key protected by his password to decrypt)
or stored in a password vault

The same variations can be used to store the copy.


Petraeus scandal - what would have been a better way to communicate electronically

Don't send unencrypted email with secret information that can get you in trouble.

Ask others not to send you secret information through unencrypted email, and if you receive act like you don't understand the information.

The problem isn't a particularly a technological one; its they used public email (e.g., gmail) to transmit information that could get him in trouble if it becomes public.

Now if Patreaus had an secret account that no one knew about, and only accessed it through tor (or something), never had his name associated with it (e.g., Broadwell was instructed not to use his name), never saved emails to his computer, never left credit card statements with the VPS (e.g., she charged the credit card statements), etc he could possibly get away with it.

But then again, the US govt may not be too happy with a general having secret unmonitored VPS accounts sending out information to unknown parties.


first of all: please disallow any network-connections in/out via iptables, except ssh. chance is given your server is part of a botnet already.

running an outdated $whatever is bad, as you experienced, see  [1], [2]

for your second part: you dont know if files are modified and malicious stuff included, or any hidden file dropped into your docroot. finding such stuff needs some experience though. you shoudl also check /tmp for hidden directories or
your network-config.

what you can do: grab clean joomla-sources and do a setup with your database; but check your database for stuff that does not belong there.

you can check your website with sucuri
or your server-ip with robtex to see, if your site is already known as bad; google-safebrowsing might give another hint.
and google has a page to help/inform people like you: here

you should also check your logs for that ip that accessed that wp-conf.php.


A conditional forward is SPECIFIC to a domain being queried at the end of the day.  Let's model this:

YOUR COMPANY
yourco.com
finance.yourco.com
mrkting.yourco.com

Internet
yahoo.com
google.com
blogger.com

Internet.Misc
login.yahoo.com

We have your company three websites, and a specific Yahoo site. When a machine makes a query from say your network:

john.yourco.com --> whois finance.yourco.com --> your DNS server

It's best this query be handled internally by your DNS servers. This minimizes any kind of leakage. You wouldn't want anyone on the outside to be able to even know about the internal design of your network, e.g.: prototypes-of-new-revunue-generation.yourco.com

Now, when someone in your network visits say Google, Blogger, Yahoo, initially they'll query your DNS server:

john.yourco.com --> whois google.com --> your DNS server

In the event your DNS server doesn't see it right away, it will make this query to the root servers. There is no mechanism to control what/who sees what coming from you. Now imagine the following:

john-remote.house.com --> find: prototypes-of-new-revunue-generation.yourco.com --> DNS

You would not want this traversing through the Internet so you shove it into a conditional forward. Pseudocode:

if usersearch == specific_to_me
    then
       send him to this server ALL THE TIME
    else
       let him query root servers
fi

It can also reduce the amount of traffic coming in and out of your network. This coupled with the fact that, you can ensure no one has hijacked your DNS server to re-route, etc.

http://skibbz.com/how-forwarder-resolves-queries-between-internal-and-external-dns-server/
http://technet.microsoft.com/en-us/library/cc782142%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/cc757172%28v=ws.10%29.aspx


How is HTTP PUT and DELETE methods insecure, if they really are?

PUT and DELETE are not intrinsically insecure, they are used without problems at many REST services for example.

In my practice the main problem related to these HTTP verbs (apart from the common authentication and authorization problems) was that the server operators weren't aware of their existence introducing the possibility of HTTP Verb Tampering. In summary this means that access control was implemented based on a HTTP verb blacklist but some lesser known verbs were missing from this list allowing access control bypass.

I'd like to note that many web servers implement their own custom (sometimes undocumented) HTTP verbs, so this kind of "Verb-Based Access Control" doesn't seem like a very good idea anyway.


How to make TLS_RSA_WITH_3DES_EDE_CBC_SHA strong

If following that guide you used this line in your nginx configuration:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

You should replace that line with

ssl_ciphers '-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES';

then restart nginx and try the Qualys test again (click on clear cache on the Qualys test page if necessary). You can compare the results for the simulated connections by different browsers and search engines to see that nothing changed except you lost the ability of Internet Explorer on Windows XP to connect. That is not a loss, it's completely insecure.

In the future, when you upgrade from Ubuntu 14.04 to a server OS that ships with a version of openssl that supports ChaCha20Poly1305, you'll wany to adjust the ssl_ciphers. This can be as soon as when Ubuntu 18.04 is released a year from now. You'll definitely need to adjust when you switch to Ed25519 certificates, which will take a few years (RSA 2048 certificates will probably be supported for a very long time, and Ed25519 will not become available for at least a year, but eventually everyone will upgrade).


Where is the first online reference to the "HeartBleed" bug?

Hackernews user eastdakota (probably Matthew Prince) is the CEO and co-founder of CloudFlare (according to the HN bio) and has publicly stated that:

  One of the individuals who discovered the [Heartbleed] bug contacted
  us as a large provider of SSL termination services. We were asked not
  to further disclose the details until it was officially patched and
  announced by OpenSSL. The official announcement occurred today after
  which we put up a post to let our customers know that they were
  protected.

And:

  ...we held the post informing our customers that they were protected
  from the bug until after it was officially announced by the
  organizations that had discovered it as well as by OpenSSL

And also:

  The bug was discovered by a researcher at Google and three engineers
  at Codenomicon.

Credits:

  The vulnerability was first reported to OpenSSL by Neel Mehta from
  Google Security. Matti Kamunen, Antti Karjalainen and Riku Hietamäki
  from Codenomicon Oy reported the vulnerability to NCSC-FI, who
  reported it in turn to OpenSSL. NCSC-FI would like to thank
  Codenomicon for reporting and analysing the vulnerability.

The heartbleed.com site is registered to Codenomicon

  Domain Name: HEARTBLEED.COM
  Registrar URL: http://www.godaddy.com
  Registrant Name: Marko Laakso
  Registrant Organization: Codenomicon Oy

So going from what Matthew has said, it appears that the first public disclosure was either the OpenSSL Security Advisory or heartbleed.com, and the rest is history.

The Cloudflare blog post is 21 hours old at the present time, with the Hackernews post now at 20 hours old, so the initial announcements from OpenSSL / heartbleed.com are probably not much older than that.

Edit: heartbleed.com now states:

OpenSSL Security Advisory (published 7th of April 2014, ~17:30 UTC)
Cloudflare Blog Entry (published 7th of April 2014, ~18:00 UTC)
heartbleed.com (published 7th of April 2014, ~19:00 UTC)


Remote System Administration of an Encryption-Switch-Encrypted Infrastructure

This is really a system administration question rather than security. However, I'm going to go ahead and attempt an answer. Most of Safenet's product's try to ensure a transparent form of encryption that the user doesn't notice. So, if it's encrypted storage the product performs the encryption just before it hits whatever integrated storage solution. If it's encrypted networking, they usually have two products (one for each side) that establish a tunnel and seemlessly move things through. Even the coprocessors are integrated with common libraries so you don't really have to modify some applications.

A proper setup with your storage using something like Storage Encryption product should cause no trouble. Your side of things should change little or not at all. They reiterate that in their datasheet:

"SafeNet StorageSecure offers a seamless, non-disruptive deployment that drops into the network between clients and servers, linking them with a high-speed cryptographic path. There are no hosts to configure or software to install. StorageSecure is ready to encrypt and secure storage transparently without any impact on user experience."


Is it safe and secured to use Mono-Project for Ubuntu to run a ASP.NET with a MySQL database?

One rule specialy true in software development is the simpler the better. Each time you add a complex system (OS, library, framework), you must wonder about its security level with 2 different points of view:

does the design present security problems? (typically how is the data hosted and accessed, how is authentication and authorization processed, what is the complexity of the configuration)
what is the risk that the system contains implementation flaws?

That second question is often hard to answer and is often not much than a bet but is important. As far as I am concerned I try to know what the reputation is, and look at the bug list for open source systems. Its size, the kind of bugs and time of resolution scheds some light on the risk of security flaws. The following is no more than my opinion:

Ubuntu is a serious OS, based on Debian Linux and has a pretty good reputation. Its configuration to obtain a standard server security level requires some work (it is by default a workstation system) but it is not much harder than Windows
Mono is a framework that port the NET API to the non Microsoft world. I am not an expert on it but I would be afraid that its developpers cared more for functionalities than security. You should examine the current bug list to make your own opinion. IMHO this is the key point for your question.

But using a correct underlying platform is far from being enough to build a secure web application. Many problems can come (and often do) from the way the application itself is designed and implemented. And anyway, I must secure it really shows that you are concerned with security which is a good start point, but best practices recommend to do a true security analysis:

what are the threats
what are the current weaknesses
what are the security requirements

Only the anwsers to those question will allow you to secure the application according to its requirement.


Store the private key for an S/MIME certificate from Digicert on a Yubikey.

You need to download Yubikey PIV Manager https://developers.yubico.com/yubikey-piv-manager/ that allows storing the certificate to Yubikey.

A nice walktrough for some email clients (but not for Outlook): https://blog.ligos.net/2017-01-02/Smime-Email-and-Yubikey.html


The first one uses randomly generated CSRF tokens which uses a cryptographic strong random generator to generate the token.

This is ideal. In this case, the token is an absolutely unpredictable opaque block with no significance outside its intended context.

  The second implementation I found uses HMAC which encrypts the session id with
  secret key stored in the server side config.

This is simpler to implement. Presumably session IDs are already being generated, so nothing additional needs to be persisted. Since no further storage is necessary, it could be that this mechanism may be implementable in situations where a random token couldn't be worked in to a legacy design. This is a relatively elegant workaround. Assuming the secret key doesn't become known to the attacker, the token shouldn't be reproducible outside the server.

  The third implentation I saw uses a combination of both, a secret key stored in the server side config is used to HMAC a random generated value

This is a little silly. Presumably driven by the fact that a an HMAC is a security-related concept, the author attempts to add security to his design by including something security-related. A sort of magic security talisman.  Presumably it's no worse than using the random number alone, but it's certainly no better. Unless you count the warm fuzzy feeling you get from using HMAC in your security implementation.

It is, however, a reasonable work-around if you have a poor RNG, though in that case I would probably mix the session ID or something similar in there before hashing so that you're guaranteed that the number you hash in unique.


Heap spray against 64-bit processes - possible?

First, a small clarification: Classic heap sprays never needed to fill the entire virtual address anyway.  They only needed to fill enough of memory to cover the range of uncertainty you have for the address of whether the shellcode will be.  Thus, 100MB or so were enough.

The picture changed a lot with the advent of DEP, because one can no longer spray shellcode; now one must spray a ROP stack (for instance).  You might think that ASLR also made heap spraying harder, but VirtualAlloc allocates at deterministic addresses even if ASLR is enabled (maybe it still does), which made predicting the address a lot easier.  Finally, the 64-bit address space increased the amount of variability available to ASLR, which has the potential to make some heap spray attacks harder.

The biggest change is found in Windows 8, which made two major changes that will likely make heap sprays more challenging.  First, HiASLR enables greater entropy for ASLR.  On 64-bit platforms, HiASLR introduces a 1TB range of possibilities for the base of the heap.  This makes it harder to predict the address of something on the heap.  Second, Windows 8 makes allocations non-deterministic: when you allocate a object using the default allocator, the position that is used is randomized (it is no longer deterministic), introducing fine-grained randomization at the individual object level.  Object-by-object randomization is not used for everything (only for the LFH allocator, which I think is only used for heap objects that are at most 16KB in size), but it will add an additional challenge.

That said, heap spraying may still be possible in some cases.  The situation where heap spraying becomes useful is where we have partial knowledge of a pointer value (or where some object will be in memory), but not exact knowledge.  In that situation, a heap spray can still be a useful technique to make the exploit reliable despite the lack of perfect predictability in that address.

For instance, one example is Ivan Fratric's exploit of 64-bit IE11, where he used a heap spray to make the exploit reliable.  In that vulnerability, the attacker could trigger a write to address A+256MB, where A is the address of some heap object.  Due to ASLR, we can't predict the value of A, and due to the 64-bit heap, we can't spray enough to fill all of the heap -- but Ivan noticed that in this case it is enough to spray around 256MB of data into the heap.  This makes it likely that the address of a random heap object, plus 256MB, will land into the sprayed region.

So, as Ivan Frartic explains, heap spraying can still be useful for the attacker if "we can make a vulnerable application dereference memory at a valid heap address + a large offset" (for instance, imagine the buggy code do_something_with(a[i]), where i might be a offset that points past the end of the array).  He gives another example of an earlier vulnerability that also had this form, to illustrate that this case is common enough.

Finally, 32-bit processes might be used in cases you wouldn't expect.  For instance, even 64-bit IE on 64-bit platforms will use 32-bit child processes for each new tab, on Windows 8.1.  Who knew?

Bottom line: No, we can't say that there's no need to worry about heap sprays against 64-bit processes.  That was indeed too naive.


Full disk encryption vs home folder encryption - why should the former be chosen over the latter

I recommend Full Disk Encryption everywhere. Home folder encryption will cover a lot, but there are a few points missing:

Data outside of home

Some programs will write things on /tmp, log files are going to /var/log, swap will contain sensitive data. Those directories are outside of your home, and will not be protected.
Protection against tampering

I think this is the most important. If your computer breaks down for any reason, and you must send it to repairs, your home is protected, your system isn't. It will be trivial to replace binaries, or put backdoors in place.
Protect login password, WiFi passwords, and databases

The same support technician  can copy /etc/shadow, all data from NetworkManager, anything on /var/lib/mysql, and so on. With full disk encryption, nothing can be copied.


What's the point of the second SA exchange in the Create_Child_SA exchange in IPsec

During IKE_SA_INIT you negotiate cryptographic algorithms which I assume (correct me if I am wrong) are very similar to a TLS cipher suite (symmetric crypto algorithm and a hash function). You also do a Diffie-Hellman exchange which I assume is not specified in the SAi1/SAr1 because you always do DH in IKEv2.

Yes, they are similar. But there are no fixed cipher suites in IKE (i.e. algorithms of different transform types may freely be combined in a proposal - with some exceptions, like not negotiating integrity algorithms when AEAD mode ciphers are proposed).

The DH group is also negotiated with SA payloads (transform type 4), even though the initiator already sends a KE payload with its public DH value for a specific group. So if the initiator proposes more than one DH group it has to assume which group the responder might select (the responder could, of course, use the KE payload as strong suggestion towards the group that should be selected, but it might prefer it's own configuration or not even support the proposed group). If the initiator's guess was wrong and the responder selects a different DH group it will respond with an INVALID_KE_PAYLOAD notify containing the selected group. The initiator then has to send another IKE_SA_INIT request with an appropriately updated KE payload (and possibly an updated SA payload).

  What I dont get why you would want to negotiate cipher suites again. RFC 7293 tells me that

    All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.

  so what's the point of the SA offers in the CREATE_CHILD_SA request?

That quote is referring to IKE traffic, which is encrypted after key material has been established with the DH exchange during IKE_SA_INIT. But to transport traffic via IPsec it's necessary to negotiate actual IPsec/Child SAs within the IKE SA. The algorithms used for IKE and Child SAs may be different, actually, every negotiated Child SA could theoretically use different algorithms (that may usually not be the case, but using different algorithms for IKE and Child SAs is definitely common, e.g. AES-GCM for IPsec and AES/SHA-2 for IKE). That's why algorithms are negotiated in CREATE_CHILD_SA exchanges.

The CREATE_CHILD_SA exchange is also used to rekey IKE and Child SAs, and while different algorithms could theoretically be negotiated then (basically a new SA is created to replace the existing one) RFC 7296, section 2.8 discourages this:

  Note that, when rekeying, the new
     Child SA SHOULD NOT have different Traffic Selectors and algorithms
     than the old one.

Please also note that, unless RFC 6023 is implemented, a first Child SA is already created with the IKE_AUTH exchange. The algorithms used for this SA are negotiated with SA payloads during IKE_AUTH (SAi2/SAr2 in RFC 7296). However, because there is no separate DH exchange for it (the keys for this SA are always derived from the IKE key material), no DH groups will be negotiated, RFC 7296, section 1.2:

  Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
     Thus, the SA payloads in the IKE_AUTH exchange cannot contain
     Transform Type 4 (Diffie-Hellman group) with any value other than
     NONE.  Implementations SHOULD omit the whole transform substructure
     instead of sending value NONE.

If that Child SA is later rekeyed, a DH group may optionally be negotiated to establish new key material that's independent of the IKE key material. Because no DH transforms were contained in the initial SA payloads used for this Child SA, configuration errors regarding DH groups for this Child SA may only be detected when it is first rekeyed and fails.


Understanding CSRF vulnerability in Web Application?

I suggest that you read the OWASP references on this topic, including:

Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
Testing for CSRF (OWASP-SM-005)
Reviewing code for Cross-Site Request Forgery issues

as well as the following resources:

OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF)
OWASP Top 10 Deeper Dive – A5: Cross-Site Request Forgery (CSRF)

In general, if you have questions about web security and secure web development, a good starting point is to look at what resources OWASP has available.


Yes, they can.

Based on network topology, your protected network should be connected as far away from the Internet as possible. By allowing router Y to be directly connected to router X, all the wireless clients need to do would be to run a trace route, and then they will find out that they are actually connected to your corporate network.

You can try to remedy this by reversing the position of X and Y in the network, so that the wireless clients are connected to the outermost network whilst your business network is in the innermost layer, eg.

Internet -> Router Y (wireless) -> Router X (business)

Or, you can keep the same configuration that you mentioned, but place router Y in the DMZ of router X. The DMZ should limit the wireless clients on router Y from connecting to the business network of router X.


Impact of the response content-type on the exploitability of XSS

My question is if the Content-Type header in the response has an impact on the exploitability of XSS and possibly other vulnerabilities?

Yes, the content type makes a difference. XSS only applies to documents that are capable of running active (script) content in the first place.

A page with the MIME type application/json can't contain active content. To the browser it's just data. The situation would be similar with text/plain, text/javascript, image/jpeg, etc.

XSS would be possible with a MIME type of e.g. text/html, image/svg+xml, text/xml and many others. In some cases, vendor-related types such as application/x-shockwave-flash may have an XSS potential, too.


vulnserver - Can't find JMP ESP in ntdll.dll

There are a few executable modules in your screenshot. In your case, nttdll.dll doesn't has JMP ESP instruction.
The right tool for this is mona.py

mona.py is a tool written in Python and available with Immunity
Debugger that helps finding a reliable JMP ESP instruction.

https://www.whitelist1.com/2016/11/xstack-overflow-1-exploiting-slmail.html
To find all addresses with JMP ESP, use !mona jmp -r esp command.
This command will search in the loaded executable modules for a memory address that has JMP ESP.
https://medium.com/@johntroony/a-practical-overview-of-stack-based-buffer-overflow-7572eaaa4982


What you are trying to do is a great challenge and currently isn't possible.  There has been some discussion about using TPMs to provide a vendor locked trusted environment that could be used as the basis of such a system, but the problem currently is that an untrusted system can not prove itself trustworthy since any inspection a trusted system could do could be faked.  You have to have some trusted subsystem on the client that can do the validation actively.  When all you have is a request from the client, you lack the access and level of trust necessary to achieve your goal.


Why do you want to run https to localhost anyway? There's no point in it.
TLS is meant to guarantee confidentiality, integrity, and authenticity of the connection against an attacker living on the network path between you and the server, but if you're connecting to localhost, there IS nothing between you and the server.
CA's won't issue a certificate to localhost, a certificate embedded in your desktop app can be easily reverse engineered and stolen, and a self-signed certificate is as good for security as none at all.
Just use plain http to localhost.
If you're worried that browsers will spook at you for "mixed content" or something, don't worry—modern browsers (at least I'm pretty sure Firefox does) treat localhost as secure regardless of how you connect to it.


on which layer do the interception happens using the proxy tools like burp, either in application layer or network layer?

So this looks like two questions; 1. which OSI layer do tools like burp suite work on, and 2. is it an issue if information is in the clear in a proxy tool but not in a raw capture from wireshark.

Proxies like burp operate on OSI layer 7 (application) which allows them to understand HTTP, and traffic must be directed to them by configuring the client application.
Burp is doing an MiTM attack on the encryption as you are routing traffic through it, wireshark on the other hand is just capturing the raw traffic and does not has enough information to allow it to decrypt the traffic (by default), so nothing to worry about so long as it's encrypted in wireshark.


Vulnerability Scanning as a Point of Compromise

Mitigating the risk of having a scanning system with credentials in the environment can be accomplished with the following best practices:

Use a dedicated system for scanning and disable it (disable NIC / power it off) when not in use.
Use dedicated credentials (AD preferably or local if necessary) for the scanner and disable them when not in use.
Rotate passwords for the scanner's credentials periodically.
Ensure scanner's version and host OS are current with patching and updating.

UPDATE

For the extremely paranoid, we can implement the following controls:

Restrict access to this box (SSH, RDP, Scanner Web Interface, etc) to only authorized machines.
Enable detailed logging of the host & scanning application then review the logs for anomalous activity.
Connect this box to any SIEM solution currently in the environment and configure alerting on any access to the system while it's powered up / online.


Tips if someone else is using "my" username on another site

I would merely take this the other way around: instead of telling people about pages not linking to you, I would merely concentrate on the pages actually linking to you.

Just display a list of official contact pages, everything else will be then assumed to be not you:

Official contacts:

Main website: ...
Blog: ...
Twitter: ...
Facebook: ...

Etc.

As per your recent edit, "I wan't to send the complainers to a page that politely explains why they don't own their own username", this seems to me more likely a law-related question than IT-Security which should most probably find better answer on SE's Law specific website.


"Malware" is a general term for all categories of harmful software, including software that doesn't try to spread itself, but only does things that the user would rather it didn't.

A "worm" is a self-propagating program that can spread without outside help.  An example would be a program that looks for an unsecured SSH server, uploads itself, and then runs itself on the newly-infected system.

A "virus" is not self-propagating.  Instead, it piggybacks on another program, only executing when the infected program is run.  An example would be a program that runs on a computer, looking for USB thumb drives; when it finds one, it modifies every program on that drive to contain a copy of itself.

Email, the Internet, and the design of modern operating systems makes the boundary between "worm" and "virus" a bit fuzzy.  Is a program that depends on a bug to add its code to an already-running program for initial infection, but runs on its own afterwards, a worm or a virus?


What is the safest way to identify a device without human action please?

I'm not sure if your suggestion of push notification is really going to help.  For that to work the client still has to "subscribe" itself to the push notifications.  What would stop a MITM from intercepting the end-client's request to subscribe to push notifications and subscribe itself instead?

The internet is inherently built around the concept of "anonymous" clients initializing conversations with servers.  It is possible for a client to uniquely identify a server via SSL certificate validation, but nothing about the internet is really designed to do the opposite.

What it really boils down to is that if doing what you wanted to do was easy and fool-proof, then every server everywhere would do it and stolen credentials would be a thing of the past.  That obviously isn't the case though.


The benifits of Full NAC solution VS simple radius server

The solution of NAC basic use two features. Posture and Profilling.

In the case of not using Host Checker(Agent) you are "losing" posture features - check patchs, av, registry and otheres stuff.

Using only a radius server you are "losing" the profilling of the endpoint.
This may have huge impact - that depends of the size of your network.

If its a small network, withou many kinds of endpoints - Notebooks, Cellphones, cams etc. I should be ok.

But if you have a medium large network it s going to be difficult to manage and control all kinds of endpoints. That exactily what profilling do for you.


Is there a stream cipher equivalent when using RSA key pairs?

First of all, basically nobody encrypts messages directly with asymmetric primitives.  Instead, in practice asymmetric cryptography is used for key encapsulation or for key exchange.

But to answer your question, the standard RSA-only encryption algorithm is RSA-OAEP, which involves randomizing the encryption (the values r and Y in the explanation in that page).  So encrypting the same input block twice does not produce the same output, which avoids the ECB problem.


If an input field accepts <% data then how can one say there is risk of stored XSS

No, printing <% in an HTML context doesn't make it vulnerable to XSS.

For an XSS attack you need to allow a letter after the opening bracket, as has also been discussed here. Starting with <% alone, you cannot construct an HTML payload. That said, it's a little suspicious that the XSS filter didn't go the whole way and filtered opening brackets followed by any character.

(Possibly, the auditors are worried about other attack vectors via embedded ASP code blocks but that's not related to XSS at all.)


Replacing windows shell for everybody but the system administrator

It seems like you're going about this the wrong way round, instead of mucking around with vaguely documented registry keys, I think you'd be better off just defining a proper GPO (group policy object).
I dont have an environment handy to verify this, but I assume its possible to define a custom shell according to the user's group...


Why do browsers not reliable block pop-ups?

As a long-term webdev, I've seen this evolve from IE6. This is all by design and consideration actually. Legitimate user-desired actions are not to be blocked. Many corporate portals use popups, as do web-based email, messaging, media players, and more. To developers, "Popups" and "popunders" are unintended and unexpected sub-window openings to be exact. If a site launches a popup, it's because you did something.

The rules for FireFox, Chrome, and Safari are identical: if the popup happens as a result of a user action, like a click or keyboard press, it's allowed. If the popup happens on it's own, it's blocked.

How does the browser determine what caused the action? JavaScript has a way to trace the caller of event-handling function(s) and sub-functions all the way back to a physical user action, like a click. If it doesn't find such a caller on the call stack of the popup-launching code, the popup is blocked. Developers generally cannot extend the user-initiated action until later, you have to window.open() right away, or else it's blocked. Extensions can block whatever they want, regardless of the user intent, or lack thereof. Links/forms with target=_blank only fire as a result of user-action, so they need not even be audited.


There are several aspects of security and which one is more secure for you depends on your environment and requirements:

If you have a problem with leaving the mails at a server you don't control: Both POP and IMAP can leave the mails on the server but can also delete the from the server. But usually IMAP is used in a way to leave them at the server while POP is used to just get and delete them from the server. Not that in both cases the mails are still at least for some time at the server, so if you don't trust the server at all you've lost anyway.
If you care about encrypted transport to defend against man in the middle: Both have the option to use TLS.
If you care risks introduced by the implementation of the protocol in server or client: IMAP is a way more complex protocol than POP and thus the risks of an insecure implementation are much higher there.
If you care about data loss:The servers of the providers are usually better maintained than a desktop system, i.e. professional providers have redundancy, backups etc. So leaving the data at the server (usually with IMAP) might be an advantage.
If you want some firewall in between to scan the messages for malware: POP is the more simple protocol to implement in firewalls too. It is only used to retrieve full messages (or maybe the header only) while IMAP can be used to only retrieve a specific part of the message like the body data of a specific attachment or even a specific byte range. This feature is especially used when mobile clients are used which try to reduce bandwidth use by only loading attachments on demand. But even the Thunderbird mail client on desktops transfers by default large message in multiple chunks. This behavior makes it much harder for firewalls to inspect IMAP traffic because they might miss essential context like the Content-Transfer-Encoding or the filename of the attachment or the previous chunk of a message which are needed for proper scanning. See for example the section Understanding IMAP Antivirus Scanning Limitations in the description of IMAP scanning in Juniper products and many other firewalls have similar limitations (but often don't document these) or even do not support IMAP at all.


The guide isn't very good. More of a quick guide and it assumes a significant amount.

First assumption is that you know to run a console as root to actually do the installation and configuration. The result of that should be that the configuration files are not public but rather all belong to root or a separate OpenVPN limited user (sorry, I can't remember which off the top of my head).

Therefore, normal (non-admin) users of the box should not have access to the sensitive files. But don't forget that any computer where people have unrestricted physical access cannot really be fully trusted.

Furthermore, using a service like VPNbook, you are putting a lot of trust in the service. You can never really know what happens at the other end of the VPN. Remember that the traffic is only encrypted between your PC and some terminating computer at the other end. After that, anyone with system level access can read anything. Don't assume either that this would protect you from being traced online, it will not.

A more secure setup requires you to control the other end of the VPN and to control every aspect of the PC.

At @Phillipp commented, you need to give us more information about what your security concerns are for us to be able to comment further.


Does an HTTPS proxy encrypt traffic between proxy client and server for HTTP requests?

It may be simpler to see it in stages. First, in a whole-HTTP world (no SSL whatsoever), an HTTP request is a collection of headers, indicating the target URL, and sent over a TCP connection (usually on port 80). The request headers begin with a "verb" which is usually GET or POST.

When there is a proxy, the request is sent to the proxy; the proxy then opens the connection to the target server (or another proxy) and forwards the request over that new connection. The response follows the same path, backwards.

Now enters SSL. SSL is coupled with HTTP in the following way: once the TCP connection is established, a SSL handshake is performed, establishing an encrypted tunnel between client and server. The HTTP request will be sent within this tunnel.

When there is a proxy, a client wishing to talk to a SSL-powered server will send a CONNECT request. The request identifies the target server name and port. The proxy then connects to that server (TCP) and forwards bytes back and forth. The SSL handshake occurs between the client and the server; the proxy is kept "on the outside". The proxy (and eavesdroppers on the line between client and proxy, and between proxy and server) can still see the handshake message and thus know what server is being contacted (in particular through the Server Name Indication, and also the certificate sent back by the server).

It so happens that the proxy itself may also be a SSL server. In that case, the communications between the client and the proxy will be themselves encapsulated in a SSL tunnel. When the client-to-proxy connection is SSL-protected, eavesdroppers on the line between client and proxy can know that the client is talking to the proxy, but cannot see the requests and responses. In particular, they cannot know the identity of the ultimate target server.

The two SSL are uncorrelated. This implies some considerable confusion, because when people say "HTTPS proxy", they may mean two different things:

a proxy which knows the "CONNECT" verb and is able to forward connections to a ultimate SSL-powered target server;
a proxy which is itself a SSL server and will engage in SSL with the client, to protect requests and responses when they transit between client and proxy.

The two characteristics are orthogonal to each other, meaning that you may get one, the other, or both. If you have both then the client actually manages two SSL connections, one nested into the other.

If you want to defeat eavesdroppers on the line between client and proxy, and the goal of the attackers is to guess the identity of the sites that you are talking to, then you need a SSL-powered proxy, i.e. one that supports SSL by itself; and you will also want a proxy which supports CONNECT, so that you may browse both HTTP and HTTPS Web site under protection of your SSL-powered proxy.

Since a given proxy may or may not support a specific protocol (at least conceptually, a proxy may refuse to understand a "CONNECT" request), Web browsers can be configured to use different proxies based on the kind of protocol they want to use. In your case, this only adds to the confusion.

An alternative is to use a SOCKS proxy. This is easy to setup with SSH. With a SSH-powered SOCKS proxy, all the communications emanating from your browser will go through a SSH tunnel between your client machine and the proxy server.


As @Lighty said, the IMEI is a unique identifier for your phone (not the SIM card though, that would be the IMSI).

You can think of it as an equivalent to a MAC address in Ethernet. The IMEI could be spoofed to impersonate you / your phone. Your phone could get traced in a network using the IMEI (It actually is to maintain your connection). The IMEI is also used to find stolen phones, by comparing it to the IMEI DB of the GSM Alliance, for example.

Thus, to protect your idendity, and limit tracing to legitimate usages, it may well be worth it to not spread the IMEI out in public.


Unfortunately (for you), computers are deterministic systems. What a computer can compute, it can compute -- and it can do so at a speed which depends quite heavily on the computer model. This means that you cannot enforce an exact timing without external events: without extra input, a computer is an isolated system and can reach any computable conclusion from the available data at a speed which will depend, roughly, on its price.

So you need a reliable clock somewhere in your system. When you envision publishing a decryption password, then you are the clock. Using encryption is a good idea since encryption concentrates secrets: instead of having to deal with 100 megabytes of data, you just have to publish a small size value (the decryption key), which can be small enough to be typed manually by a human or even uttered over a phone call.

At that point, you have a choice, which is where the clock is:

The clock could be in the physical hands of each customer. This calls for a tamper-resistant device which can store a key, includes a clock, and can perform some computations over both. This page pretends that the "VaultIC" line of USB tokens includes a real-time clock and can implement the TOTP generator for time-based passwords, so it has the needed potential. Some specific on-board programming would still be needed, though, to match your needs.
The clock is not in the physical hands of each customer. Instead, they must contact someone (e.g. you) (or be contacted) at the publication time. There are various ways to convey information in our modern world: Internet-based (Web, emails...), phone calls, SMS, radio... The idea here is that if customers cannot be expected to always have Internet access at the right time, they must have a link with the external world. If one of your customers is a Buddhist monk who lives as an hermit in a cave on the flank of an Himalayan mountain and goes to the nearest village only once a month, then that customer will be hard to reach; but, similarly, it does not matter much that he gets the embargoed information immediately since he does not have any contact with anybody -- such information is useless to him until his next contact with civilization.

Publishing the decryption password on your Web site and sending it by email to the customers and sending it by SMS to the customers, ought to be sufficient. Customers who cannot be reached by any of these means are decidedly away from the connected World, and therefore can wait.


Well here is how I ended up implementing CSRF:

On the first request, sets a CSRF token as a cookie. Every subsequent AJAX requests include the CSRF token as a X-CSRF-Token HTTP header.

Django has some nice documentation on how to do this cleanly with jQuery: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/

Edit: An alternative approach whitelists requests that contain the X-Requested-With header. It seems that's what Rails does. But as @damio pointed out below, the X-Requested-With is a security hazard, Django and Rails reverted back to not using it and forcing a token.


There is no evidence that Apple has ever installed a hardware keylogger into any of their products. I can find no reference to such a feature or option existing or being advertised, either for consumer or commercial purposes. Further, it seems highly unlikely that a hardware vendor would embark on such an ethically questionable course of action against their own products and customers; it would reflect exceedingly poorly upon them.

This is not to say that a company could not have installed keylogging software after they received the laptop. However, I find it hard to believe that they would install a hardware keylogger - for a start, modern MacBooks are difficult to disassemble without damage. In this situation, formatting the disk and re-installing the OS should be sufficient to ensure that the device is clean.

DEP is a confusing acronym here; I suggest against using it as for 99% of cases it refers to Data Execution Prevention, which is an exploit mitigation in most operating systems. I'll assume that you're referring too Apple Device Enrolment Program.

ADEP is a mobile device management (MDM) solution. Organisations can indeed use it to deploy any software they like to their devices. If you re-install the operating system, however, the ADEP settings and deployed software packages are not carried over and the enrolment stops working for that device.


Is nonce of HMAC secured message considered secret?

NIST (National Institute of Standards in Technology) defines an nonce as a time varying, non-repeating value to help prevent 'replay attacks.

The nonce doesn't necessarily have to be secret but should be a random sourced non-repeating value used in block ciphers for symmetric and asymmetric encryption.

Please reference NIST SP 800 series of documentation for additions details of best practices, implementation & reasons for use.


Public part of SSH key (*.pub): Keep or destroy?

The whole point of your public key is that you can share it with anyone. It doesn't matter if someone gets it, it doesn't matter if it's on your machine.

It isn't a target for attackers so it would be of no value to anyone in having it on your machine. It does have a benefit in keeping it: you can then easily share it.

(Yes, I know there is a possible attack vector if an attacker had the public key and had a way to impersonate the server you are trying to connect to, but if they are prepared to do that you have greater issues)


Why is Norton Safe Web flagging my site as dangerous when it reports on PHP files/urls that don't exist?

This is a Norton Security/Safeweb false positive. Their threat scanning engine is flawed when handling reponses from these 'hacked' URLs, which in vulnerable systems can do damage. The problem is that they interpret the response incorrectly, so sites that have no PHP/WordPress etc get flagged in error.  This is hugely damaging to customer goodwill of course. And they do not make it easy or fast to dispute. Additionally, they do not notify the domain holder (in our experience at least), so often the first to report is from a customer. In our case, it was a prospective customer who first reported the problem. They did not buy a website from from us due to this false warning, and the delay in getting it resolved.

It is not your site per se, but rather the response that the site returns to what is essentially a bad URI. If they get anything other than a hard 404 response, they take that to mean the URL is valid, and therefore a vulnerability.

My guess is that your firewall returned a 301 redirect to the initial request, which shows(redirects to) the file not found page.  This is called a soft 404. A common way to download a file is via a 301 redirect, so this raises a red flag to the scanner.

You need to make sure the actual response is a hard 404 in these cases. If not, the Norton threat scanner assumes the URL found the vulnerable file/page, and you get flagged.


When you create random numbers, you need to ask yourself what those random numbers are for.

For example, if you wrote a first person shooter and wanted to generate some random bullet spread, then the randomness doesn't need to be of high entropy or uniformly distributed, as long as it's "good enough" for the game.

On the other hand, if you were to write code that serves some kind of cryptographic purpose, then the random numbers you use have to fulfill certain properties, depending on their exact purpose. Back in 2008, the Debian team had a huge bug in their OpenSSL package, causing the quality of the random numbers to decrease significantly. Ironically enough, this was all due to a code quality tool complaining.

What is a nonce?

You mentioned that you intend to use your random numbers as a nonce. It really depends on the exact purpose of the nonce, but a nonce should fulfill two properties:

It should only be used once, hence the name "nonce".
It should be impossible to predict.

The second property is really what your code is all about.

Why is System.Random not okay?

The System.Random class was designed to provide random-looking numbers quickly. These numbers are really not "high quality", and designed for something like a game, as I showed before.

An attacker, who is able to read enough random numbers generated by your system may be able to predict future numbers generated by the system. This may not be a problem in a game, but is very likely a problem if you look at your crypto code and imagine the attacker knowing all the nonces.

What to use instead?

The MSDN page for System.Random recommends using System.Security.Cryptography.RNGCryptoServiceProvider. As the name implies, it's designed to be used for cryptographic applications. Be aware if you are already using a third party crypto library, they may provide their own interface for generating secure random numbers, which may be more user-friendly and less prone to implementation errors.

Usually, when developers generate random numbers, they want them in a specific range, such as "Between 0 and 9999". This gives way to biasing errors, which, due to the way the modulo operator works, makes some values more likely than others.

But since all you care is unpredictability, you can make your life easy and generate a nonce in an easy-to-use size, which means just generating it byte-wise.

For example, the following code generates a nonce of the desired length:

private static RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();

public static byte[] GenerateNonce(uint nonceLength)
{
    byte[] nonce = new byte[nonceLength];

    rngCsp.GetBytes(nonce);

    return nonce;
}

Why is this code simpler than the others? Because the code you provided is designed to deal with the case I mentioned above, where biasing can be a problem. Since you can generate "nice" values, you will never have biasing issues and your code becomes much easier.

Is this nonce really secure? How long does it need to be?

Yes. Well, almost. An attacker can still guess the nonce and has a small chance of guessing it right. But it's the same as thinking of a number between 0 and 2^128-1 and not telling you what it is. You can still guess, but your chances of guessing it correctly are...small. Very small.

In fact, they become smaller the larger the nonce becomes. How long should a nonce be to make guessing infeasible? The general answer is it should have at least 80 bits of entropy, so 10 bytes at minimum. If you feel like you can deal with the overhead, you can go ahead and use 16 bytes (128 bits) and you should be good to go.


Can a CRL file contain multiple full stops in its name?

The standards for CRLs specify the format of the file itself, not the filename. I have never heard of any client having issues with multiple dots in the filename - so, as long as it doesn't contain characters that the OS/filesystem can't handle reliably, there shouldn't be any issue.

As a general recommendation, you should avoid spaces and special characters in CA names, including underscores, since there are some products out there that have problems with that. So if you want the CRLs to have filenames based on the CA name, you need to remember that when creating the CAs. I've not heard of periods being a problem, but as a rule I go with "CamelCaseCANames" instead of "no.camel.case.ca.name". But this is an issue with the CA name rather than with the CRL filename.


Not easily. This would amount to a known-plaintext attack on DES -- the "attacker" has access to a pair of ciphertext and plaintext, and is attempting to determine the key. DES is not a particularly strong cipher, but it is not considered to be especially vulnerable to this attack.