What key exchange mechanism should be used in TLS?

You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match. To see this in details, let's have a look at cipher suites defined in the TLS 1.2 specification. Each cipher suite defines the key exchange algorithm, as well as the subsequently used symmetric encryption and integrity check algorithms; we concentrate here on the key exchange part.

RSA: the key exchange works by encrypting a random value (chosen by the client) with the server public key. This requires that the server public key is an RSA key, and that the server certificate does not prohibit encryption (mainly through the "Key Usage" certificate extension: if that extension is present, it must include the "keyAgreement" flag).
DH_RSA: the key exchange is a static Diffie-Hellman: the server public key must be a Diffie-Hellman key; moreover, that certificate must have been issued by a Certification Authority which itself was using a RSA key (the CA key is the key which was used to sign the server certificate).
DH_DSS: like DH_RSA, except that the CA used a DSA key.
DHE_RSA: the key exchange is an ephemeral Diffie-Hellman: the server dynamically generates a DH public key and sends it to the client; the server also signs what it sends. For DHE_RSA, the server public key must be of type RSA, and its certificate must be appropriate for signatures (the Key Usage extension, if present, must include the digitalSignature flag).
DHE_DSS: like DHE_RSA, except that the server key has type DSA.
DH_anon: there is no server certificate. The server uses a Diffie-Hellman key that it may have dynamically generated. The "anon" cipher suites are vulnerable to impersonating attacks (including, but not limited to, the "Man in the Middle") since they lack any kind of server authentication. On a general basis, you shall not use an "anon" cipher suite.

Key exchange algorithms which use elliptic-curve cryptography are specified in another RFC and propose the following:

ECDH_ECDSA: like DH_DSA, but with elliptic curves: the server public key must be an ECDH key, in a certificate issued by a CA which itself was using an ECDSA public key.
ECDH_RSA: like ECDH_ECDSA, but the issuing CA has a RSA key.
ECDHE_ECDSA: the server sends a dynamically generated EC Diffie-Hellman key, and signs it with its own key, which must have type ECDSA. This is equivalent to DHE_DSS, but with elliptic curves for both the Diffie-Hellman part and the signature part.
ECDHE_RSA: like ECDHE_ECDSA, but the server public key is a RSA key, used for signing the ephemeral elliptic-curve Diffie-Hellman key.
ECDH_anon: an "anon" cipher suite, with dynamic elliptic-curve Diffie-Hellman.

So, what shall you choose, for a Web site ? Your main constraints are:

You want a cipher suite which is supported by most clients; in practice, this rules out elliptic curve cryptography (elliptic curves are mightily cool, but not well supported yet in the field -- consider that according to gs.statcounter, as of September 2011, 40% of client systems still use Windows XP, and almost 5% use IE 7.0).
You want a cipher suite which is compatible with your server key type and certificate. This, in turn, depends on what the CA accepts (the CA which sold you the certificate). 99.9% of the time, this means RSA. Everybody does RSA. Diffie-Hellman keys in certificates, and DSA signatures, used to be promoted by NIST (the US federal agency which deals with such matters) because there was a patent on RSA; but that patent expired in 2000. Diffie-Hellman (as part of certificates) is specified by ANSI X9.42, a standard which is not free (so opensource free-time developers are reluctant to implement it) and not all that clear either. So nobody really uses Diffie-Hellman in certificates. DSA is more widely supported (its defining standard is free and quite readable) but not to the point of being non-anecdotic when compared to RSA.
You do not want to use an "anon" suite because that's insecure against active attackers, and most client browsers have the "anon" suites deactivated by default.

So you choice is basically between "RSA" and "DHE_RSA". The latter may have a slightly higher computational cost, although you would need to have at least a few hundred new connections per second to actually see a difference (I insist on the "new": since TLS includes an abbreviated handshake which can build on the key exchange of a previous connection, the actual key exchange with asymmetric cryptography only occurs once per new client browser in the last minute). So, in practice, no measurable difference on the CPU load between RSA and DHE_RSA.

DHE_RSA offers something known as Perfect Forward Secrecy, a pompous name for the following property: if your server gets thoroughly hacked, to the point that the attacker obtains a copy of the server private key, then he will also be able to decrypt past TLS sessions (which he recorded) if these sessions used RSA, while he will not be able to do so if these sessions used DHE_RSA. In practice, if the attacker could steal your private key, then he probably could read the 10000 credit card numbers in your site database, so there is little reason why he should even bother recording and decrypting previous sessions because this would yield only a dozen extra numbers or so. PFS is mathematically elegant, but overhyped. If it still a nifty acronym and can make a great impression on the weakly-minded, as part of a well-thought public relations campaign.

Summary: use DHE_RSA.


Are there any vulnerability differences between real-time systems and non-real-time systems?

Generally, if something is wrong with a real-time system, it'll go wrong upon a trigger event occurring. For example, Knight Capital had a stock trading system which responded to specific circumstances by buying stocks - when the system was pushed out without testing, it spent all their money, causing price fluctuations and the company to go bankrupt.

As a result, system correctness testing is really important - whereas with a non-real-time system, there are often ways to compensate for issues (maybe you can revert the database and redo transactions if you find a mistake has been made), that's not always the case with real-time systems, especially those with a real-world impact.

Consider systems that control traffic lights, or fly-by-wire implementations in aeroplanes. In these systems, a flaw which isn't picked up in advance can cause injury or death, and, worse, can be triggered by an unforeseen situation - can your fly-by-wire system handle failure of the GPS satellite systems? What about the sudden appearance of a number of erroneous GPS signals from a malicious agent?

This means that development and testing of real-time systems tends to be much more stringent than for other software. It's not uncommon for vast swathes of safety case data to be produced, ensuring that any potential failures result in a safe state, which depends on the system in question: for Knight, it would have been a maximum spend, for example. For Boeing, it might be that the plane alerts human pilots to a requirement to take over. For a nuclear power plant, it might involve a controlled shut-down.


What is the best way to upload a file securely?

You can normally upload the file using standard HTTPS way, however, exposing application server for uploads is always very risky. Especially if the application server has a lot of libraries built-in and so on. So ideally:

Create dedicated Tomcat instance just for file uploads with minimum set of libraries
Enable HTTPS on it and disable HTTP, harden HTTPS settings so it's using only latest protocol versions
Create user certificate which is used to authorize user to connect to the server
Create the username and password for each user
Now you can upload via HTTPS to tomcat controller any file, you can make it by using binary form to not consume too much bandwidth
If you have more of the infrastructure, you can use HTTPS -> HTTP proxy, e.g. in AWS, this makes things easier

On top of that, you can encrypt the file itself. If it's .NET application, it could be dedicated (per app instance, e.g. per customer) pre-shared symmetric key which is not stored on the destination server, so the file is copied from the upload Tomcat instance to another, isolated instance where it is decrypted.
Regarding pre-shared keys, it's not the best way, so you can use another Tomcat instance as Key Server. Having client certificate already, you can connect to Key Tomcat Instance and request one-time symmetric key, and the decrypting Tomcat Instance will re-request this key during decryption.

You can bypass the extra upload server if you trust your Main Tomcat. However, using HTTPS and Key Server with encryption is really recommended if upload needs to be secure. Also, the stored file might remain encrypted and the Main Tomcat server might not need / be able to query the Key Server at all.

This way, if your upload server gets compromised, the files are unreadable. If your key server gets compromised, the files are not readable either. Reducing the attack surface is the main thing. Use cheap Tomcat hosting to achieve that. Use JRE8 with G1GC to reduce memory usage. Use streams and don't load files into RAM.

See the diagram:


I store my passwordstore.org data in the cloud. Are my passwords safe?

Pass leaks the names of the entries: if your password is named web/site.com, it will be stored in the file ~/.password-store/web/site.com.gpg, and in the git repository it will just be web/site.com.gpg.

So anyone with access to your repo (in your case: github) is going be able to see the name of your passwords. This is not so great for privacy: say there is a file named web/pornhub.com.gpg, this might give a hint about your browsing habits ;)

Moreover, the size of the files might also gives a clue about which accounts might have small passwords. If a file is very small, chances are that your password is small too. An attacker could use this information to select which account of yours is most likely to have a weak password.


End-to-End (Point-to-Point?) Email encryption

You may also want to look at this question, which also touches on the subject.

  I understand that an SSL / TLS certificate, verified by a public CA,
  will enable transport security on SMTP between servers. However, I
  don't see how this could help with transport security between the
  server and a client. At best, it seems like the client's outgoing mail
  would be encrypted, but incoming mail would be in the clear. Am I
  understanding this wrong or is that a separate solution for that?

All of the client mail access methods - basically POP3, IMAP, and webmail - support secure alternatives.  POP3 and IMAP can either be run on a dedicated SSL port (just like an HTTPS server, traditionally POP3S is on port 995 and IMAPS is on port 993) or they can support STARTTLS which allows a client to connect to the default plain-text port and then negotiate with the server to switch to encryption first thing in the session.

With mail servers like POP/IMAP/Webmail you can insist upon encryption - if you configure the server correctly, it will refuse to authenticate or share mail before encryption is in place with the client.

  I also understand that the SSL certificate would not secure
  transmission between the far-end server and any of its clients. For
  that S/MIME or PGP is required (I'm not at all interested in PGP.) but
  my clients do need to be able to communicate publicly, so I'm resigned
  to that part.

You are correct.  Because SMTP encryption is opportunistic rather than required, and because mail may pass through multiple servers not controlled by you, the only way to be sure the mail is encrypted through the entire path is client-based encryption like PGP or S/MIME.

  That being said, I am attracted to the idea of running S/MIME strictly
  between my server and my clients. Is that possible? Can the server
  encrypt run S/MIME for all mail to/from internal users, but not run
  S/MIME for outbound public mail? Simultaneously can it accept
  unencrypted public mail and apply S/MIME encryption for the final
  delivery to the internal user? I know that seems convoluted, but I'm
  asking as much out of curiosity as for practical reasons.

It is possible to do this but it has little advantage over simply using an encrypted client access protocol, and would be harder to set up (e.g., it's not a config switch on an existing mail server).

You could have your mail server S/MIME-encrypt your mail as it arrives and before it stuffs it in your mailbox.  Then the mail would need to be decrypted on the client in order to read it.  However, if you did this and still used a plaintext mail access protocol, then your email credentials would be sent in plaintext* over the network, which could allow someone to copy your (encrypted) email, to delete your email, to send mail as if they were you... in short, you want to encrypt that client access protocol, even if you're thinking of enforcing S/MIME on top of your email.

The sole advantage that I can see of encrypting your email with S/MIME as it arrives is that the mail will sit encrypted on the server, and not be vulnerable to being read by an attacker who gains control of your server.  (That only protects your back traffic; any new mail arriving could be snooped before your server manages to S/MIME it if the attacker is on the system).

  Is it a viable combination to use SSL / TLS certificates and S/MIME,
  or does one invalidate the other?

You could layer server-imposed S/MIME on top of encrypted client access protocols; neither invalidates the other.  You will want encrypted client access either way to protect credentials.  S/MIME will provide additional on-server (in-storage) protection which encrypted POP/IMAP/Webmail alone will not.

  Can anybody suggest a best-practice
  for a start-up business situation? I would like to be able to deliver
  a solution in which it is secure to transmit trade secrets over this
  email server between internal users, at the very least.

Encrypt your client access protocol, and don't worry about S/MIME.  Here's why:

You absolutely need to encrypt client access, for credentials* if not for email.
S/MIME that you introduce at your server introduces key management issues.  When Dave in Sales leaves, and you don't have a copy of his key, then all his email to your customers is suddenly unreachable.  Are you going to do key escrow?  Encrypt with dual keys?  You're going to introduce usability and availability headaches if you add S/MIME, and you won't even be protecting your end-to-end like you should get out of S/MIME.
Server-imposed S/MIME is only useful if your mail server gets compromised.  In all likelihood, if your mail server gets compromised, having your mail be encrypted is only one of a large number of problems in your lap.  It's kind of like having the deck chairs properly arranged on the Titanic.  Bear in mind that most compromises are not discovered for months - an attacker could watch your new email as it comes and goes; not having access to the email that was there before the compromise is not a game-changer for him.

Now, some of that may differ based on the business you're in.  If all your business proposition is tied up in mail messages, well, maybe that extra layer becomes worth it.  But standard business, best practices, probably not worth it.

* There are, in fact, some client login methods which effectively encrypt the credentials.  Generally they will require the server have a plaintext copy of the user's password, which is bad.  And support for the different methods may vary while every client/server pair will support LOGIN or PLAIN.  As a result, the vast majority of email client access servers encrypt the session and use the plaintext LOGIN or PLAIN password methods.


Can apps be trusted when requesting your credentials?

No. In modern applications and web applications users have become numb to the requests for username, password, and various other innocuous details. The commonality has led users to believe that these information nibblets are useful to the application. However, this is wrong. With rare exception, authentication is unnecessary to application function.

In fact I believe application use of authentication is detrimental to the user. It makes authentication too common, making users less prudent and careful in cases where authentication is needed. It structures the identity space making it easier for attackers to guess your identity. It simplifies the keyspace making it easier for attackers to find your keys. It dampens operation security and degrades security practice for assets with value.

  Isn't this effectively the same as handling the password to the developers of said app?

Yes, with rare exceptions. Even in cases where the protocol is not directly delivering the password to the application or developer, but is instead delivering an authentication token, the potential for misuse and abuse is high. Even OAuth has vulnerabilities 'This protocol makes no attempt to verify the authenticity of the server.'.

  Isn't this an extremely efficient method of gathering passwords and a terrible security risk for users?

Yes, even when it is unintentional, poorly designed authentication schemes can provide a wealth of information for attackers. Even if the username and password you use for a typical application is not the same as the username and password you use for more important assets, the patterns you use help attackers narrow in on the valuable authentication. In contrast, well designed protocols like OAuth have a bright side: they reduce the number of pairs of usernames and passwords, as well as the number poorly design, poorly implemented authentication interfaces.

However, we also need to look at the OAuth service providers: Google, Yahoo, and Facebook. These are companies with an interest in collecting and aggregating information about users specifically to make money from that information. Using these companies as authentication providers is in part a bizarre contortion of trust. You are trusting these companies to handle authentication of your identity only to parties you specify. While they have a conflicting interest in providing data about you with as high resolution as possible to parties your are unaware of. Their most effective claim is that the information they provide about you to third parties is anonymous. They hold that this will be true despite the fact that they now know your identity and have authenticated it, potentially many times. I have been unable to find any policy specifically stating that these providers will never allow your authenticated identity to be connected to other collected. Caveat emptor.

The application in question: 'newsreader app for my tablet that connects to Google Reader'

The purpose of this application is to monitor no-cost publically available online content (web sites and RSS feeds) for new content, to notify you when new content is detected, and to display the content on request. The online content is not unique to you, meaning that you do not need to identify yourself to obtain the data.

The data that is unqiue to you is the list of sites and what content you have marked as not-new. Uniqueness requires identity but not necessarily authentication. The application uses Google Reader, although it could simply implement its own functions without the need to use Google Reader. Likely the application is doing this to keep your data coherent (synchronized). You want to be able to check online content from a number of different devices and not need to manually update changes on one device that you made on another. Note that the application could still synchronize with other devices without using Google Reader.

Your unique data (site lists and read-content) is transfered to and from your device. Authentication does not provide confidentiality (privacy). So authentication is not protecting others from seeing your site lists and read-content. Authentication does not provide integrity, so your data could be corrupted or maliciously modified while in transit. What authentication provides is a way to control the reciept and storage of the data. If the data is from you then it must be valid and thus an update from your current device to all your other devices should be accepted so your data is kept in sync.


How can I encrypt something user provided without risk of the key being exposed?

If an encryption algorithm is susceptible to known plain text attacks, then it is fairly severely broken.  Is there a reason that you don't use a public/private key encryption scheme?  Then the user could actually encrypt it prior to transmission and you would still be the only one who could decrypt it.  More ideally, you'd really want to have them choose a key, encrypt the data (symmetrically) with the key, encrypt the key with your public key, send the encrypted data and encrypted key to you, then if you need to use a common key, you could decrypt the data and re-encrypt it with your own key.  This would give you protection while the file is in transit.  (Alternatly, if it is a web service, simply using SSL for the transfer will do the same thing.)

Is there a particular reason you need to use the same key for every user?  This is a big point of insecurity as it results in a single point of failure.


How do hardware OTPs work - from a developer's perspective?

As stated in your other post:

No. You do not need to pass the OTP value to the manufacturers site. Usually - if you are buying pure OATH/HOTP tokens cheap in china (like Feitian), you will not even be able to do this. You need to run your own server like privacyIDEA.

The smartcard is usually no OTP token. However, some smartcards like from Gemalto indeed have an OTP application on it. In this case you need to insert the smartcard into a smartcard reader and you need to have an additional application on your client. This application will communicate with the smartcard to retrieve the OTP value.


Using encryption inside of SSL connection

It really depends on what you're trying to protect.

SSL only protects data in transit, and between the two set points.  It doesn't protect data at rest, and it doesn't offer any guarantee that the data came from the person claimed.

So if you need to protect the data while it's stored at either of the endpoints, then encrypting it might make sense.  Or if you need to provide assurances that the data came from a certain party, then signing it might make sense.

On the other hand, if you're simply decrypting the data and storing it at the endpoint, and not doing any authentication, then it wouldn't make a lot of sense to add another transportation layer.

Security often works in layers, so it's important to understand what each layer provides.  SSL is merely a transport layer, and only provides assurances that the data sent wasn't intercepted along the way, or replaced with something by an attacker in the middle.


Can my employer track my computer use at home if they pay for my internet access?

Your company could potentially see everything your ISP (i.e. "the local cable company") can see. Since they are the ones who pays the bill, they could call up the ISP and ask to see the logs. Depending on the company and the jurisdiction, they might not let your employer see the logs, and there might not even be any useful logs. But if we focus on the technical aspects, the answer is that whatever your ISP knows, they could potentially tell your employer.

So what does your ISP know? Check out this old answer of mine. In this case your ISP are the ones that own the network.

I don't see how a router would make any difference here.


Is there any processor that could decrypt encrypted data and machine instructions?

There are quite a few processors that support encrypted memory. Such processors transparently decrypt whenever they read from memory (code or data) and encrypt before writing back to memory.

This has been supported for many years in processors used in smart cards and USB tokens. For example, according to this product brief, Infineon's SLE78 supports "Full CPU, Memory, Bus and Cache encryption". This processor is the subject of What's the State of the Art of Homomorphic Encryption?.

Over the last few years support for RAM encryption has been added to processors used in consumer electronics devices such as game consoles and set top boxes. A good example of this is the XBOX 360, in which the RAM encryption was a significant challenge for hackers as described in this classic presentation by Felix Domke and Michael Steil (video).

To minimize the impact on the processor performance, the RAM decryption algorithm will probably not be a strong block cipher like AES but a synchronous stream cipher.

Such memory encryption technology is intended to defend against an attacker who does not control the CPU but can access the physical memory directly, e.g by probing the bus that connects the CPU to the physical memory.


is the certificate signature a hash of just the public key?

The signature covers the certificate, not only the public key. If the signature covered only the public key, you could change any parameter (expiration date, domain name, issuer) and the signature would still be valid.

Digital signatures are not encryption: https://security.stackexchange.com/a/87373/70830

It is important, when reading the link above, to not skip words, sentences and paragraphs that are hard, or at least, if you did, to not then say you've read it when you have only tried and failed to read it.

Very insecure textbook RSA was explained in a handwavy form to non-specialists who did not need to implement it, in this bad way, by someone who thought it reduces the number of concepts and is thus easier to digest. The people who made this explanation were wrong in the 70s about RSA (at the very least because padding), but they are catastrophically wrong about modern digital signatures. There is no notion of encryption in DSA, ECDSA, EdDSA.

People have, in the decades since and even recently, naively implemented textbook RSA, thinking it is secure. Often, they later say something like "my math professor said I can implement unbreakable encryption by just using modular exponentiation, in some introductory math class, and I took a bignum library and just did it".

Textbook RSA is of course insecure, and if they learned about cryptography in a cryptography class, they would have been taught why.

We can't take out every math teacher (or documentation writer or blogger) who says this out back and shoot them. Because we need math teachers (and maybe even bloggers). But we really need to teach math teachers, at least new math teachers, to not talk about cryptography outside of cryptography classes that will teach people enough so they won't go out and do stupid things. Machine shop teachers understand teaching about safety, math teachers should too. But many were themselves taught in an environment that did not appreciate that there can be safety hazards in pure math. Because someone might rely on an app, a piece of math, to keep secrets that would land them in jail, or worse.

We are also getting into the general problem with updating information in people's heads and on the internet. This problem is very hard.

Often, when people  learn that something they knew is actually incorrect, they would later forget the update and keep remembering the incorrect first thing they learned. So you need to keep correcting people.

The internet keeps publishing regurgitations of information that someone learned decades ago and that now we know is incorrect, and the date of the publication is new, so a reader would not know they are reading something from the 70s that has since become wrong. So we need to keep correcting publications.

This site has many separate questions and answers that boil down to someone trying to make sense of the "signature is encryption with the private key" explanation and failing (first example that came up on google). The world is full of buggy software written by people who didn't read and understand why it's wrong.

(Thanks Steffen Ullrich for the typo fix!)


Should I encrypt data on my server as an extra layer of protection?

I see a lot of flaws here:

If one account is comprimised, every person's details who are secured against their private key are revealed. This puts users' security in the hands of other users, which is possibly the worst situation to be in.
Users choose terrible passwords, which no password derivation function can save them from. Even if you're using a work factor in PBKDF2 or bcrypt that ensures an attacker can't compute more than one hash per second, they'll guess weak passwords like "letmein1" and "a1b2c3" after less than a minute.
You can't encrypt arbitrary length data with RSA (public/private key), so you need to encrypt the data with a block cipher, using a randomly generated surrogate key, then encrypt that key with the public keys of the users.
Your protocol provides no authenticity information. An attacker could use the public key of a user to encrypt a set of false financial information, then insert it back into the database. You'd need to combat this by signing the data with the user's private key, which adds extra complexities when you're allowing other users to access the data too.
You're encrypting and decrypting the data a lot, so you make yourself more susceptible to side-channel attacks like DPA and timing attacks. You'll need to account for these and take countermeasures.
Since the information is financial, you're going to have to host your server in a facility with some serious physical security.
You're going to need to use strong transport security. You can't just use any old SSL certificate - you're probably going to need something like an EV cert running 256-bit AES.
It is generally bad practice to store financial information in a database of any kind. A more suitable solution is a HSM.
I'm not sure of the legal situation in your country, but you may be forced to adhere to PCI-DSS, the Data Protection Act, or any other number of regulations. Most of these require audits, which aren't cheap and aren't easy to pass.

In all honesty, this entire scheme sounds like an accident waiting to happen, especially since you're a beginner with crypto. My advice is don't store sensitive financial information unless you are a payment processor or a bank, and have strong experience in security. Rule #1 of security is "security is hard". Getting it wrong puts your customers in danger, and sets you up for a series of expensive lawsuits. If you're a company looking to sell things, or provide a paid service, use a payment processor company who already adheres to strong security procedures and standards.


If you start the juypter notebook server it will generate an authorization token and a URL which uses this token. If you look further at the output you will see something like this:

[I 06:02:28.891 NotebookApp] The Jupyter Notebook is running at: http://localhost:8888/?token=e2b7d4eb14d22f46a7950ccb01aecaf303951cb6fbe87fa9

Everybody which knows this URL can connect to the notebook and is considered authorized. Thus, the URL or this token should be treated like a password.

  ...as if everyone using the same application now had access to my hard drive.

Everybody using the same application and the same authorization token has access to the local folder (not the whole hard drive). This is similar to for example sharing a folder within Windows and giving others the path and the password to it.

  ...  even though I realize that a notebook is a Jupyter project type

From within the Juypter notebook you have access to files inside the local directory too. This is for example needed to include local data into computations done inside your notebook.


Login form - Incorrect login and password returned in response

Incorrect passwords are almost as sensitive as correct ones - just think of all the times you failed to login because caps lock was on... Or all the times you have entered a password you use for another site by mistake.

But is this really a dangerous way to handle passwords, incorrect or not?

Let's concider security in transit first. Here you already send the passwords in one direction. Sending them back as well will not make things worse. So either you use good TLS and everything is fine, or you don't and then this doesn't make things any worse than they already are.

The next issue is security at the client. What I would be concerned about here are two things:

The user might not expect the password to remain accesible after clicking login. It would be easy to leave the password in an open tab. (The fact that it's a password input makes no difference here.)
If the page is cached the users password would end up in the browser cache. That's not so good. But responses to POST requests aren't cached, and hopefully they don't use GET requests for logins anyway. (If they do, there are bigger problems associated with that.)

Finally, on the server side a larger part of the application needs to handle the password because of this. That doesn't have to be a problem, but in general, the more you use passwords the easier it is to accidentally leak them to log files or something like that.

So in conclusion, I would say that this is not good practice. It fulfills not legitimate need. But the effects are not catastrophic either, so I wouldn't be to concerned with it. This is a case of small cost, no benefit.


Getting hmac_sha to work between Erlang and PHP

It's a string problem - turns out single quoted strings and double quoted strings aren't the same in anyway in PHP.

Here's some relevant info:
https://stackoverflow.com/questions/3446216/difference-between-single-quote-and-double-quote-string-in-php

tl;dr; I was using single quoted strings - when I went to double quoted ones it worked.


It's hard to compare the two, but I'd say they are roughly similar when it comes to risk profiles.

An app running on your phone is generally more isolated from other apps compared to applications using standard desktop environments. A rogue smartphone app that does not have root-level access would not be able to access other application's data nor see what is being displayed on the screen. This is not true about many desktop environments where there is a lot less isolation between processes using your monitor display (especially on Linux using X, which is horrible in this regard). However, a sufficiently bad smartphone vulnerability would give attackers access to the actual pre-shared key used to generate one-time codes, so security vulnerabilities on your phone are that much worse for the purposes of safeguarding your multi-factor authentication codes. If someone steals the pre-shared key used to generate OTP codes, your account is fully compromised.

On the other hand, the Yubikey Desktop Application does not expose your actual pre-shared secret to the desktop computer, as the codes are generated directly on the Yubikey. So, even if an attacker gains access to your computer, all they would be able to obtain is the current OTP code --
which is bad, but not nearly as bad as a vulnerability of a similar scale on the smartphone.

It's up to you to weigh the upsides and downsides, but in my mind the risks are roughly similar -- therefore, using the Yubikey Desktop app backed by hardware Yubikeys is an acceptable alternative to Google Authenticator.


Compromised mobile device on a company network

Ok, I'm answering the question as posed in your comment:

  [Is] a compromised mobile device as risky as a compromised computer?

Yes. Absolutely.

Per @Sean W, a modern smartphone/tablet is a computer, albeit a little one with not that much CPU, that is easy to carry around and prone to being dropped into puddles. Therefore the risk profile is similar (at the very least).

In fact, in many cases I would argue that a smartphone/tablet is much more risky once compromised:

It's small and easily hidden. If connected to AC power in a dark corner, it might go un-noticed for months.
They often have data connectivity via cellular network, allowing an attacker to bypass any corporate security controls.
The mobile OS usually runs on chips (as opposed to hard drives, which can be removed). This makes post-attack analysis much more difficult for Infosec analysts.

An attacker connects to the smartphone, which in turn is connected to the corporate network. End result? The attacker is connected to the corporate network, just as if a desktop computer had been compromised. Almost every mobile device will have enough CPU to run a SSH server for the attacker to connect to.


Amazon EC2 security compared to a standalone server

They are relatively similar and there is nothing special about an Amazon EC2 server that you can not achieve at home.

However, the two defaults that won't occur (by default) in an ordinary install of, say, CentOS are:

+Security Groups - By default all external traffic is forbidden. You must set up a 'security group' to allow specific ports and I.Ps. However, allowing all ports and all I.Ps is relatively simple.
+Key-Pair Authentication - By default it is not possible to log in to an EC2 server with a simple password. You must generate a private key and use that to log-in. Making bruteforcing much less likely.

Of course, there is a clear security negative with the EC2 cloud:

-Public I.P - All EC2 instances have a public I.P., if you modify the security groups improperly then you're potentially opening yourself up to malicious traffic. Whilst on a local network your server can hide behind a NAT or not be connected to the internet at all.

There are other advantages of EC2 over, say, keeping the server in your bedroom. But these apply more generally to data center vs. bedroom:

+Physical security
+Safety from Natural Disasters
+Safety from Power failure
+etc. etc.


Wrap key operation in Azure Key Vault - symmetric keys

Key wrapping is a class of algorithms meant specifically to encrypt symmetric keys.
The reason for the wrapping is not the security of the vault itself but rather the security of the key once it leaves the vault.
The way wrapping is typically used is:

client A requests WK = wrap(K)
client A sends WK to client B
once needed (immediately, or in the distant future), client B asks vault for K = unwrap(WK) and uses K.

This short example shows some of the benefits of wrapping a key:

protect the key while in transit (sending from A to B) or in storage (stored by B)
assign permissions to unwrap the key (client B must have permissions to unwrap the key)
set a lifetime on the wrapped key (some vaults allow lifetimes on a wrapped object, or the key that encrypted it)

All of the above assume that the client will only store the wrapped key and not the result of unwrapping. If client B decides to store K itself, we're back to using a plain unwrapped key.


The question is what you consider "bad" in this case. Since I can only guess what is considered bad in your use case:

Stripe will have access to the data in the GET request without further intervention from the user if you load it the way your example works: this might be a privacy regulation issue depending on the details.
Anyone that sees the URL sees the data. That means the users' browser, but also anyone that visits the site that contains the URL.

However, as far as I'm aware, Stripe already offers its' users a pre-fill feature through an SMS/text message to the user when Stripe detects that it knows their browser -- I'd recommend using that unless you have a very specific reason to pre-fill this data.


The link you've provided does not mention SSH at all.  SSH can be easily configured to use username/password and public key authentication.  Major SSH implementation allow for the configuration of Kerberos authentication.  But SSH does not allow the use of shared secrets for authentication.  The protocol itself just doesn't support it.

SSH isn't really designed for using shared secrets.  Shared secrets are often used for long term VPN tunnels between two end-points.  While you can tunnel with SSH it is designed to perform secure shell actions.  For this you would like to authenticate individual users so that admins can keep track of who is connecting to a particular machine.  Shared secrets would only authenticate the machine that is connecting to it, not the user.


Is my keepass great? How can I improve it?

Having the DB file and Key file in the same place pretty much defeats the purpose of the Key File (especially if its stored Online). If someone has access to your Google Drive Account they "only" need your Password.

I would also consider trying to only remember your Master-Password (Diceware can help) and not having it in so many personal places.

Also keep in mind what your Threat model is.


How do companies track employee usage on corporate computers?

This depends widely on the type of monitoring that is desired. Logs can be collected and reviewed. Proxies can be used to limit access to specific ips or domains. IDS devices can be used to monitor and if the devices are inline even reset connections that are a result of a violation of policy. Such as IRC,Facbook etc.. I think more details would be necessary to answer your question in a more effective way.


are organizations that receive certificates considered "end entities" in a PKI?

An end-entity certificate is a certificate which is not used to validate signatures on other certificates, i.e. a certificate which does not contain a CA public key (its Basic Constraints extension is absent, or contains a cA flag with value FALSE). It is called "end-entity" because it appears, necessarily, at the end of a certificate path.

A CRL issuer certificate, i.e. a certificate for some entity who signs CRL (on behalf of a CA), can be an end-entity certificate, since signing CRL does not require to be a CA.


Establish a secure channel with mutual authentication given pre-shared public keys

Yes, Diffie-Hellman with pre-shared public keys provides a mutually authenticated channel. However, if you use it, you will be guilty of using your own cryptographic implementation and in part your own cryptographic protocol, which is not nearly as big a sin as using your own cryptographic algorithm, but still best avoided. Unless you have a good reason not to, use SSL (with pre-shared, self-signed certificates, or for more flexibility with certificates signed by an in-house CA).


Password hashes should run md5 thousands of time: really?

Cryptographic hash (like md5) with salt are bad.

It is not sufficient anymore. The traditional cryptographic hash functions are designed for documents and therefore they are optimized for speed.

But speed is exactly what we don't want for password hashes. Modern graphic cards can do 2,000,000,000 SHA1 or MD5 hashes per second. So brute forcing a 6 character password takes less than 10 minutes.

  It isn't uncommon to break/crack unix shadow files.

That's true for the old hashes used in them.

  To make a password hash I should run it over md5 or whatever hundreds or thousands of times.

While this is am improvement over just using a quick hash function ones, it is not sufficient.

You should use one of the hash crypt algorithms (except for md5crypt): sha256crypt, sha512crypt, bcrypt or scrypt. Those are algorithm that are designed to be relatively slow and not easily implementable on graphic cards to gain a performance boost.

Those algorithm do more than just using the output of one round as input for the next round. The rules of what to use as input vary based on the iteration counter (See the linked specifications). Modern unix operating system use sha512crypt.

scrypt goes one step further than the other algorithms because in addition to scalable CPU usage, scrypt uses a lot of memory. The idea is to make hardware implementations of password crackers a lot more expensive. Such hardware usually has access to up to 1KB of fast memory, but the default parameters of scrypt require 16MB.


How to find the actual address of spoofed IPs?

An important point must be made, which is that IP spoofing is limitative. When an attacker uses a fake IP for the packets he sends, he will usually not be able to receive the answer, unless he has some extensive power over the overall network: that's because the response will be sent to the fake IP, not the attacker's actual IP address. In particular, this makes it hard for the attacker to spoof IP addresses for TCP connections.

In fact, most successful intrusions have a non-spoofed components. Attackers use relay hosts (compromised machines around the world) to try to make them harder to track down, but that's not spoofing.

Spoofing can be detected in some cases because it "looks weird". Consider an ISP; from the ISP point of view, there are two sorts of IP addresses: its addresses (i.e. the one he grants to its customers), and the rest of the World. In the ISP routers, packets with a "external" source address should be seen as incoming packets (coming from the outside), not as outgoing packets; and vice versa for packets with an "internal" source address. If one of the ISP customer sends a packet with a spoofed external address, this will show up as an outgoing packet, coming from the inside, but with an external source address; the ISP routers will find such an occurrence anomalous and may report it. The ISP can then further track down such packets down its infrastructure and thus pinpoint the culprit.


Is TLS 1.2 client authentication really different from that earlier ersion of TLS

Client authentication in TLS normally uses a client certificate and the method by which the client is authenticated has not substantially changed since SSL 3.0: during the initial handshake, the server asks for client authentication (a CertificateRequest message), and the client responds by sending his certificate and then a signature computed with his private key over the concatenation of all the previous handshake messages (which includes the two "random values" sent by the client and the server, and also the negotiated cipher suites, the server's certificate...).

There are details, though. A signature algorithm uses a hash function, and the hash value is then used with the private key. Up to TLS 1.1, the client necessarily used the concatenation of MD5 and SHA-1 as "hash function". With TLS 1.2, client and server send to each other the list of hash functions and signature types they support, so that the client may choose an "appropriate" hash function, and also an appropriate certificate in case the client owns several of them.

The pre-1.2 method employs a "special padding" with RSA: in PKCS#1, the hash value is first stored in a structure which identifies the hash function (in practice, a fixed header is attached to the hash value), and that encoded structure is then padded with some bytes (most of them equal to 0xFF) up to the key length. In the signatures used from SSL 3.0 to TLS 1.1, the hash value has length 36 bytes (16 bytes for MD5, 20 bytes for SHA-1), and there is no header: the 36 bytes are directly used in "type 1 padding". With TLS 1.2, only one hash function is used (negotiated between client and server), and the header is back.

Thus, TLS 1.2 aligns itself with the PKCS#1 standard and supports many hash function, which should improve interoperability. Yet, it is conceivable that a specific hardware token for the client private key (e.g. a smart card) could be incompatible with TLS 1.2 (if it supported only the 36-byte-hash-with-no-header mode of older SSL/TLS). In that sense, TLS 1.2 might break compatibility with deployed tokens (this is rather improbable, but still warrants some tests). For software implementations, this should not be an issue.


Are there implementations of password hashing algorithms for major frameworks that utilizes specialized hardware like GPUs/FPGAs?

The benefit of computing hash functions with an FPGA or GPU is that they are heavily parallel,  such parallelization is not required for most authentication systems.  Further more memory intense hash functions,  such as bcrypt and scrypt, remove parallelization advantage that FPGAs and GPUs have over CPUs.

It is possible to implement such a feature,  however it would be counter productive.  The point of using bcrypt, and other key stretching algorithms, is to remove the computational advantage provided by a heavily parallelized computational resource such as a  FPGA or GPU.

Related:
Why can't one impermanent bcrypt in Cuda?


Chrome/FF not negotiating advanced ciphers?

After all, SHA-1 is deprecated in general.

No. SHA-1 is deprecated for signatures. It is not deprecated when used as HMAC. See also Obsolete cryptography (SHA1) warning although certificate uses SHA256.

  Our certificate was also signed with SHA-256.

This is completely unrelated to the choice of cipher.

  ...there's no reason that Chrome or FF shouldn't support larger block sizes for SHA hashing, is there?

Apart from performance probably no. But there is also no reason to have a "mine is bigger" approach to security. SHA-1 is save as HMAC and even MD5 is save for this purpose. They both are not safe for use in signatures but this is a different thing.


A tool or browser which changes the IP Address (Not like a single VPN, lots of different addresses) but fast

This is possible by using python modules. You can use an https proxy list which can be easily found using simple google search.

Then you will be able to emulate a different browser by using a module like Fake-useragent.

Here is a writeup which you can refer to :

https://codelike.pro/create-a-crawler-with-rotating-ip-proxy-in-python/


Is it safe to use cheap USB data cables?

Do you have reason to expect targeted attacks?

It's reasonable to assume that random cheap cables sold in large scale generally aren't modified to include offensive hardware, mostly for two reasons:

That would raise the cost of the cable far above its price, and would be uneconomical even considering the ability to "monetize" a certain amount of random untargeted computers owned by the attack, so there are no good economic reasons for attackers to do this.
We would have noticed such an attack. While most people wouldn't notice, if this was a mass attack, there would reasonably be some detection of that. Malware that tries to randomly hack many, many computers has obvious problems staying undetected for long.

However, if you have some reason to expect targeted, expensive attacks aimed to compromise you by people who have no qualms to perform illegal actions, then it certainly is a possibility that the hardware you receive is "special". However, that's not limited in any way to cheap USB data cables, or USB data cables - reasonably similar attacks would apply for any device you purchase in the same way, from mice/keyboards to laptops or server hardware. How do you know that your computer didn't have a hardware / firmware backdoor installed when you bought it?

If you have reason to expect such risks, you have to treat your USB data cable purchases in a similar manner as all other sensitive hardware; for example, ensure that you buy an item that cannot possibly be "adjusted" especially for you, e.g. random purchase of a generic item from a store shelf instead of a remote order that will be mailed to your address.


How secure is Ubuntu's default full-disk encryption?

In a word: sufficient.

This is block-level encryption, so it is filesystem-independent.

Ubuntu's transparent encryption is done through dm-crypt using LUKS as the key setup. The built-in default for cryptsetup versions before 1.6.0 is aes-cbc-essiv:sha256 with 256-bit keys. The default for 1.6.0 and after (released 14-Jan-2013) is aes-xts-plain64:sha256 with 512-bit keys.

For older versions of cryptsetup:

AES you certainly know; it's about as good a cipher as you could want.
CBC is the chaining mode; not horrible but certainly not what I would pick for new projects: it has several issues but it can be used securely.
ESSIV ("Encrypted salt-sector initialization vector") allows the system to create IVs based on a hash including the sector number and encryption key. This allows you to jump straight to to the sector you want without resorting to predictable IVs, and therefore protects you from watermarking attacks.
SHA-256 is the hashing algorithm used for key derivation. LUKS uses PBKDF2 to strengthen the key for (by default) a minimum of 1000 iterations or 1/8 second, whichever is more. On a fast computer, expect around 200,000 iterations. With respect to security, you couldn't ask for a better arrangement.

And with newer versions of cryptsetup:

XTS is counter-oriented chaining mode. It's an evolution of XEX (actually: "XEX-based tweaked-codebook mode with ciphertext stealing"), while XEX ("xor-encrypt-xor") is a non-trivial counter-based chaining mode; neither of which I can claim to completely understand. XTS is already very widely supported and looks promising, but may have issues. The primary important details are these: No fancy IVs are necessary (plain or plain64 is fine), and half of your key is used by XTS, meaning your original key must be twice as long (hence 512-bit instead of 256-bit).
PLAIN64 is an IV generation mechanism that simply passes the 64-bit sector index directly to the chaining algorithm as the IV. plain truncates that to 32-bit. Certain chaining modes such as XTS don't need the IV to be unpredictable, while modes like CBC would be vulnerable to fingerprinting/watermarking attacks if used with plain IVs.

Other options not used by default

LRW has been largely replaced by XTS because of some security concerns, and is not even an option for most disk encryption products.
benbi calculates a narrow-width block count using a shift register. It was built with LRW mode in mind.

Altogether, this makes for a pretty tight system. It isn't the absolute best system theoretically possible, but it's pretty close. You should be able to trust it in any reasonable circumstances as long as your password is sufficient. Your attacker will almost certainly choose brute-forcing the password as his preferred attack method.


someone is trying to SQL injection me.. what are they trying to do?

This looks like a fully automatic attack which is performed by bots on random websites they find.

The attack is trying to get your database to output the string &~! (ASCII values 38, 126 and 33). They likely parse your websites response for that string and when they find it, the bot assumes that it was the result of its injection and reports it to a human cracker as a potential target for a more targeted attack. The cracker will then take a look at your site and consider if the data you have might be worth their time. Only when you appear to be a lucrative target will they pursue further actions.

Did you take the usual precautions to secure your website against SQL injections? Then you have nothing to worry about.


Is it possible to decrypt a PGP encrypted file without private key?

While it's recommended to use a key larger than 1024 bits, you could replace your encryption subkey with a larger one, keeping the same signing key (and by extent GPG identity). GPG keypair effectively consists of multiple separate keys (all signed with the same certification key, C in usage).

Note that this will make all data encrypted for the old key inaccessible. You could re-encrypt the data or keep the old encryption key around.

Here's an example of replacing a 2048-bit encryption subkey with 4096-bit key.

$ gpg --edit-key test@example.com
gpg> key 1

sec  rsa2048/10627915E34373B1
     created: 2019-12-27  expires: 2021-12-26  usage: SC
     trust: ultimate      validity: ultimate
ssb* rsa2048/520DD5D5DC5F1214
     created: 2019-12-27  expires: 2021-12-26  usage: E
[ultimate] (1). Test Test <test@example.com>

gpg> addkey
[snip]
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
[snip]
sec  rsa2048/10627915E34373B1
     created: 2019-12-27  expires: 2021-12-26  usage: SC
     trust: ultimate      validity: ultimate
ssb* rsa2048/520DD5D5DC5F1214
     created: 2019-12-27  expires: 2021-12-26  usage: E
ssb  rsa4096/29F957A70823378C
     created: 2019-12-27  expires: 2020-12-26  usage: E
[ultimate] (1). Test Test <test@example.com>

gpg> delkey
Do you really want to delete this key? (y/N) y

sec  rsa2048/10627915E34373B1
     created: 2019-12-27  expires: 2021-12-26  usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa4096/29F957A70823378C
     created: 2019-12-27  expires: 2020-12-26  usage: E
[ultimate] (1). Test Test <test@example.com>


Try a few different browsers on that machine to see if they all get the popup. If they don't, you might have a malicious extension or addon installed into chrome. If they do have the same problem, you might be a victim of DNS hijacking on the affected computer considering other machines on your local network don't experience this issue (although if they do it's still possible that your router has been compromised to the same end). If you open up your network adapter settings do you see anything under the IPV4 or IPV6 DNS settings that you didn't set?

There was a really interesting blog post on a similar case of DNS hijacking recently where a security researcher found malicious scripts on popular websites but only when browsed from his computer but I can't find it now. If I can find it I'll link it here.

Edit: Just to address the point about fake warnings, those can actually be a good source of ad revenue if the installation count is high enough. If the DNS hijacker exists, it is probably also inserting other ads into pages as well since that's easier to get reliable money from than attempting to gain and sell personal information. Also, as far as the green lock is concerned, it's possible that the main site resolves the same way but its external dependencies (a jquery cdn, for instance) resolve to something that will occasionally pad a bit extra into the original content.


Is this a website attack / vulnerability test?

It's probably either a crawler or internet background noise (e.g. automated vulnerability scanners). If all those pages actually exist it's a crawler, if not it's a internet background  noise.

If it annoys you, you can ban the IP on your firewall. Another option is a Host Based Intrusion Detection system like OSSEC which detects these type of attacks and blocks them automatically on the firewall for a period of time.


Why would a modern browser allow internal resources to be loaded from an external page

functions such as reboot and factory reset ... why would a modern browser allow internal resources to be loaded from an external page

Most of today's routers and other networked devices will be administrated through a web interface. This means that there is some web server with a web application running on the device and the user is using the browser to access this device the same with as (s)he is using any other web page. This web interface then offers ways for the user to reboot the system or similar by clicking the specific links in the web interface.

But by default a browser allows lots of interactions between web pages of different origin. You can click on a link on one web page to go to another page. Or you can embed images from one page into another page etc. The browser itself has no knowledge what is an internal page and what is an external page and which pages are allowed to link/embed to another and which not. Thus the web applications have to do the checks by themselves, i.e. check if a request to the device is caused from a different origin and don't execute it in this case.

Thus the one which was overly permissive in this specific case was not the browser, but the web application running at the router. It should have checked the origin of the request and not execute it if it was caused by some other site (cross origin request).

Unfortunately this kind of bugs are very common. Such devices are often developed with a tight budget and security only adds costs but not functionality. Apart from that most developers are not even aware that the web is mostly permissive by design and that they should add the needed restrictions to the device.

Since such bugs are that common it would of course be nice if browsers would at least include some protection for such broken devices, like limiting access from external to internal sites. But unfortunately there are actual use cases for such cross-origin requests to local IP which then would break. And then are issues with DNS and proxies. And probably more issues. For a deeper discussion see this Chromium bug where they discuss about this issue since about 2 years.


Is it possible to prove the content of an encrypted message without disclosing the private key?

Yes, assuming there is no randomness added to the message during encryption (or that Bob reveals that randomness) then anyone who encrypts the plain-text message with Bob's public key will get the same cipher-text that Bob received / published. That is, of course, assuming that Bob can prove the cipher-text is genuine.


Removing malware from a malicious PDF file

Since there's absolutely no way to tell what's inside that file and what it's capable of, I'd recommend cutting your losses and nuking it from the get-go. With most PDFs (and, infact, any file really) you can recover relatively quickly as the PDF is bound to reside somewhere else (either an earlier draft or an un-modified version).
That being said, you seem very keen to open this PDF so I'm assuming it has some sort of uniqueness to it. You'll need to forgive me for putting my day-job hat on but usually this means a user hasn't saved or backed up their documents when they should have. If that's not the case, and this is truly the Dead Sea Scrolls of the PDF world, let's see how we can open/clean these files without damaging them or, indeed, yourself.
Using a browser to recover the PDF
You've brought up opening them in a browser several times:

"Upload the document to Google Docs. I assume that Google has one of the most secure PDF viewers out there."

and

"Use Firefox's pdf.js or some other browser-based viewer"

As I said at the beginning, we've no idea what we're dealing with at the moment. Opening it a browser (at this stage) wouldn't be recommended. Also uploading it to Google is a little bit unethical since you know full well that there's something suspicious going on with the PDF.
Even if you were somehow able to know exactly what that PDF file's malicious content is capable of, there's no way to ensure it hasn't been tampered with to masquerade.
Using a VM/isolated machine to recover the PDF
You touched on it in the middle of your question, using a VM or isolated machine is obviously a far safer way of opening that PDF.
Now you might be thinking that's a lot of time to spend setting one of those up but if you keep a snapshot of clean, portable, small systems taken immediately after the installation has completed, we can almost safely open the PDF, print the contents to file (as @KnightOfNi has already alluded to) without the PDF editing capabilities. Why not go one step further and actually print them on a closed loop with a USB printer and rescan them? Might seem like a massive hassle but we're dealing with a time-bomb of unknown magnitude. It could destroy your system, steal your data, crypto-locker your stuff, or simply be a lemon - the point is we have no idea.
"Can I be sure that it is safe?"
From your question:

Another question I have: How reliable is the pdfid tool? For example, if I get a result with no Javascript, OpenAction, etc. can I be sure that it is safe?

Again, not really - but there are ways you can test to see how accurate the tool is.

If it's Open Source, have a dig through the code and make sure it's not just spitting out any old garbage and barely touching the files.
In that VM/isolated machine lab, why not throw it some good/bad/ugly files that are known to be infected with a certain strain of malware? You can roll your own or you can reach out to the researcher community who usually have a few examples to download online.

To be honest, it all depends on how much you want to recover that PDF. For most people- it's way more hassle than it's worth... but then again, that depends on the contents.

What I'd do:

Isolated virtual machine on an isolated physical machine (sounds like overkill but that's how I tested my first experience with CryptoLocker - glad I did it that way).
That means no file sharing (i.e. share desktop -> desktop on VM)
Go for an odd OS. The odder the better. Most of these PDF viruses are targeting specific users of specific versions of an operating system. I doubt they've thought about Kali, TAILS, or similar
Deactivate plugins/delete any known areas or apps of concern (flash, etc.)
Open a test PDF and set all the security settings to max before opening the target document
Open the target document, physically print it, scan it back in.


SETOOL Kit:Error: "Unable to Clone the site. Check your network connection"

First off, a site can't really be vulnerable to a phishing attack. A site / email / app can always be duplicated convincingly from an aesthetic standpoint given enough time. So really, it would be the end user who is or isn't vulnerable to phishing since they are your target.

Regarding SET, the relevant logic in SET can be found here (lines 130-167). Have you tried using wget to access the site? Specifically the command used by SET:

wget --no-check-certificate -O index.html -c -k (-U [useragent]) [url]

I parenthesized the useragent parameter as it probably isn't needed if you are running this from command line on the same computer as you are running SET. Otherwise it may be a permissions issue regarding SET not being able to write to disc. Make sure that you're running SET with sudo. Also perhaps try a site like google (DO NOT ACTUALLY PHISH ANYONES GOOGLE ACCOUNT INFO) that should work just as a sanity check.


What IP address is used when replying on an email while using a VPN?

Question 1: What IP Address recepient will see?

Scenario 1: You are connected to VPN and using a native email client such as Outlook: Then the header will contain the VPN IP Address

Scenario 2: You are connected to VPN and using a webmail service such as Gmail: Your real IP address or VPN IP address will not be part of the headers. Headers will only contain your webmail servers IP address.

Question 2: Will the real IP address be exposed when recipient replies?

Recipient will reply to your email address not your IP address. Let me elaborate. Emails are stateless, every reply or forward will be just considered like a normal email by your mail server. When the recipient will respond to you, recipient's email server will fetch the MX record from your DNS records. The recipient's email server will then send this email to your email server. Now, for you to access this email, you will have to sync your native email client with your server or access this email through webmail. This is what I meant by "Recipient will reply to your email address not your IP address".


Is it the responsibility of a certificate authority to ensure an SSL is not used for nefarious purposes?

No.
A CA has a responsibility to verify that the person requesting a certificate for a domain actually owns the domain in question. It is not up to the CA to perform censorship of domain names, nor to police what people do with a certificate once they have it.

Now, your concern is already kinda addressed by the higher levels of SSL certificates, but it's up to the corporation applying for the cert to spend the extra time and money to get it.
There are effectively two levels of certificates you can buy: Domain Validation (DV) and Extended Validation (EV). DV certs are designed to have automated issuance and are the type of cert that Let's Encrypt issues. EV certs have much higher levels of vetting before issuance, and require phone calls, paperwork, etc.
wikipedia/Extended_Validation_Certificate:

Issuing criteria
Only CAs who pass an independent qualified audit review may offer EV,[5] and all CAs globally must follow the same detailed issuance requirements which aim to:

Establish the legal identity as well as the operational and physical presence of website owner.

Establish that the applicant is the domain name owner or has exclusive control over the domain name.

Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.

Note that for EV certs, the legal entity applying for the cert needs to be a corporation, not an individual, and the corporation name is included in the cert, and appears in the status bar of your browser.
ex: non-EV cert:

ex: EV cert:

Notice how PayPal's legal name appears in the address bar? That is next to impossible to spoof, and we are raising the bar for spammers: the only way to get "PeyPal, inc" there would be to actually incorporate a company, which criminal organizations typically don't want to do. So once users get used to looking for this on big-name websites, this problem will kinda solve itself. Unfortunately, because of the amount of manual verification involved, EV certs are expensive (hundreds of $USD per year), and CAs like Let's Encrypt or godaddy will never offer them.

Generally speaking, a CA is like the passport office or the bureau that issues driver's licences; they have a responsibility to ensure that A) you are who you say you are, and B) that you have met the requirements (ie you are a citizen / you have passed your driving tests). They have no responsibility to track what you are doing with that ID, nor is it legal for them to revoke your passport / driver's licence even if you do use them for illegal purposes.

Addressing comment:

Is there a history of certificate issuers revoking certificates because of nefarious use, even though they don't have a legal responsibility to do so?

No, Definitely not. A CA would get shut down if they did that.
Think about it this way: Certificate Authorities need to be a completely neutral and globally trusted 3rd party. If they have the power to make judgments on what counts as "nefarious" and revoke certificates based on that, then they wouldn't be neutral and globally trusted, now would they?
You might think that the browser could get together and make a strict set of rules for what counts as "nefarious" so that the CAs are then only enforcing the rules. But what would that actually accomplish? Phishers and scammers are very good at slipping through the rules. We would likely spend more time and effort arguing about the rules than the amount of benefit we'd get from it.


Are there any security implications in creating an SSH key for the root user?

No, having keys for your root user does not impact your security profile. It is wise though to disable root login in ssh and NOT have an authorized_keys in your /root/.ssh/ folder.

However. I got the feeling your going about this the wrong way. Personally, I would not use the root user in this manner (but a system user like www-data) and make several command and control scripts that reload Apache config for example that are specified in the sudoers list (with full specification) so that my user can simply call a script that does have the rights to do the 'special' actions needed.

This way you will have an audit log of what has happened. This limits what can be misdone by the user in case of a compromise and does not expose your complete system.

The sudoers file (and the sudo command) have an option to make them work without password entry (:nopasswd:). You can also limit the commands and calling users in the file. As a bonus you can have a separate user with limited rights to have the deployment access, further limiting potential harm.


From the post and ensuing dialogue:

The machine is a Debian wheezy / 7.0 that aparently has not seen updates for around two years.
There are logs lacking, that indicate the attackers cleaned up traces of their activity.
The OP complains of a divergent behaviour, which corroborate the last hypothesis. [ and the compromised page ]

As for the length of time without updates, there have been multiple holes, remote and local, at kernel level, and in daemons. Vulnerabilities in IPv6, ICMP, ssh and so on. The attackers could actually have gotten by pretty much anywhere in the system.

It is strongly recommend to kill this machine.

Hackers also often install kernel modules to hide their tracks. If you wish to perform a post-morten analysis, boot it with a Live CD/DVD and dump the disk with dd to a DVD for analysing it.

As for recommendations for the future:

Rules to use new versions of the operating system;
a sensible update policy. No machine, as the best as it can be
configured, will withstand an attack without having regular security
updates;
uphold the Unix principle of installing the minimum services needed;
Creating firewall policies, just expose to the Internet the essential ports;
Install a WAF application, for instance, modsecurity if using Apache;
update your CMSs regularly, Joomla, wordpress and Drupal have more holes than a swiss cheese;
Consider looking into containers, namely Docker;
Follow standard programming practices to avoid layer-7 attacks like SQL injections;
Monitor for usage and unusual activity;
Keep regular backups.


Best practices for design of mutual-auth TLS certificate chains?

I don't know that there is a single set of "best practices" for doing client-auth since it depends a lot on the details of your environment. You can probably find best practices for setting up a CA for VPN client auth, if that's close enough.

I can give you a list of questions that you should think about in the context of your application. In solving these problems, the question about CA hierarchy may get solved for you.

Is there anything differentiating a client from a server? It would be bad if a someone could set up a fake server using a client cert and get other clients to connect to it. There are any number of ways you could solve this: you could use different root CAs for clients and servers, though it may be simpler to put a "I am a client" and "I am a server" Extended Key Usage into the certificate. Note that the more clever methods will require you to write custom certificate validation code on the client and / or server components.
How does revocation work? If a client/server needs to revoke their certificate, who do they contact? How will the servers/clients know it has been revoked? How quickly will the servers/clients know it has been revoked?
How are you updating client certificates when they expire? (don't pull a Tesla, full twitter thread here)
How are you securing the private keys of the CAs? Are they being stored on some sort of hardware token? What happens if the machines hosting the CAs go down? (either temporarily, blocking revocation information from being published, or permanently, losing the CA private keys)

Basically, I think how you set up the CA hierarchy ends up being a side-effect of how you address the other security considerations ;)


Trying to figure out if I was hit by an obscure exploit attempt of some kind

So, it turns out that someone was using a copypasta script for checking file contents that, inexplicably, calls file_put_contents inside an if() declaration, I honestly didn't look at it long enough to consider why it was, I'm just glad that was the root cause. Turns out, the reason mostly PHP files were affected only, is that the script was written in PHP, and PHP-fpm doesn't have privileges to much else.

I still find this an interesting question, whether something like this could be used to fish for application vulnerabilities or so on; anyway, something about the thin line between a novel accident and a breakthrough? Hopefully this post wont inspire a maniac's creativity...


Your password can be viewed by processes in the server, since you are executing the ecryptfs there.

What you can do is to mount the ecryptfs locally. I see two options:

Mount the server folder locally with sshfs and then ecryptfs over it.
Reverse-mount the source folder and rsync those encrypted files to the server.


Why do I have keys of strangers in my GPG keychain?

Lots of mail clients will automatically fetch certificates if you receive signed mail (or news group postings) to be able to verify them. Especially newsgroup postings and messages on mailing lists can lead to a rather high number of "drive-by" certificate downloads.

Certificates of unknowns are not a problem at all: unless you trust them, they do not have any effect on validation of other keys unless trusted, but enable you to validate signatures (on files/messages) issued by this key if GnuPG can find a trust path to them.


To identify a card, you power it using a carrier wave on its frequency and wait for answers. If there is no answer, you switch to a different frequency and protocol and so on until you get communication from the card (you may need to use multiple readers as different frequencies require different readers). Using your phone is accurate, I mean, if the phone can talk to the card then at the very least the card is using a frequency and protocol that's supported by the phone's reader.

Now, let's assume you positively identified a Mifare Classic card and you need a reader to attack it. Any LibNFC-supported reader should work, but I suggest you look for NXP PN53x-based readers, they are pretty cheap (chinese, and I'm not sure the NXP chip is genuine but they do work) and work perfectly with LibNFC and all applications that use LibNFC to talk to readers.

For software, you first use mfcuk to get at least one key, then you pass that key to mfoc which uses a different (and faster) attack that requires the knowledge of at least one key (you can also try default keys if the people who manage the card system you're attacking were really idiots). These software use LibNFC to talk to the card and are thus compatible with any reader supported by LibNFC.

Yes, once you have the key, any device can read and write to the sectors protected by that key. Note that there can 2 different keys per sector, and each sector has some ACL bytes that describe the permissions for each key.

Note that Android devices with NXP chips can directly crack Mifare Classic cards using NFC-War.


Client side signing of a file(.exe,.dll,.jar..) using CA issued certificate and signtool

In theory, what you're asking for is possible: code signing basically is just signing a file hash so there is no reason why you have to do that at the same place the hash is calculated.

In practice, though, I'm not aware of any way you can do that without writing your own code signing code - something that you should really not consider. It would be a delicate problem because you'd have to secure the system very tightly.

That being said, I cannot really imagine a setup where uploading your code to a signing server would be impossible or even very difficult. I suggest you concentrate on that aspect of your problem instead.

Edit: In view of Jonathan's answer, I think I have to add a word of warning about trying to change existing code to implement such system.

First, it can be done. In fact, after checking my own (read: the code I use, which is professionally maintained, and not any code I wrote myself) code-signing libraries, it wouldn't be too hard (at least not at the code-signing level).

That out of the way, you need to consider the consequences: first, the tools and library you use would then immediately stop being supported by your provider (whoever they are): if there is any bug in it that is fixed at a later date, you'll have to implement the patch yourself (assuming you can). This is incredibly uncomfortable from an operational point of view.

Second, writing crypto code is HARD and writing a safe crypto-based product is even harder. While it can be quite interesting to do so "for the fun", a professional, production-ready system needs much more resources than a single person: it's really a team effort that requires formalized testing.

So, given that your issue seems to be that you have a single instance of a problem (your code base is so big that you're having issue uploading it to the server), I think it's a problem that needs to be solved at one location, not get a universal solution.

Now, if you want to produce a new product that solves the issue of code signing for teams (and there might be a market for that), that's a different issue altogether (but not one for this place).


Base64 conversion for byte array in encryption

It sounds like you are using cryptography improperly.  There is no reason to store encrypted data within an html page.  Further more ECC and another asymmetric algorithms are very resource intensive.  A symmetric cipher should be used with a mode that has authentication.

But most importantly.  Why aren't you using HTTPS?


My Apache log is kind of freaking me out

Do you use any application to access your FTP account? The first thing I would do is to check the source of the FTP connection. Some application may save your credentials if you have selected to and would periodically connect. Don't freak out yet, check the source IP of the FTP connection. If it is from one of your IPs, it is probably a saved password in one of your application. If it is something from elsewhere (China), you might even have issues with your personal machine as you mentioned that you changed the username and it appeared in the logs when you did not use it.


This is the endless problem of: I know how to securely encrypt this, but where should I securely store the key?. Unfortunately, there is no nice solution, because if you want to allow an unattended reboot, the key must be accessible from the machine. That means that you can only rely on a something you have.

Said differently, if only the storage disk is stolen, your system will be safe, but if both disk are, the attacker will have all he needs to decrypt everything.

The best technical solution I can imagine, would be to use a HSM to decrypt the keys. But it only adds security if you can hope that the HSM will not be stolen with the disks. That means that the only efficient way will be to improve the physical security of the data center.


Fuzzing C++ application that expects XML file

Since the time usable for fuzzing is limited it is best to fuzz first the parts which are likely to process possible dangerous input. I don't know the exact use case for the tool but I find it more likely that the XML files used as input can be controlled by an attacker than that the attacker can control the command line. Thus I would suggest you care about the XML first and if you then have still time you can fuzz the command line too.

Apart from that I would suggest to try more intelligent fuzzing instead of random input. Have a look at American Fuzzy Lop.


Yes. The Windows event log (eventvwr.msc) on the local machine will show the logon in the Security log.

For example, the event details might look like this:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          23/03/2015 13:08:55
Event ID:      4624
Task Category: Logon
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      POLYBOX
Description:
An account was successfully logged on.

Subject:
    Security ID:        SYSTEM
    Account Name:       POLYBOX$
    Account Domain:     WORKGROUP
    Logon ID:       0x3e7

Logon Type:         7

New Logon:
    Security ID:        POLYBOX\polynomial
    Account Name:       polynomial
    Account Domain:     POLYBOX
    Logon ID:       0x55539572
    Logon GUID:     {00000000-0000-0000-0000-000000000000}

Process Information:
    Process ID:     0x2f4
    Process Name:       C:\Windows\System32\winlogon.exe

Network Information:
    Workstation Name:   POLYBOX
    Source Network Address: 10.0.99.11
    Source Port:        12345

Detailed Authentication Information:
    Logon Process:      User32
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

Alternatively, security auditing can be set up to monitor the access of securable objects (files, registry keys, services, processes, users, groups, etc.) and provide a rich listing of changes made.


I work for a company from home online, using my own laptop. Privacy issues

According to your comments you seem to be working remotely through a web interface displayed in a web browser.

That website doesn't have more or less technical possibilities on your computer than any other website. It should be unable to monitor any other activity on your computer like accessing other websites or running other programs.

The website should also be unable to access your webcam or microphone unless you gave it permission to do so. You can see which websites have special permissions in Chrome's settings menu under Settings->Advanced Settings->Content Settings->Media. Note the "Exceptions" button where you can see if specific websites have different permissions.

However, there might be other software you installed on your machine which might be back-doored. Especially when using that website required you to install any additional plugins, these plugins might give the website additional abilities to spy on your machine.


What are the advantages and disadvantages of installing an operating system through network?

The advantages are various:

You can save a lot of bandwidth.
You can customize installs with SPECIFICS. For example, if you have multiple departments, with multiple needs, you could create specific images for specific departments. E.g., a system with network specific tools for say, those who work in a NOC. System with say graphics applications for a marketing/graphics department.
Another benefit is it makes things simple to upgrade/update from a single source versus: "Oh someone forgot to mark this CD/DVD/USB" From a security standpoint, the biggest benefit is you control what is installed from the ISO level.
You also minimize having to run the risk of allowing a "boot from USB/DVD" rogue images from being introduced.


Vigenere Cipher - help with decryption (by hand)

You are approaching this the wrong way. What you have here is the ciphertext. This means that the most frequent letter in each block will (or should) correspond to the most frequent letter in the cleartext. With a long enough text, you can assume that this is the letter 'E'. The most frequent letter in each position is not the letter of the keyword.

This means that you can find each letter of the key using the most frequent letter at a position and its offset from the letter 'E'. Knowing that the letter 'A' will give you a offset of 0, and the letter 'Z' will give you a offset of 25, it is trivial to guess the original key.

However, this only works for longer texts, since the letter distribution is easy enough to mess up in shorter ones. Using the cleartext from your question, the most frequent letter is, in fact, 'O', not 'E'. In addition, because the text is so short, the letter frequencies at each of the positions of the key are even more skewed.

I am not sure how you managed to decode this automatically. The only way I can think of would be to check for dictionary words in both the key and the resulting output, ignoring any keys which do not make sense.

In general, the Vigenere cipher can be cracked easily for longer texts with shorter keys. If you have a short text (like here), or a longer key, then it gets harder. Ideally, you would use a random key that is longer than the plaintext, so it never repeats, which guarantees that the ciphertext cannot be decoded without the key.


What types of trade-offs are appropriate when using encryption/authentication on devices with low bandwidth?

This is a really big problem, and much more data is needed before rushing in to algorithm selection.  I'm going to offer some suggestions, but I expect a good answer for you will need more focus.

First, public key cryptography is good for key exchanging between parties where there's an outside establishment of trust.  Public keys can be delivered on certificates, and certificates can be validated against a trusted root certificate issued by a certificate authority.  But as you've noted, this can take a lot of bandwidth and CPU, two things in short supply in a tiny embedded device.  RSA would probably be a poor choice; Elliptic Curve Cryptography (ECC) exchanges fewer bits and generally computes faster than RSA.  A paper comparing the two on an ATmega128 is available here; their bottom line is ECC secp160r1 can be computed in 0.82 seconds requiring 4k of memory, while their 1024-bit RSA implementation took 11 seconds and 7.4k.

But public key crypto is not normally used for the byte-by-byte communication; it's generally only used for key exchange for a symmetric encryption algorithm. Ordinary communications are protected using a self-synchronizing stream cypher.  These cyphers resynchronize themselves in case of a transmission error or data corruption without needing another expensive key exchange.

Given what you've described, it sounds like you'll only have pairs of devices, or possibly a peer-to-peer network instead of a server-client environment; there may possibly be a 'master' device available.  Are you planning on a 'pairing' step to introduce devices to each other in a trusted environment?  Do they have to pair to the master device, or can they pair with a neighbor dynamically?  Do your users have a setup step for each device? Is there an interface where the end users can inject each device with a secret key?  Are you customizing chips for each customer?  Or is every chip identical, with no differences between any of them?

If these are to be deployed generically to all your customers, they need to be secure against tampering.  You don't want an attacker just reading the memory out of your chips with a JTAG reader.  Even so, there's probably little hope of truly securing the communications, as reverse engineering chips and protocols is a hobby for many people.  This would limit the amount of trust any device should place in the communications, meaning "don't use these devices to secure your building door locks, piles of money, trade secrets, burglar alarms, or other valuables."  This may indicate that simple, light-weight obscurity might be enough -- it may not be worth investing in securing the communications given a motivated attacker.

But let's assume for the moment that you have some kind of key injection step that customizes chips for each customer.  In that case, a pre-shared key might be a good way to go, where the same key is injected into each device, either during manufacture or at the customer's site.  This eliminates the need for a key exchange during communications.  You simply use the PSK to encrypt the data as it leaves, and decrypt the data as it arrives, using the self-synchronizing stream cypher.  Also, consider the case where the customer wants to change keys - maybe someone stole one of their devices and they consider the key compromised.  Customer site injection is a lot cheaper than sending the chips back to you.

If there's some kind of pairing step available between devices, where you introduce them to each other in a trusted environment, you can use this introduction period to exchange keys.  Each network would have a base key, and each chip could get a copy.  Typically this is done with a hardware-activated switch to prevent a rogue network injection of a key exchange request.  If an attacker wants to break in, they have to be physically operating the device.

For higher security there's a protocol called DUKPT that is designed for protecting financial transactions.  Each device is injected with a unique key derived from the base key, and a unique key is derived for each message sent.  No end device ever receives the base key, so compromising one device does not compromise the network.  As this was developed for cheap terminals in the 1990s, the CPU and message overhead is fairly small, making it good for embedded devices. But all communications have to originate at the client devices, and be forwarded to a decrypting server; there is no provision to communicate securely from peer-to-peer, and the key exchange is unidirectional from the client to the server.

Keep in mind there's usually nothing technically stopping an attacker from 'acquiring' one of customer A's devices after it has a key -- theft, maintenance, or even shipping errors can leave the devices to turn up on eBay some day.  The attacker could then use his unauthorized device to communicate with the authorized device.  This is a reason you'd need to be able to exclude a device or reset the network's base key.


Is it safe to allow arbitrary image formats in comments?

As long as your server and client are up to date, codes, standards, and framework safety: Yes...

If they're older: No!

Just to be safe: !!!NO!!!

There were a few old bugs that caused issues with this sort of thing on both ends, so we'll approach them both that separately.

Server Side Issues:

Probably not what you're asking for, but I wanted to make sure this gets addressed as well.

In the olden days of flat file servers with upload areas, and some other server side protocols/programs this introduced one very large problem. That problem was the dreaded script injection. By uploading this malformed image they were actually uploading a script that they could then access, and use to gain control of the server, and subsequently a vector of attack against clients as well.

Newer frameworks however have protection for this built in, and if your server programmer is worth anything then they should know about these types of attacks and how to guard against them. This is still a problem even to this day in bad roll your own servers some people keep doing. These programmers may be smart programmers, but sometimes this just falls through the cracks.

On the client side:

For their safety and security, no. It is NEVER okay to allow arbitrary formats for anything. In fact it is never okay to allow a user to do anything arbitrary at all. There is a reason for this, and it is considered a security best policy:

  Assume ALL content you personally have not produced to be dangerous

Because of that reason, you should never allow it. Why? Because just like the content being somewhat out of control, client browser versions are completely outside your control. This means that a well meaning person could connect to the place the image is, and get hijacked. Someone would be using your code, website, and functionality to ruin another persons life. You don't want that to happen.

The tentative Yes...:

This isn't such an issue as long as the web/server developer is willing to put in the time, effort, and functionality to safe guard against these attacks and can guarantee that they and their clients are safe from these code injections. That's a lot of work though, so it's a lot easier(not to mention safer for everybody) to just say no.

(you can't tell but the ellipses is italic too...)


SQL has the same vulnerability than all other dynamically interpreted programming languages (this includes shell scripts, Javascript, PHP...), which I call "data is code". Such languages have a concrete syntax which is meant for human consumption ("select * from users where...": words and signs which the human brain grasps). Their processing entails a first step which is called parsing: the sequence of characters is broken down into an internal structure which describes the meaning of the expression, in a way which the computer can use efficiently. Parsing is a well-known subject but even if algorithms for it have been known for decades, it is still relatively complex for the human programmer.

When a language is dynamically interpreted, it makes it seductively easy to build the expression from dynamically obtained parameters. E.g. "select * from users where id = $paramIdFromWebForm;". SQL injection vulnerabilities hide there. The problem is fundamental: by building the expression in the concrete syntax, the programmer is doing an ad hoc reversal of the parsing. To make such things robust, the programmer must master all of the subtle ways by which parsing operates; he must think of every dark corner of the language specification. Many programmers think of it in terms of "must escape dangerous characters", and work on the assumption that the few dangerous characters they could think of indeed represent all the "dangerous characters" that could ever exist. This leaves the door open to a lot of issues, in particular when the Web site developer, his programming framework, and the database behind it, do not fully agree on what a "dangerous character" is, and such problems are prone to happen for a lot of reasons, including simple software updates.

See for instance this question for an example of the kind of things which is not captured by the "character escaping" mental framework. Whenever I see the functions mysql_escape_string() and mysql_real_escape_string(), my eyes bleed, and I wonder if there is not somewhere a function called mysql_really_escape_string_this_time_I_said_please().

Nonetheless, there is a proper way to build SQL expressions dynamically without getting into the "data is code" issues: parametrized expressions. This is about working with the abstract representation of the SQL code, the one after parsing. When we use parametrized expressions, we do not try to reverse the parsing step, and security is much enhanced (and it is good for performance, too).

So it is not really SQL's fault; the programmer is still to blame, for not using the right solutions which exist and are documented. We may still consider that SQL designers, and, in particular, the people who integrated SQL in PHP, should have made some effort to make dynamic SQL expression building a bit harder when parametrization is not used. For a better language design (with regards to this specific issue), see LINQ: it keeps the syntax where it belongs, i.e. in the source code, not in runtime-interpreted character strings.


Typically, one maintains a (mostly offline) root CA and then signs a certain number of intermediates to actually issue end-entity certificates.  With this approach, you ship the root CA in the certificate package for your system using a configuration management approach (e.g., on Debian, a custom ca-certificates package distributed via Puppet).
As for the end-entity keys and certificates, usually these can be distributed via something like Vault.  Vault, in fact, has support for running your own PKI.  It can also be used to ship globally trusted certs to systems.  You can automatically deploy systems every N days to rotate keys (or otherwise guarantee frequent deployments or certificate reloads); that can easily be handled by service teams as a requirement for deployment.  The certificate management can be done with Vault or other secret-handling tooling by the security team.