Trusting a fraudulent/not trusted CAs for STARTTLS/SMTP

It depends.

Basically you have the choice to:

Always require a valid certificate. This obviously means you have to disable fallback to plaintext and enforce TLS use. This will prevent some servers and the people using them from sending you mail.
If you can't enforce to use TLS, it doesn't make any sense to enforce a valid certificate. A encrypted connection with a invalid certificate is still better than no encryption at all.

If you use the second approach, it makes sense to enforce TLS for some domains. One thing is to only allow TLS connections for domains with valid DNSSEC/DANE data. For postfix this could be set with:

postconf -e "smtpd_use_tls = yes"
postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"

You can also add some domains which send mails regularly to you to a list and enforce TLS with valid certificates, if you know they support it.


How is security of server's RSA private key is ensured?

For best security, the private key should be held in an HSM (or Smart Card implementing a minimal HSM). It is hard to extract the private key from that, especially remotely, except for a bug or backdoor in the configuration or implementation of the HSM. That's because all good signature (resp. encryption) algorithms have the property that no matter how many signatures (resp. decryptions) one obtains, it is impossible to deduce the private key or a complete functional equivalent of that.

The HSM is also valuable because it is security evaluated, including against side-channel attacks like timing, and intrinsically invulnerable to others (like, leaks from one VM to another due to supervisor bugs, or physical CPU cache states). An HSM typically comes with means to enforce administrator/operator roles; put the HSM (typically, by default) in a safe (non-operative) mode; zeroise sensitive data on some attacks; do encrypted backups of keys; sometime, log operations. Also, some HSMs provide a significant performance boost compared to software-only solutions.

However, an attacker that gets root access to an host with HSM while it is operative, can potentially make signatures or decryptions (the HSM only makes it necessary for the attacker to have a few HSM-specialized skills). Therefore, an undetected persistent intrusion on a machine using an HSM is nearly as good to an attacker as getting the private key; and in most signature cases, revoking the private key is necessary if an attacker had even temporary access to it, so the fact that the private key can't be extracted is moot.


Is it dangerous to post my MAC address publicly?

Disclosing the MAC address in itself shouldn't be a problem. MAC addresses are already quite predictable, easily sniffable, and any form of authentication dependent on them is inherently weak and shouldn't be relied upon.

MAC addresses are almost always only used "internally" (between you and your immediate gateway). They really don't make it to the outside world and thus cannot be used to connect back to you, locate you, or otherwise cause you any direct harm.

The disclosure can be linked to your real identity since it might be possible to track you using data collected from WiFi networks, or it can be used to falsify a device's MAC address to gain access to some service (mostly some networks) on which your MAC address is white-listed.

Personally, I wouldn't really worry about it. However, when it's not inconvenient, I usually try to redact any irrelevant information when asking for help or sharing anything.


security implications of Java's System.load vs System.loadLibrary

Relying on the calling system to help locate things can certainly lead down odd paths. The biggest problem is that the system may provide a file that wasn't intended to be loaded by the application. If an attacker can place a file in a location that falls under the search, then the attacker can inject arbitrary code into the application and execute it. E.g. an arbitrary code execution vulnerability (http://en.wikipedia.org/wiki/Arbitrary_code_execution).

If you specify the exact path, you have the ability to protect the loaded file through things like file permissions, etc.


This makes it hard to obtain positions in the field and mid-level industry certifications with work requirements due to the lack of directly related experience.

Security is a hot field so there are no shortage of players in the market looking to capitalize on this by getting into the certification space. Be careful what you sign up for.

SANS stuff is expensive but always respected. (This doesn't mean it's good, just that it's a useful credential)
OCSP is supposedly brutal and separates the men from the boys, but nobody in a position to hire you will have ever heard of it.
CEH/Security+ is a joke (see above warning; both are beneath you and exist only to siphon DoD 8570 money).

The insult to people like yourself is that you went to the trouble of getting a Master's, yet the implication is that you're not qualified unless you also go out and buy an overpriced certificate and pay to maintain it.

  How does one break into the cybersecurity industry given this scenario?

Start by being more specific and focus on that. There is no job title of "cybersecurity." But there is application security, network security, malware analysis, digital forensics, penetration testing, security engineering, security analysis, etc.

Then, relocate. Are you in middle America? Get out. Go where the financial and defense industries are, typically on either coast. Many of the security vendors who sell to them are located in California (San Jose, Sacramento, mostly northern). Go where the market is.

With a degree in something as broad as "cybersecurity," you've aligned yourself with the management track. Pursue that. You'll probably need a SANS cert. If you don't want to be management, pick a particular niche of security and beef up your technical skills in that domain (ex. for network, go the CCNP/CCIE route).

Not that it's impossible, but most people who end up in mid-level security-related positions did not start there. They tend to cut their teeth in a more technical domain first and build from it-- networking experts who've seen enough threats in the field to know something about it, developers who know how to break applications because they've spent enough time building them, etc. Myself, I cut my teeth as a sysadmin dealing with threats to infrastructure as a matter of course-- trial by fire.

I don't have any certifications. It hasn't stopped me from progressing in my career on either coast. The only qualification I don't have that has actually impacted me is lack of a security clearance-- it makes it very hard to get anywhere in the defense industry.


Consequences of trusting a PC from my iPhone

This largely depends on what you clicked on.

If you entrusted your computer with access to Bluetooth ... who knows.
If you entrusted your computer with access to USB ... your
probably fine.
If you entrusted your computer with access to your
icloud ... theoreticly your IS dept could gain access ... but I
really doubt they will care enough to.


I suppose, the best way would be to ask the user to remember/store the key himself. And ask the key each session for encryption/decryption. Therefore there is no trusted server, which may be attacked.
The keys may be synchronized using the Diffie- Hellman


Why is root security enforced but $HOME typically unprotected?

I'm going to disagree with the answers that say the age of the Unix security model or the environment in which it was developed are at fault.  I don't think that's the case because there are mechanisms in place to handle this.

  The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data.

The superuser's permissions exist to protect the system from its users.  The permissions on user accounts are there to protect the account from other non-root accounts.

By executing a program, you give it permissions to do things with your UID.  Since your UID has full access to your home directory, you've transitively given the program the same access.  Just as the superuser has the access to make changes to the system files that need protection from malicious behavior (passwords, configuration, binaries), you may have data in your home directory that needs the same kind of protection.

The principle of least privilege says that you shouldn't give any more access than is absolutely necessary.  The decision process for running any program should be the same with respect to your files as it is to system files.  If you wouldn't give a piece of code you don't trust unrestricted use of the superuser account in the interest of protecting the system, it shouldn't be given unrestricted use of your account in the interest of protecting your data.

  Is there no way to prevent malicious code happening in $HOME? And why does nobody care about it?

Unix doesn't offer permissions that granular for the same reason there isn't a blade guard around the rm command:  the permissions aren't there to protect users from themselves.

The way to prevent malicious code from damaging files in your home directory is to not run it using your account.  Create a separate user that doesn't have any special permissions and run code under that UID until you've determined whether or not you can trust it.

There are other ways to do this, such as chrooted jails, but setting those up takes more work, and escaping them is no longer the challenge it once was.


Is it possible to tell when a remote bitmessage client is creating new messages?

PyBitmessage has random forwarding delays, so you won't necessarily receive a message first from the node it originates on. You can increase your anonymity by using a passive node (not accepting connections), and/or by using Tor. Of course, we're trying to improve anonymity even for the rest of the cases.


There's no one (normal) process that would be causing ARP to happen - a process might ask for a connection to an IP address, but then it's the network stack's job to figure out how to get it to another machine, and that's when ARP happens.

Your best bet is to figure out where the machine is connected, switchport wise, from your switch.  Either via the switch's interface or via SNMP via the IP net-to-media table.  Then you can chase wire and find the beast.

Since it's just Windows, you might have a WINS server that got elected master, or something like that, but that's purely a stab in the dark.


How to convert a certbot certificate private key to "Unencrypted PEM encoded RSA"?

I find out I can use openssl to convert the format

  openssl rsa -in  ./letsencrypt/live/mycompany.com/privkey.pem  -out  ./letsencrypt/live/mycompany.com/privkey.pem.rsa.key


Can the intended recipient be derived from a public-key encrypted ciphertext?

It depends on a lot of things.

Let's consider a message encrypted by OpenPGP, the most used encryption standard.  By default, it includes in plain text a field containing the key ID the message has been encrypted to.  However, note that the OpenPGP standard allows for this field to be empty i.e. containing a key ID = 0x0.  So the correct answer to your question is "It depends, if you have a ciphertext encrypted with OpenPGP it might be possible to find out the recipients."


Is there any particular reason to use Diffie-Hellman over RSA for key exchange?

The situation can be confused, so let's set things right.

RSA is two algorithms, one for asymmetric encryption, and one for digital signatures. These are two distinct beast; although they share the same core mathematical operation and format for keys, they do different things in different ways. Diffie-Hellman is a key exchange algorithm, which is yet another kind of algorithm. Since the algorithms don't do the same thing, you could prefer one over the other depending on the usage context.

Asymmetric encryption and key exchange are somewhat equivalent: with asymmetric encryption, you can do a key exchange by virtue of generating a random symmetric key (a bunch of random bytes) and encrypting that with the recipient's public key. Conversely, you can do asymmetric encryption with key exchange by using the key resulting from the key exchange to encrypt data with a symmetric algorithm, e.g. AES. Moreover, Diffie-Hellman is a one-roundtrip key exchange algorithm: recipient sends his half ("DH public key"), sender computes his half, obtains the key, encrypts, sends the whole lot to the recipient, the recipient computes the key, decrypts. This is compatible with a one-shot communication system, assuming a pre-distribution of the public key, i.e. it works with emails.

So for the rest of this answer, I assume we are talking about RSA encryption.

Perfect Forward Secrecy is a nifty characteristic which can be summarized as: actual encryption is done with a key which we do not keep around, thus immune to ulterior theft. This works only in a setup in which we do not want to keep the data encrypted, i.e. not for emails (the email should remain encrypted in the mailbox), but for data transfer like SSL/TLS.

In that case, to get PFS, you need to generate a transient key pair (asymmetric encryption or key exchange) for the actual encryption; since you usually also want some sort of authentication, you may need another non-transient key pair at least on one side. This is what happens in SSL with the "DHE" cipher suites: client and server use DH for the key exchange, with newly generated DH keys (not stored), but the server also needs a permanent key pair for signatures (of type RSA, DSA, ECDSA...).

There is nothing which intrinsically prohibits generating a transient RSA key pair. Indeed, this was supported in older versions of SSL; see TLS 1.0, section 7.4.3. In that case, use of an ephemeral RSA key was mandated not for PFS, but quite the opposite: so that encryption keys, while not stored, could be broken afterwards, even if the server's permanent key was too large to be thus brutalized.

There is, however, an advantage of DH over RSA for generating ephemeral keys: producing a new DH key pair is extremely fast (provided that some "DH parameters", i.e. the group into which DH is computed, are reused, which does not entail extra risks, as far as we know). This is not a really strong issue for big servers, because a very busy SSL server could generate a new "ephemeral" RSA key pair every ten seconds for a very small fraction of his computing power, and keep it in RAM only, and for only ten seconds, which would be PFSish enough.

Nevertheless, ephemeral RSA has fallen out of fashion, and, more importantly, out of standardization. In the context of SSL, if you want PFS, you need to use ephemeral DH (aka "DHE"), because that's what is defined and supported by existing implementations.

If you do not want PFS, in particular if you want to be able to eavesdrop on your own connections or the connections of your wards (in the context of a sysadmin protecting his users through some filters, or for some debug activities), you need non-ephemeral keys. There again, RSA and DH can be used. However, still in the context of SSL, non-ephemeral DH requires that the server's key, in its X.509 certificate, contains a DH public key.

DH public keys in certificates were pushed by the US federal government back in the days when RSA was patented. But these days are long gone. Moreover, DH support was never as wide as RSA support. This is indeed an interesting example: DH was government approved, and standardized by an institutional body (as ANSI X9.42); on the other hand, RSA was standardized by a private company who was not officially entitled in any way to produce standards. But the RSA standard (PKCS#1) was free for anyone to read, and though there was a patent, it was valid only in the USA, not the rest of the world; and in the USA, RSA (the company) distributed a free implementation of the algorithm (free as long as it was for non-commercial usages). Amateur developers, including Phil Zimmerman for PGP, thus used RSA, not DH. The price of the standard is nothing for a company, but it can mean a lot for an individual. This demonstrates the impetus that can originate, in the software industry, from amateurs.

So that's one advantage of RSA over DH: standard is freely available.

For security, RSA relies (more or less) on the difficulty of integer factorization, while DH relies (more or less) on the difficulty of discrete logarithm. They are distinct problems. It so happens that the best known breaking algorithms for breaking either are variants of the General Number Field Sieve, so they both have the same asymptotic complexity. From a high-level view, a 1024-bit DH key is as robust against cryptanalysis as a 1024-bit RSA key.

If you look at the details, though, you may note that the last part of GNFS, the "linear algebra" part, which is the bottleneck in the case of large keys, is simpler in the case of RSA. That part is about reducing a terrifyingly large matrix. In the case of RSA, the matrix elements are just bits (we work in GF(2)), whereas for DH the matrix elements are integer modulo the big prime p. This means that the matrix is one thousand times bigger for DH than for RSA. Since matrix size is the bottleneck, we could state that DH-1024 is stronger than RSA-1024.

So that's one more advantage of DH: it can be argued that it gives some extra robustness over RSA keys of the same size.

Still for security, DH generalizes over other groups, such as elliptic curves. Discrete logarithm on elliptic curves is not the same problem as discrete logarithm modulo a big prime; GNFS does not apply. So there is not one Diffie-Hellman, but several algorithms. "Cryptodiversity" is a good thing to have because it enables us to switch algorithms in case some researcher finds a way to easily break some algorithms.

As for performance:

RSA encryption (with the public key) is substantially cheaper (thus faster) than any DH operation (even with elliptic curves).
RSA decryption (with the private key) entails more or less the same amount of work as DH key exchange with similar resistance. DH is a bit cheaper if it uses a permanent key pair, but a bit more expensive if you include the cost for building an ephemeral key pair.
In the case of SSL and DHE_RSA, the server must generate a DH key pair and sign it, and the signature includes the client and server random values, so this must be done for each connection. So choosing "DHE_RSA" instead of "RSA" kind-of doubles the CPU bill on the server for SSL -- not that it matters much in practice, though. It takes a very busy server to notice the difference.
A DH public key is bigger to encode than a RSA public key, if the DH key includes the DH parameters; it is smaller otherwise. In the case of SSL, using DHE_RSA instead of RSA means exchanging one or two extra kilobytes of data -- there again, only once per client (because of SSL session reuse), so that's hardly a crucial point. In some specialized protocols, ECDH (with elliptic curves) gets an important edge because the public elements are much smaller.

If you are designing a protocol in a constrained situation (e.g. involving smart cards and I/O over infrared or anything similarly low-powered), ECDH will probably be more attractive than RSA.

Summary: you will usually prefer RSA over DH, or DH over RSA, based on interoperability constraints: one will be more supported than the other, depending on the context. Performance rarely matters (at least not as much as is often assumed). For SSL, you'll want DH because it is actually DHE, and the "E" (as ephemeral) is nice to have, because of PFS.


As for the DNS: normally, the principle of the SOCKS protocol is that when a client wants to connect to server example.com on port 80, it sends through the tunnel the message "please open a connection to port 80 of example.com and forward the bytes back and forth", so the name example.com will be resolved on the other end of the tunnel (here, your home router). As @M'vy indicates, Firefox can do otherwise, in which case one has to assume that the SOCKS message will talk about the resolved IP address.

As for the corporate proxy, it works as it would work for SSL: the browser sends a "CONNECT" order to the proxy, with a target name and port, and asks the proxy to propagate bytes in both directions. In your case, the corporate proxy believes that it is forwarding some SSL connection, but in fact this is some SSH. The proxy is still "on the outside" cryptographically speaking; it won't see the data, and, in particular, it won't even know which sites you are browsing. The corporate proxy sees one quite busy connection, between your desktop system and your home router.

Note, though, that SSH and SSL protocols do not use the same kind of headers, so the corporate proxy may notice that what goes through it is not SSL (even though it uses the traditional HTTPS port 443) but really SSH. Depending on the surveillance tools and the sysadmin efforts, the proxy may decide that things are fishy and raise an alert.


Is there a point in randomizing my WPA2-Personal SSID (meaning, set a random string in place of the SSID)?

Using a strong password is enough. If you use a pseudorandom password of 19 characters, that will give you a key with about ~113 bits of entropy. NIST requires symmetric keys of at least 112 bits so you should be fine with a 19 character pseudorandom alphanumeric password, even if the password is being cracked on a supercomputer.
In fact, normally, your WiFi AP broadcasts its SSID, so it is already known to the attacker. Therefore it adds no entropy to your PMK (it is included only as a salt) and there is no point in keeping a long random SSID.


Network Sniffing Java Applet Authentication

The answer is it depends on how the Java Applet works. If it needs to connect back to a server to check the userid and password entered are correct, then I think it is in clear text. If it doesn't connect back to a server (since a Java Applet runs locally) then there's no opportunity for sniffing or man in the middle attack.
You can use Fiddler 2 for packet sniffing.


Create netcat listener and execute reverse shell in the same script

Typically, you would just start the listener separately: Open a new terminal and run your nc -l -p 9999. Leave that there waiting, then fire off your exploit causing the remote machine to start a reverse shell.

There are loads of things that can go wrong in this process, generally just binding a shell is much easier than getting a reverse shell to work when you're blind.

You need to open a listening socket, and then interact with it once it has received a connection.

So, first open your listening socket (this replaces netcat)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('0.0.0.0', 9999))
s.listen(5)

You can use a simple interact function that takes a socket:

def interact(sock):
     command=''
     while(command != 'exit'):
         command=raw_input('$ ')
         sock.send(command + '\n')
         time.sleep(.5)
         print sock.recv(0x10000)
     return

Then you can use them together with something like:

interact(s.accept())

This might require some tweaking, but that is the basic layout.


In general, cryptographic techniques assume that the attacker knows everything about your scheme except for the secrets.  This is Kerckhoff's Principle.  That means that the attacker knows the techniques you use to generate the secret and the size of the set.
Under this principle, you need to generate the secret securely and from a large enough set, that is, with at least 128 bits of entropy.  Using a non-cryptographic PRNG won't be suitable for this because it's easily guessable.
If your goal is to generate some sort of verifiable token, you can use HMAC (with a cryptographically secure hash, such as SHA-256) to take your secret and hash any additional data you want (such as your salt) to generate the token.  If you just need a completely random token, then you can just use a CSPRNG.
Note that it is secure to generate a token with an increasing ID using HMAC as long as your secret is secure: token = N || HMAC-SHA-256(secret, N).  This is also true for any other non-secret contents in place of an integer.  HMAC is better than using a plain hash because it avoids length-extension attacks on common hashes.
Even if you think nobody will know if you use a non-CSPRNG, under your scheme, if someone knows the data being hashed other than the seed, they can brute-force your scheme to recover the weak seed and forge tokens.  Note that modern CSPRNGs can be faster than non-CSPRNGs, so there's really no reason not to use the right tool for the job.


It is certainly possible. See this presentation for example: http://www.coresecurity.com/files/attachments/Persistent_BIOS_Infection_CanSecWest09.pdf

One way to achieve protection is by requiring a flash bios password that some implementations support.

Another way is by using a TPM which does almost exactly what you are suggesting: It creates a SHA-1 hash of the BIOS image before loading it - and if Secure Boot is enabled it compares it to a stored value.

Now, how to check if the BIOS is compromised:

The general idea is that you can take a BIOS backup image at any time and compare the hash of that image to the hash of a previous one - maybe one you took after flashing.

But, in theory, if the BIOS modification is malicious enough, it will serve you something that won't be suspicious - so you won't actually be able to check but only just re-flash (and this may not be enough if the flash procedure itself uses bios functions that are hooked).
Generally to check the integrity of anything, you have to perform the checking operation at a level lower that the level of the object you check. With BIOS this is pretty hard - and this is one of the reasons TPMs were invented.


The problem is that the encryption operation is rather efficient and thus passwords can be efficiently bruteforced. Its better to use existing standards which do exactly what you're describing but in a safe (and often already implemented) way, like in http://en.wikipedia.org/wiki/PBKDF2


It is possible for USB drives to have firmware-embedded malware, see this BadUSB article which shows the research. There would be no way to get rid of firmware-embedded malware, formatting would have no effect on it at all. However, it's pretty new, and therefore very, very unlikely that you would run into it. It's probably something someone dropped by accident, although found devices can have deliberately installed malware on them for the unsuspecting. These can be targeted on individuals (drop it by a CFO's car door) or companies (strew them around a coffee shop or company car park) or at random (drop them on the floor of the downtown bound 2 train).

Assuming your perfect sandbox you could examine the content and reformat it with almost certain safety. That perfect sandbox doesn't really exist though, so it would make sense to boot a virtual system from read-only and save nothing from the session.


HTTP Response to a SAMLResponse POST by user agent

I think you refer to the descriptions like "returned in HTTP Redirect URL to SAML responder, encoded into Location header". This talks about a normal redirect at the HTTP level, which consists of a Location header in the HTTP response header and a status code of 3xx, specifically 301, 302, 307 or 308. There are no semantics defined for a Location header with status code 200.

For more see RFC 7231, 7.1.2 Location and RFC 7231, 6.4 Redirection 3xx.


This behavior will likely vary by browser.

With regards to Chrome I believe (at least for passwords) these values are displayed as entered but are not initially available to Javascript provided by the site. The moment you interact with the page (like clicking anywhere inside of it) it is.

I believe for IE / Firefox (as of late last year) the values were made available immediately so would suffer the issue you stated.


How can files be deleted in a HIPAA-compliant way?

1) With modern filesystems, there is no more concept of securely deleting an individual file. It might have been copied around, snapshotted, written to a different location upon editing, etc.

2) With modern drives, there is no deletion / wipe without confirming it. Some drives have had a Secure Wipe command flat-out lies to you, returning immediately while doing nothing.

See SSD (Flash Memory) security when data is encrypted in place
Use Full Disk Encryption.
Pretty much forget about the concept of securely deleting a file and knowing it is really gone. Even with a freespace wipe, you've still got cache files, preloads, snapshots, slack space (though some utilities wipe that)...


Which SSH security is stronger? 2 Factor or Public key

This is not a "one is better than the other" issue. Both increase the burden of an attacker to break into your system:

Using (and enforcing) keys increases the "quality of the password" ("mypassword123" vs "long_binary_asymetric_keypair_here"). Humans are very bad at remembering long passphrases with good entropy.
Using 2Factor auth ensures that an attacker would have to get 2 properties under control: one password-mechanism (usual passwords, PK) and another one which is (usually) not at the same physical location as the first one. With 2Factor mode the system you are trying to authenticate against will challenge you a second time after you succeeded at the first challenge. But if both challenges are silly / simple / easy to break the whole 2Factor thingy is pointless.

So, both mechanisms supplement each other.

Good tutorial on the 2Factor part:

http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

Combine that with any other tutorial which explains how to use ssh-keys (and there are LOTS in the internets). The flow of the authentication is then as follows:

Client triggers mechanism to unlock the private ssh-key (password) on his machine
Client contacts Server to ensure public and private key match. From here on the ssh-server is basically not involved in the authentification any more.
Server routes Client to the second challenge
Client responds to the second challenge correctly
Client gets access to the shell on the Server


Advantages of client certificates for client authentication?

Deploying client certs could fit here.  The advantages of using a cert over username is somewhat simple.  Anyone can type in a username from any client device.  If you're using a combination of username with guid, then the "security" or assurance that the client is connecting from a known/authorized client device is dependent on the strength and uniqueness of the guid.  If there's a way to clone or spoof the guid (mac addresses can be spoofed fairly easily), then the assurance level would decrease.

Client certificates can be deployed to clients, with or without validity checking (aside from validity date, cn, ski/aki, fingerprint, etc).  On-demand validity checking mechanisms such as ocsp would require the server application check with an ocsp server each time client connects/attempts to auth.  But from the description, I didn't read that validity checking is as important as being able to tie cert to client device.

One important detail with clients certs (certs in general) is that is can be exported and most implementations do not lock down portability of the cert.  Regardless of whether or how the client certs are going to be stored, without proper measures, the cert can be easily copied from device to device.  Some implementations store the cert on the filesystem (files that end with .cer, .der, .key, .crt usually are indications that certs are stored in the filesystem).  Stronger implementations (application dependent) may store the certs and keys in a keystore (i.e. java key store).  The key store can add additional protection like ensuring the private key is not exportable.  However, the assurance that the key hasn't been exported is only as strong as the key store itself.  Hardware key stores (i.e. smart cards, usb hsm, ironkey, etc) offer a much stronger assurance that private key is not exportable than software key stores.

BTW, the above point also affects server keys.  Most implementations store the private key in a software key store and is usually marked exportable.  Further, the private key is usually not password protected so anyone with access to the server can walk away with the private key.  If a cert can be copied, then it doesn't offer non-repudation.

To answer your question, if there's a good way of leveraging a hardware id of sorts (guid, serial number, cert stored in HSM, etc), that'll likely provide more assurance than using a software-based id (client certs included).  Using client certs with password protection enabled for private key access provides a bit stronger validation because not only does a client need to have access to the private key but also the password to use it.

If you do decide to use client certs, then you'll have to build or use an existing PKI infrastructure.  Vendors like Codomo, Entrust, Symantec (formerly vrsn, thawte, and geotrust), Godaddy, and a bunch of others offer both public and private infrastructure for use.  However the cost of implementing a software-based client cert will likely be higher than using a software based hardware id or perhaps even a hardware-based unique id.

If anything, determine the level of assurance you want to have and decide whether software, software + password, or hardware is sufficient.


Is it a bad idea to bypass login wall for a specified IP address?

You don't have to worry about spoofing the IP from a different connection, because returned TCP packets would not make it to the attacker in that scenario.

So all you have to worry about is how easy it is for the attacker to make use of that IP:

Is that IP shared between multiple computers in the office?
Can that IP be used on WiFi? How well is the password kept when a visitor says 'can I use your WiFi'?
Are all the computers with access to that IP well secured, and have competent users?

If the IP is not well kept, then you should ask

In addition to IP, can you have a cookie stored on the single machine that is authorized?
(i.e. a limited-use Remember Me feature)

I commend your client for not using the Remember Password feature as is so tempting to do.

Also, how secure is your content?

What are the damages of the content being viewed by unauthorized persons?
What type of attackers would be attracted to your content?


how to circumvent ASLR without pointer leaks

There are ways, but they depend on the context of exploitation. No one size fits all I'm afraid. Some example techniques of bypassing ASLR;
- Partial address overwrite
- Brute force
- Using non-ASLR libraries.
- Non-PIE binaries
- Forcing a non-ASLR library to trigger
- Heap spraying

I'm sure there are more techniques I missed. But life is a lot easier if you can get a memory leak.


nginx - How to prevent processing requests with undefined server names with HTTPS

I've solved it by generating a fake certificate that doesn't reveal domain name and adding it as a default one on the start of the config:

server {
    listen 443 default;
    server_name     _;

    ssl     on;
    ssl_certificate         /path/to/fake.crt;
    ssl_certificate_key     /path/to/fake.key;

    return 403;
}

And yes, it requires a nginx with SNI support (check nginx -V).

Follow on:
How to create self signed SSL certificate for test purposes


Is passwords with combination of different encodings super safe?

If the length of the password is not reduced, then I'd say it will be harder to crack, though I wouldn't call it "super safe". Take for instance a 16 character ASCII password: there are (2^7)^16 = 2^112 possibilities for such a password (also called 112 bits of entropy, assuming all 128 chars are equally probable in a "random" password). A 7 character Unicode password encoded in UTF-16 for example (cover the whole set) would have about (2^16)^7 = 2^112 possibilities - the same strength as before.

For that reason, just increasing the length of the password will offer the same protection against brute force attacks. With the advantage that the password will be easier to type, and won't cause problems if entered in systems with different default encodings and input methods.

I'd like to add, though, that for that math to hold the passwords must be truly random. There are other types of attacks (like dictionary attacks, rainbow tables etc) that take advantage of different probabilities in the distribution of characters in a password. Since, by your question, you seem to be generating those passwords, I think you can do fine without using different charsets.


Google Chrome says "Your connection to example.com is encrypted using an obsolete cipher suite."

Alright, here we go:
Question 1

TLS 1.0 is not quite perfect. See the answers to this question for details.
3DES is somewhat odd these days, but still okay, nonetheless depricated by AES.
using RSA as a key exchange mechanism fails to provide forward secrecy.
using SHA1 is okayish right now but expecected to be broken any time, hence there is the SHA2 family available for quite some time already.

Question 2
Well, the developers of Chrome chose to accept this and show a green lock instead of a yellow one (connection established with warnings) for now, as otherwise a lot of sites (banks for example) would fail to show the green lock.
While using that exact combination is not ideal, it's still able to establish a connection, verify the remote machine and the exchanged data is reasonably safe (for now, at least, see forward secrecy link above).
As to how this is established: there is a handshake taking place between the browser and the server, agreeing on a specific cipher suite. Your browser and that server agreed on this one (because either might not support anything newer), even if it's not the best option. See the How does TLS work for good coverage on that.


WPA2 is specified by IEEE 802.11i-2004 [pdf]. I think what you are looking for is in section H.4, "Suggested pass-phrase-to-PSK mapping" on page 165.


What is more safe for browsing the web: PC or smartphone?

First, here I compare an up-to-date Android phone which receives regular updates with a Windows PC which receives regular updates. While this might be the normal case if you buy a PC with Windows 10 it is not guaranteed if you just buy a cheap Android phone. Thus, I assume that you use a vendor and product known for its good product support, like phones from Google or the Android One phones. Even then the phones will only get updates for a few years, which is usually not as long as a PC would get updates. Thus, you might need to replace the phone after a few years with another one.

With this in mind ...
The security features of the underlying OS in terms of protecting the applications itself are basically the same, i.e. both provide hardening of the kernel, offer layered security with sandboxes inside the browser etc.

One major disadvantage of Windows compared to Android is that in Windows all applications started by a  user essentially run as the same user and can thus affect each other. This means that a compromised word document could lead to the installation of malware which could read the password store of the web browser. In Android instead the different apps are more isolated between each other since they are running as different users and data have to be explicitly shared between the applications except for data stored on some common storage where all apps have access.

Another advantage of Android is that applications are usually installed from the Google Play Store and the user needs to be explicitly go into the settings and allow apps from third-party places to be installed. And while Windows has some kind of app store too it is currently common to install apps just downloaded from the internet, from some CD-ROM or an USB drive. This attack vector is actively used to trick users into installing some apps, because they are allegedly needed to view a video on some (usually illegal) video sharing site, allegedly are the security update for Adobe Flash which is needed or similar. While an app store like the Google Play Store might contain bad apps too (and often did in the past) it is still much less likely to get a bad app from the app store than one would get from just downloading something from the internet. And, as explained in the previous point, the harm a malicious application can do in Windows is significantly higher than what it can do in Android.

Additionally entire classes of attack vectors which affect PC's are not relevant on Android phones: there is no Flash, no Java applets, no macros in Office documents, no EXE, SCR, ..., which means many of the typical malicious payloads in mails will simply not work. Credential phishing done through mail or by tricking users when browsing the web is relevant on both platforms though.

One main disadvantage of a phone vs. a PC is the smaller screen size and therefore reduced information and the ways information can be displayed by interacting with the device. For example there is no such thing as hover over a link or click right for a context menu in order to receive more information about the real link vs the claimed link. Often the URL of the visited site is also not shown to save crucial screen space for the actual content.  But, given your intended non-technical audience this loss of information might not be that much of a problem since this kind of audience can probably not deal with this detail of information anyway.

But in summary I think that an Android phone which is currently up-to-date and will be kept-up-to-date (which means buying a new one after some years) is the better choice for a non-technical person with only a few needs in terms of communication, i.e. basically web browsing, mail and messaging.


Implications of running script as argument to shell

Not really. If someone can get you to run a malicious script -- whether with ./scriptname or with bash scriptname -- you're pretty much toast. Also, you shouldn't think of the execute permission as a protection against malware. Execute permission controls whether you are allowed to execute the script (via exec() and its relatives), not whether it is allowed to execute.


How to know if mail is for tracking our IP

You have no way to know. The IP tracking is performed by the server that serves you the image. The server necessarily knows that it served some image file, but you have no way -- as a client -- to know whether the server does anything meaningful with that information, or whether the image load could be traced back to you personally.

If it's a mass email, the image URL would probably have your email address in it (or, more likely, some randomly-generated unique ID that maps to your email in a server-side database). That's so the server knows whose IP they're getting with each image load. (e.g., "Okay, 11.22.33.44 just loaded the URL /images/35fd76a74/track.png... from our records, we sent that URL to foobar@example.com.) However, if an information gathering effort is focused on only you (or the service is very clever in how it encodes unique IDs in their URL), the URL could look perfectly mundane.

In order to decide if an image is used to track your IP address, you'd have to decide whether the server associates the loaded image uniquely back to your email address. Since you don't run the server, this is generally not possible. If some image is known to be widely used (e.g., just a /static/img/header.png that the sender puts in every single one of their emails to many recipients, without any kind of unique ID in the URL) then it's unlikely that that image could be used for tracking: too many people load that same image for the originating IPs of its requests to be uniquely linked back to a particular recipients.

If you fetch the images through an anonymizing proxy, you can hide your IP address. However, a proxy cannot hide the fact that the image was requested at all. The server would still know that /images/35fd76a74/track.png was loaded (and that that unique ID links back to your email address), but they simply don't know what your real IP is.


This is impossible (or, if you really want to nitpick, it can't be done usefully).

Proof: suppose that you were able to detect when one node generates two identities. An entity wants to carry out the attack that the unicity of identity prevents. That entity can create two distinct nodes and have them cooperate to carry out the attack.

You can apply heuristics to try to detect when multiple nodes are controlled by the same identity, but that won't be easy or reliable. You can raise the cost of creating a node, but that only works if the attack isn't a very damaging one.


Does the use of pepper for passwords violate Kerckhoffs's principle?

No. The principle means "The security of a cipher must not depend on the secrecy of the algorithm". Inputs are allowed to be secret. That includes keys, plaintext, and passwords.

Different people use the name "pepper" to refer to different things. I know of at least three. None violate that principle. The first two don't harm security.

The key used to encrypt password hashes and salts.
A second salt that is stored outside the password database.
A second salt that is randomly generated and not stored anywhere. The server and password crackers are supposed to brute force it as part of its password stretching procedure.

Definition one doesn't hurt security. A benefit to this is that it prevents offline cracking if the key can be kept secret.

The key might reside on a HSM, which would mean an extra layer of defense resistant to a lot of attacks.

At worst using encryption like this is equivalent to storing hashes unencrypted. It doesn't reduce security. (Just like using full disk encryption doesn't reduce secrecy.)

Two is no more insecure than normal salted password hashing. If this pepper is unpredictable (remains secret and can't be brute forced) then it prevents offline cracking. It is better than using one salt in certain contexts where hackers gain read only access to only some of your data.

The old justification for this method was that it would provide an extra layer of defense if the only type of access a hacker has is a database dump or SQL injection. Outside of that context it's pointless, but it never hurts security.

Three doesn't violate the principle, but it's inferior to just allowing the original password stretching algorithm more time to run. (Instead of forcing the server to run it more than one time.)

It's less secure if scrypt is used, for example.


Is password protecting a VPN file enough, or do we need to whitelist the connectors IP?

Using an IP as an authentication method is not a great practice. It can be slightly useful as second factor, but it is much better to rely on real authentication methods. IP can be spoofed in many ways, or the attacker may be able to bounce the data from your network, if he compromises a device in it.

I would suggest you use the PKI authentication paired with TOTP. TOTP should be more secure than using a password, as an attacker that can steal the private key will often be able to install a key-logger as well, but that will not help with TOTP. You can add password as a third factor if you want, just to make sure. While the password should be unnecessary assuming employees follow basic security precautions, such as having the phone with TOTP app locked, you should never trust users to do things right.

PS: If you really want to invest into security, you can also use physical tokens. But it should be completely unnecessary in most cases.


Attack scenario when using split tunnel VPN

Since in your specific setup the home office computers are either connected with a full VPN tunnel to the company or have full direct access to the internet (i.e. VPN off), the main point of the VPN is obviously not to protect the computer itself. With such a setup it is still possible that an attacker can compromise the system and establish a permanent presence on it, only to later move further into the companies infrastructure once the full VPN is established.
But a full VPN can make such lateral movement more difficult, in that it might prevent the outside attacker to easily control the compromised system once it is using the VPN. With a split VPN an unfiltered connection to the attacker can be kept while at the same time being connected to the company network. With a full VPN instead only filtered connections to the internet are possible, which ideally prevents access for the attacker. Of course there might still be ways to tunnel the attackers connection but it is more difficult and it is less stealth than before.
Additionally the normal web browser can be used for cross-origin attacks, where one origin is the attacker on the internet and the other the company network. This is because the same browser has access to both networks and can connect to both at the same time, even from within the same web page. This makes for example attacks like CSRF or DNS rebinding possible. See also Attacking the internal network from the public Internet using a browser as a proxy for more such cross-origin attacks.


Can demo exploits/attacks be run on desktop applications?

Are there any applications/tools for exploiting desktop applications? (with pre-built exploits)

Short answer : No

Details : What you ask is a program/tool which will automatically pentest your client Java application. At this date, it doesn't exists. A real and complete pentest needs some security skills and especially a nose for exploitation of vulnerabilities and divert the main usage of functionality available in the application.

I have no details of your application but you need to keep in mind the Top Ten OWASP during your development phase. Fix vulnerabilities after the end of development is more expensive that fix it during development.

This OWASP Cheat Sheet will help you to check and test your application.
This GitHub OWASP repo will be useful after you identify the angles of attack of your application.


Heap canaries, to protect function pointers in heap objects

Canaries within an object run into one practical problem: it changes the in-memory layout of these objects.  This layout needs to be consistent when passed between, say, the program and libraries.  If you passed a pointer of type struct whatever * from a program compiled with this instrumentation, to a library compiled without this instrumentation (but with the same declaration of struct whatever), then things would break, because some of the fields would be at a different offset.  As a result, using internal canaries for anything other than theoretical research would break compatibility with almost all existing code and libraries.


Deploying vulnerable web application online

I suggest you put them on a LAN and your students can surf to them through a VPN setup. It's a lot safer than putting them just on the internet. If you just put them on the internet, you get attention from non-students as well.

You answered your question yourself, a vulnerable application on the internet.

Ok so you need to bear in mind:

jail applications, do not let them be able to even see other folders.
Partition your hard drive so they can only fill a folder where they would have access with an exploit, otherwise they might crash the system
use least privileged principle
Watch out with applications being able to write stuff (I know for instance that with sql injection in mysql one can create a file that generates a php shell)
Monitor and log everything
Limit upload and download
Firewall the machine so they can not set up an email spambot
Limit memory and cpu time
Separate this network completely from your own network
Firewall: whitelist instead of blacklisting


Credentialed scans and the Burp Suite active Scanner

Burp has some relatively complex options available for session handling but in the basic case, the scanner will use sessions from burps "cookie jar", so as long as it knows about a valid session ID it'll use it.

If you invalidate your sessions while the scanner is running (for example by using logout functionality) then the scanner will likely stop working well on authenticated areas of the site (of course assuming here the logout actually invalidates the session on the server-side).

However if you just go to a different site without actively logging out then burp can continue to use the session tokens you had, for as long as they stay valid.

On some sites with aggressive timeouts, this can be a problem but you can use Burps Macro facilities to detect this kind of issue and re-login automatically.


On iOS, what's the benefit of OpenSSL over using CFStream, CFNetwork etc. for secure sockets?

Two things:

you get more control over the encryption options. If you need to control or inspect the certificate exchange in ways not permitted by CFNetwork, you must drop to OpenSSL.
OpenSSL is cross-platform, so you may already have code that works with it.


Nmap with snmp-brute script freezes at 33.33%

Don't specify UDP port as you can see in this example:
https://nmap.org/nsedoc/scripts/snmp-brute.html


How to approach creating a Linux app that requires root privilege?

There's not really one correct answer to this question. It's a trade off between security and usability.

  run command with pkexec each time ( which I kind of want to avoid for the sake of user experience );

If the intended audience does not have "CLIphobia", sudo could be really great here if "each time" is within 15 minutes.

But from a security point of view, I'd recommend pkexec.  I assume it can be trusted as it comes pre-installed with the distro, unlike some quickly hacked up setuid wrapper or daemon.

  since the indicator is in python, I could have a binary with setuid bit set written in C. However, I've been told this approach is frowned upon;

The only problem I have heard of with setuid wrappers is that they can overwrite themselves with a trojan if they exploited, but this is not relevant for setuid-to-/root/ binaries as any exploit on a process running as root means you're screwed anyway.

The only problem I have experienced does not apply to setuid-to-/root/ binaries either, it was so that I did not understand all of unix user ids and forgot to set the real user ID, saved user ID and their group ID equivalents, this meant that a program that /drops/ privileges can still gain them back.

There could be other reasons why setuid wrappers are frowned upon, but I haven't heard of any. If no one else can find reasons why setuid wrappers are frowned upon, a setuid wrapper will be a really good choice.

  start a "proxy" which will run as root and only perform that one specific task , and the indicator will communicate with that "proxy"

If you create a daemon to do the task, keep it as simple as possible and make sure that unauthorized users don't get to communicate with it.

I can think of two options: (1) use a password that an authorized client would know, the daemon does know and an unauthorized client does not know. The password would have to be stored in a file chmoded 400 and owned by root.

(2) use unix permissions on the socket to prevent any other local user to even try to (ab)use the daemon.
https://stackoverflow.com/questions/20171747/how-to-create-unix-domain-socket-with-a-specific-permissions

Option two can be considered less secure and more inconsistent at UX.  The user might not understand why it won't work when they're logged in as a different user which is really bad when it does happen.


Is it possible to use AH in transport mode on an IPSec channel with mediation?

"Proxy" is a generic term. If you mean a Web proxy, then that kind normally operates at the "application data" level: the client system opens a TCP connection to the proxy, and the proxy opens another connection to the target server (or next proxy in case of chaining). The proxy relays data back and forth, but no IP header. By definition, IPSec stops at the proxy. A Web proxy does not "modify" packets, it eats them whole; and then it may resend the packet contents, reassembled and split again, as brand new IP packets unrelated to the previous ones.

You can use IPSec to protect communications between the client system and the proxy. You can use IPSec to protect communications between two proxies. But IPSec will never give you any guarantee that the data was unmodified by the proxy; only that it was not altered in transit between the client and the proxy and/or between the two proxies.

In fact, proxies are, by definition, meant to alter the data, e.g. by answering the request themselves with a copy of an older response, without talking to the actual server. This is by design.


Should I client hash user and password, HTTPS to password_hash on PHP/MySQL server?

I have resolved - this is the process I am following in case anyone is interested.

During initial registration, user enters a login and password. Both are hashed, sent over HTTPS to the server.

Server DB saves the client login hash and the output to password_hash($pass,PASSWORD_BCRYPT, ["cost"=>12]) to the db.

Later, during login process, user enters login and password. Both are hashed, sent over HTTPS to the server.

Client requests server to search DB for the loginhash, retrieves the password_hash output.

if password_verify($clientpass, $dbpass) return true, then password is valid, else false/password invalid.

This works for me.

Why do I hash the user and the password on the client even though they go over the wire as https? Because fixed lengths are faster to search for in the DB (I mysql prepare all my queries to ensure not to depend on dirty client data). Also because even though the data goes encrypted, I prefer a long sequence of characters over the wire as opposed to a short sequence which a username/password might contain - in my world, it feels better though I believe from what I read I don't get if anything extra for the effort.


KMS uses envelope encryption. The encryption key changes each time you make a request for a key.

If you need a key that doesn't vary you'll need to manage your own encryption.


Is the VPN provider's ISP able to spy on traffic?

When it is not encrypted in other ways (like https), then yes, they can. A VPN appears just like any other customer to their ISP.

However, your VPN traffic is mixed with that of all other users of the VPN. From the point of view of the ISP, all traffic seems to originate from the VPN endpoint and they can not discern which connection belongs to which user of the VPN service. Unless, of course:

the traffic includes some unencrypted information which allows to identify the user
the number of users of the VPN is small enough that they can cooperate with your own ISP and look for traffic correlation (they notice that the VPN sends/receives data whenever you send/receive the same amount of data). This is, by the way, also a well-known weakness of the poor-man's VPN service TOR.
The VPN service cooperates with them


Found security vulnerability, what should I do?

It is unlikely that you can legally make money from this bug.  If you are considering some scheme to make lots of money from it: step away, take some time off.  There is a significant risk that you will be prosecuted for hacking or for extortion if you try to demand compensation for reporting the vulnerability.

Note that in the US, hacking is illegal.  The law is extremely broad and prohibits all sorts of things that many people might not realize are illegal.  I don't know how you discovered the bug, but I am worried there is a high risk that the actions you've taken up to now (e.g., to discover the bug) might be illegal.  If your actions in discovering the bug violated the law, even arguably, and if you piss off the company or generally act like a jerk (e.g., by demanding compensation), they might call up a federal prosecutor and convince the prosecutor to charge you for violating federal law.  You really don't want to be in that position.

In general, it is rare for companies to compensate people who report security bugs to them.  A few companies (e.g., Google) have "bug bounties" programs, where they promise to pay a few hundred or thousand dollars to people who report serious bugs to them under their program.  But most companies don't do anything like that.

Generally speaking, here is my advice:

Have you ever hacked, or tried to hack, this site?  Did you try anything that could be characterized as unauthorized access or an attempt to attack the site?  (e.g., typing in a single quote to see if it is vulnerable to SQL injection, sending < to see if is vulnerable to XSS, etc.)  If yes, stop here.  Don't disclose the vulnerability to them yourself.  Give up any thoughts of making money.  If you want to do the morally right thing, you could contact an adult you trust and ask them to report the vulnerability on your behalf without disclosing your identity -- but don't expect any payment.
If you are confident you have never done anything that could be characterized as attempting to gain unauthorized access or otherwise attack the site, and you are confident nothing you've done is likely to be treated as a violation of federal law (e.g., CFAA), then you could consider how to report the vulnerability to the site, if you wish.  But don't expect to make any money off this.  Don't demand compensation.  Don't threaten.  Don't ask for compensation as a condition of disclosing the bug.  Don't expect compensation.  If you are doing it in hopes of making money, stop: set it aside, because you don't want to be accused of extortion, and you have a lot more to lose than to gain.

If you want to disclose the vulnerability, I would try to find someone you trust who has worked in a professional business context for many years.  Ask them to help you disclose the vulnerability.  Ask them to help you write a letter or email that describes the vulnerability.  (I would disclose the vulnerability in writing, e.g., an email, a written letter, not by phone or in person.)  Also, before doing any of this, have them read this thread and the following threads on this site:

Reporting vulnerable sites
How to disclose a security vulnerability in an ethical fashion?
How should I escalate a vulnerability that is dismissed by the vendor?
Which companies facilitate payment in return for vulnerability disclosure?  (but I doubt they will pay for a vulnerability in a website; there are few or no buyers for that)

The reason I suggest having someone else help you disclose this is because there is a significant opportunity for misunderstanding.  You want someone who has worked in business to help you craft the letter, to make sure it is taken seriously, and to make sure the company doesn't treat you as a threat and start coming after you with threats of a lawsuit or prosecution.  Big companies have entire legal departments full of lawyers who exist solely to protect the company's financial interests.  If they perceive you as a threat, they may use every legal resource they have to try to prevent you from embarrassing the company.  Someone with more experience in a business context can help you protect yourself.

But, the bottom line is: check your motives.  The only reason to report the vulnerability to the company is because "it is the right thing to do" and for the good of others.  You are not likely to make money off this, I'm afraid to say this.  If you find that you are doing this for purposes of making money, stop; go do something else.  If you are doing this for purposes of making money, the risks are too high that you will find yourself hit with a lawsuit, a criminal prosecution, or something else that not only prevents you from making money, but also makes your life hell.  There have been too many other cases where security researchers were prosecuted for "hacking", when they were just trying to report or publicize a security vulnerability (not even try to exploit it for financial gain).

P.S. Here is Dan Kaminsky's informal, not-to-be-taken-too-seriously, summary of how things tend to work today:


Browsers root CA accepted, countries and checking fingerprints

From point 1), if you live in those countries, with "spain...etc", if
  there anyway to check that the CA you are using (in firefox for
  example or other) is the proper company , for example google/gmail?
  and not the government one?

You can check the certification path to find out which intermediary and root CAs signed the certificate that you are presented with from your browser.

  From point 2) how do you we know that we have our browser/system not
  patched for that kind of bug?

Generally only by checking online vulnerability databases such as this one or vendor bug lists to check whether a particular security issue has been identified and patched.

  Is this correct?

You can check online SSL fingerprints such as this one on GRC. The page notes that Google and Apple cannot be checked in this way:

  But companies with a massive and widely distributed web presence, such
  as Amazon or Google, may deploy many different security certificates
  across their many globally distributed servers and web sites. Multiple
  certificates may be easier for them to obtain and manage, and their
  security is not reduced. But it does mean that not every user of their
  servers (like you and this GRC page) would necessarily obtain the same
  security certificate.

  This means that a simple comparison of certificate fingerprints could
  erroneously lead people wishing to test these huge websites to
  conclude that their connections were being intercepted, when they have
  simply received a different valid certificate than the one received
  and shown by this web page.

  The best solution is to test smaller sites that are known to be using
  single certificates, or sites using the completely unspoofable
  extended validation (EV) certificates with an EV-honoring web browser
  such as Firefox or Chrome (but not Internet Explorer, which doesn't
  properly verify EV certificates).

Mandatory attrition link.

Note that if you were the subject of a targeted attack, a Man In The Middle could alter the GRC page to show you the certificate fingerprints that she was spoofing. Unlikely, but important to include this information here because it is easily technically possible. You could check the GRC page via TOR or via another connection (e.g. via 3/4G) in order to verify your main connection has not been MITM'd. This can also be applied in order to verify the certificate chain in most cases - but as noted, Google and Apple may have different CAs depending on which server your connection hits.


The maximum size of a file that I can encrypt with a specific key size

First of all, a 1024-bit RSA key is much too small for comfort. Current recommendations for RSA are a debate between 3072 or 4096 (better security margin) vs. 2048 (better performance). See:

https://crypto.stackexchange.com/questions/19655/what-is-the-history-of-recommended-rsa-key-sizes
https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-sizes-and-algorithm-recommendations

  I want to know the maximum size of a file that I want to encrypt with my public key? and the maximum size that I want to decrypt with my private key?

The limit here really comes down not to RSA itself, because practical public-key cryptography is almost always hybrid cryptography where RSA is used to encapsulate symmetric encryption keys (usually for some AES-based algorithm) and the actual data is encrypted with those.  So what in practice limits the size of the file you can encrypt is the design of the file or message format. For example with AES-GCM you cannot encrypt individual messages bigger than 64 GiB, and you should not encrypt more than 232 messages with one key, but that really means that to encrypt a larger volume of data the software should split it into smaller chunks and encrypt each one as a separate message, rotating keys after some number of chunks is exceeded.

(Side note: even for smaller files it's best to encrypt them in modest-sized chunks so that the software can reject forgeries without having to decrypt the whole file before producing any output. For example, one of the causes of the EFail vulnerability is that GnuPG outputs the decryptions of forged files before it performs an optional anti-forgery check.)

This is just one example; the general answer is that your question cannot be answered concretely with just the information that you give, and concrete answers require looking at your specific cryptographic software to see how it's designed and implemented.  For example, the documentation for GnuPG tells you for some of its symmetric algorithms you should not encrypt files bigger than 4 GiB:

  Due to its 1970s-era 64-bit block size, [3DES] should not be used to encrypt more than about 4Gb of data. Beyond that, though, it is solid as a rock, and very few GnuPG users will ever notice a problem with it. Provided you’re not encrypting more than 4Gb of data you may use 3DES with confidence.

I could not quickly find what's the failure mode if you violate this rule, and I cannot warrant whether it gives you an error saying you did something bad (as it should) or just silently produces a potentially insecure output file (which would be terrible). Caveat emptor.


A bit of background as to what Yubikey is first: Yubikey is a variation on a common type of device known as a One Time Password generator. Basically a mini-computer that generates an essentially unlimited stream of passwords, usually one per minute from a deterministic algorithm embedded in the device. The trick is that next password is predictable if you know a secret "seed" value and unguessable if you don't know it.

This way an authentication computer that knows the secret seed can confirm you have the Yubikey physically on hand because only the Yubikey and the authentication server1 can generate the once-off password required at a specific minute in time.

So:

Point one. As long as the authentication server knows what password the Yubikey should be generating, then having a different password every time makes it impossible for someone to spy over your shoulder and steal your password - as each password becomes useless a minute later. Essentially the key is something you have rather than something you know2.
Point two. For authentication - yes. For the reasons described above. For encryption - no. As you actually want to remember and reuse the key you encrypted the file with. In theory a 32GB USB key filled with truly random data could qualify as an all-purpose entropy source for authentication and encryption, but USBs are normally not that difficult to duplicate or manipulate.
Point 3. In theory if you know the secret key, you can duplicate the YubiKey but once a YubiKey is configured the idea is that you can't duplicate it as it must be something that only an authorised person possesses. Of course, since Yubikeys are intended for authentication instead of encryption, new ones (with new seeds) can reissued for a user who has lost their old one.
Point 4. As per overview, capturing the passwords is pointless as the maths behind the internal pseudorandom number generator make predicting future passwords extremely difficult - as in governments give you millions of dollars if you succeed, difficult.
Point 5. You want it to be open source. Most common cryptographic flaws are not in the mathematical algorithms but the overall implementation. You want to know that any security expert on the planet can pull up a copy of the system and examine it for flaws as need be.
Point 6. As per earlier discussion.

1. Depending on configuration, as there are many other ways to use the Yubikey design.
2. Although I believe YubiKey is an open standard, so you could memorise the secret seed yourself if you really wanted to for some reason.


Is it necessary to encrypt nonce in cryptographic communication?

Nonces do not necessarily have to be secret, their only use is to ensure that a message is unique.

Basically, the fact that a plaintext includes a nonce means that the ciphertext is of no use to an attacker.

An attacker being able to influence the nonce is a different issue and will likely cause some problems in protocols that depend on it.


Can I get functions addresses from CaptureStackBackTrace?

A year old question but it does come up in searches so:
Pattern matching:
First part of your question, you might want to look up on how to find functions by signatures/patterns. Web search for this, there are a lot of good answers on this or the sister site Stack Overflow, on Game hacking sites, etc.
See: https://www.unknowncheats.me/forum/c-and-c-/125497-findpattern-benchmark.html

For the stack trace part:
CaptureStackBackTrace() works by calling RtlWalkFrameChain() walking EBP/RBP stack frames. Disassembling the function in ntdll you can see it's a very simple
function. At least one problem of it is for functions that don't have stack frames, it's probably not going to find those return addresses. This and StackWalk64() are better left for debugging situations where you have PDBs for everything, etc.

What you'll probably want to do is walk up the stack yourself. You can get the current stack pointer (ESP/RSP) using the _AddressOfReturnAddress() compiler intrinsic or do a "__asm mov eax,esp", etc.

Using "DWORD_PTR" advance up the stack calling VirtualQueryEx() on each value that looks like an address. If it returns success it's at a least a valid memory pointer.
If it's protection flag is "(PAGE_EXECUTE | PAGE_EXECUTE_READ | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY) != 0" then you know it's not executable.

If the type is not "MEM_IMAGE" then it's probably not a return address either because all normal Windows executables (.exe, .com, .dll, etc.) are going to be imaged mapped.
With some exceptions like if the code is from some sort of JIT, shellcode, mallware, etc.

Then you can go a level or two deeper by using a simple dissembler library (like HDE) to disassemble the instruction at the assumed return address. Should be a valid instruction there.

Look at the "debghelp.dll" functions too. There's support to resolve addresses to known API functions, etc.
Update: Tried this. Depending on the target process it ends up being a mess since you will find a bunch of stray code offsets. Turns out the stack is relatively chaotic. Better to use CaptureStackBackTrace() and hope that the return chain has frame pointers.

For the get function start address question:
(A lot of these topics are not so trivial) you can try using "SymFromAddr()" and that might tell you what API the return address is in.

If you can use the dbghelp.dll functions or they don't work for you, if again a return address has a MEM_IMAGE type the "AllocationBase" should the same as "HMODULE". The module that contains the function returned too.

Now that you found the base of the module you are in:
Then using PE header parsing, you can walk the export table for the module. Loop through them comparing the start address of one the exported function to the next. Your address will be between there someplace. The exported function closest to your address is the answer.
Update: SymFromAddr() IS what you want to use. Works great with the stack walking described above. Be sure to wrap it around a critical section though, it's not thread safe.

Note: I find my self with Windows API functions they don't always work as they are described and/or don't handle edge cases so well where you pretty much have to experiment; using either kernel32.dll, psapi.dll, or even ntdll.dll functions directly.


What is the purpose and meaning of the --sig-notation and --cert-notation options in GnuPG?

Notations provide meanings to add information to a signature or certification (which also is a special kind of signature). From RFC 4880, 5.2.3.16. Notation Data:

  This subpacket describes a "notation" on the signature that the
     issuer wishes to make.  The notation has a name and a value, each of
     which are strings of octets.  There may be more than one notation in
     a signature.  Notations can be used for any extension the issuer of
     the signature cares to make. [...]

Notations are rarely used in practice (actually I've never seen real usage, although there are few notation subpackets to be found in key server dumps). Example usage might be to add the location of an identity check during key signing, or the document types presented.

Each notation consists of a notation name and a value, while the value is an arbitrary UTF-8 encoded string.

Regarding the @, this is part of the notation namespaces. Namespaces help to distinguish notations if they use the same name, but are defined by different people. Again from the same section of the RFC:

  Notation names are arbitrary strings encoded in UTF-8.  They reside
     in two namespaces: The IETF namespace and the user namespace.

  The IETF namespace is registered with IANA.  These names MUST NOT
     contain the "@" character (0x40).  This is a tag for the user
     namespace.

  Names in the user namespace consist of a UTF-8 string tag followed by
     "@" followed by a DNS domain name.  Note that the tag MUST NOT
     contain an "@" character.  For example, the "sample" tag used by
     Example Corporation could be "sample@example.com".

  Names in a user space are owned and controlled by the owners of that
     domain.  Obviously, it's bad form to create a new name in a DNS space
     that you don't own.

  Since the user namespace is in the form of an email address,
     implementers MAY wish to arrange for that address to reach a person
     who can be consulted about the use of the named tag.  Note that due
     to UTF-8 encoding, not all valid user space name tags are valid email
     addresses.

With other words, there can be official notations in the form of some-notation-name defined by a standard and  registered with the IANA. On the other hand, everybody can declare his own notations, which should have the form my-notation-name@example.com. For example, if I would use some-notation-name@jenserat.de, it would not collide with the (assumed) official notation some-notation-name in the IANA namespace.


The OPAL Specification includes test cases that must pass in order to claim OPAL compliance. But these are to be done by the vendor, not the end-user. You would need a special testing rig to run these tests to see if the component is compliant.

If the vendor says that they have not run the tests, then they cannot claim compliance. They might incidentally be compliant, but you might never know.


Spoof IP in a TCP Packet & Vulnerable PHP Code

I'm glad that you specify that the attacker will not get communication back: many people don't understand that impact of spoofed IPs.

Technically, yes, that script is vulnerable to a spoofed IP, but a lot has to happen first:

The routers along the network path have to not inspect the source IP for sanity
The routers along the network path have to allow source path routing (not common)
The server isn't using any technology that requires a handshake first (TLS/SSL, etc.)

If the stars align, then yes, an attacker could trigger that script.


Intercept Connections Instead of Forwarding (using arpspoof)

Once you have intercepted the communication, you can perform an edit on the plain text in the packets being sent, so you can change what a website says, for instance. A search/replace using regex works for this purpose.

To do this efficiently, ettercap has many tools to help you out.

Depending on what you want to accomplish, BeEF is another great example, which in included in Backtrack. It allows you to spoof entire websites and make modifications. It also has some impressive client attack tools, but I think that's not in the scope of what you want to do.


WRT upgrading:  Don't ask if it's possible, demand to know when it will be upgraded and to see the upgrade path to future versions of SQL.

WRT logging: there must be logging.  As a customer, I want to see whether anyone has done anything with the database, including vendor admins.  Who has rights to logging?  What reporting will I receive free of charge? Who can run reports?  Who has rights to the audit logs?  (I want to be sure that, if someone goes rogue, that the rogue employee doesn't have rights to remove their actions from the audit log)

What about physical security to the data center where it will be housed?  Who has access and how is that access determined?

Are background checks performed on their employees with access to your data?

Are "least privileges" maintained with respect to your data?  How often is access reviewed?  How long does it take to remove the rights of terminated employees (whether willfully or unwilling) from your data?

Are all default passwords changed?

Those are some of the questions we often ask of outsourced providers; apologies if you already ask these questions.


How do INFOSEC competitions deal with social engineering?

I am not certain you understand the common types of security competitions. Most are specifically for security professionals, and have nothing to do with what a non-security-aware user would do.

Some examples: working out how to exploit rare or hard-to-find vulnerabilities, linking different vulnerabilities together, writing zero-days, identifying systems from limited information etc.

Simulating the effects of users randomly clicking on things is mostly irrelevant to those competitions, and is not what I would consider social engineering anyway.

That said, some competitions allow social engineering as a technique, giving you points for info/trophies gathered by non-technical means (ie lying, cheating, physically gaining access etc)


Each encryption mode has its requirements for the IV. For GCM, the requirements are simple (see NIST SP 800-38D for details):

Length should be between 1 and 261-1 bytes. It is recommended that the IV length is exactly 12 bytes (96 bits); if it is not, then GCM will need to pad and/or hash the IV first, which is not supported by all implementations, and increases the risk of spurious collision.
For any given key K, you shall never use twice the same IV.

In particular, in GCM (as opposed to, say, CBC), there is no need for the IV to be random and unpredictable; uniqueness only is required.

Therefore, a 96-bit value extracted from a monotonic clock (I suppose that is what you mean by "time stamp") is a nice IV, provided that you take care of the following:

If you encrypt several messages in quick succession, they may end up using the same time stamp, depending on the accuracy of the system clock and the speed of the CPU. You MUST include some test to avoid such an occurrence.
The system clock may vary, either automatically or through human action (the user notices that the clock is off and adjusts it). Having a really monotonic clock can be hard in all generality.


Don't expect database encryption to magically solve these security concerns.  When yet another oracle db exploit hits metasploit a competitor could use this to compromise all data  and all encryption keys stored on the database.  In short,  an adversary doesn't need SQL Injection to deliver a metasploit payload,  they already have access to the database which is a much easier attack to carry out.

Personally, I wouldn't trust my data stored on a database where competitors have access.  I also wouldn't depend on Oracle for security.  They are very slow to roll out patches in mission critical software and do not handle 0-days very well.  (TWO botched patches for the most recent java 0-day,  really?  This does not inspire consumer confidence.)


Padlocks suitable as teaching aids for public key cryptography - do they exist?

I don't believe they do and I'm not sure how that would work. There really isn't a call for a padlock you have to lock with a key, it is more complex than it needs to be.

For other locks, I think the nearest you would get to are those that have a master key which is quite common. But even there, any of the keys will lock any of the locks. The master key can open multiple locks of course.


What are possible consequences for applications that depends on Safe Mode for security?

The main reason why safe mode should be removed is because its doesn't work.  Over the years people have found many ways of bypassing PHP's safe mode.

But the lack of enforceability is only one reason reason why Zend chose to remove "safe mode".  This is a quote taken from the PHP 6 minutes discussion:

  As safe_mode is a name that gives the wrong signals as making PHP
  safe, we all agreed that we should remove this function. It can never
  be made totally safe as there will always be ways to circumvent
  safe_mode through libraries. This kind of functionality also better
  belongs in the web server or other security scheme. open_basedir is a
  feature that we will keep, and we will point users to this
  functionality in the error message that is thrown when we detect this
  setting on start-up.


Your question is quite broad, and not very specific. It is hard to give advice for such generalities as the recommendations would be different for different people.

As with most security questions start with "What are your protecting? From Whom? What are the consequences of losing this?".

Here are some starting points:

Do you have multiple personas you want kept separate? e.g. Mr Anderson Vs Neo.
If this is the case you will need different key-pairs for each of these personas.
Do you need keys for work and personal?
If so these should be different key-pairs, as your company may consider your key it's property, and may revoke it once you leave the company.
Do you mind your activities being correlated across servers? For me personally the cross persona is more important then the cross service. I don't mind my GitHub/Souceforge/Stackexchange identities being correlated but it would be a shame if it was proven I was The Dread Pirate Roberts.
If so, you need different key-pairs for each of these services.

As you say each key you maintain adds to the amount of effort you need to go to to maintain them. This also raises the possibility of using the wrong key in the wrong place and accidentally connecting your different keys.

The most likely scenario I can see would be someone with 3 personas, [professional , public personal, private personal]. I would be inclined to keep use separate machines for personal and professional, so that my personal private keys never touch my work computers and my works private keys never touch my personal computers. Then depending on the consequences of linking public personal and private personal I would either:

Keep the keys on separate accounts of the same machine (low consequences)
Keep the "public personal" private key on the machine and the "private personal" private key on an encrypted USB device, only plug this in when doing private stuff (medium consequences).
Have a Tails OS or similar for your private work. Again "private personal" on an encrypted USB stick. (medium-high consequences)
Dedicated, physically secure air-gapped machine and some luck (high consequences)


How Could A Diffie Hellman Key Exchange Work on SMS Apps on Two Different Mobile Devices?

Yes, that's possible . Why not?

Diffie-Hellman only demands you exchange data. There's no restriction on how that data gets from A to B. You might use the internet, SMS, pidgeons, shout it across the marketplace, morse it, use skybeamers to write it into the night sky…

How you encode the couple of bits into SMS, letters attached to pidgeons, buzzwords shouted across the market place, letters morsed, or skybeamer figures is up to you. In the end, Diffie-Hellmann just requires you to send a few numbers around.


Android Security - Giving Google Your Phone Number

Yes it is quite a compromise of a Google account if you lose an Android device that isn't protected (with disk encryption + a lock screen). It is best practice to be able to remotely wipe the device. When you realize you have lost the device you should immediately log into your Google account on a PC to update the 2FA settings. You're not missing anything, using a phone number/SMS for 2FA is not good and I wish we'd stop requiring it.


Is this a good way to handle login process

In your process, people will get a distinct error code depending on whether the account exists or not. This is often considered somewhat inopportune. It is preferable if it is not possible, for outsider, to know whether a given account name exists; therefore, observable behaviour of your server should be the same in all situations which depend on the account name and lead to a failure: account does not exist, account is disabled, password is wrong. Note that "observable behaviour" includes not only the error code you return, but also the time taken by your server to respond (if you use slow-and-salted password hashing à la bcrypt -- and you really shoud do that -- then password verification can take a non-negligible time which can be measured from the outside).

Banning an IP address after a few failures has the following caveats:

The IP address you see could be shared between several people, in case of NAT. This is very common in organizations. Also common are HTTP proxies. You don't want three failures from one user to induce your server into banning a complete university, or even all the customers of a specific ISP.
Sometimes, people forget their password. This happens a lot. So you will get "legitimate" login failures. Such users will want to use the "I forgot my password" process, and they will want to do it immediately. Therefore, the ban must not be long (say, ban for one minute at most).
Attackers who are intent on trying a lot of potential login+password pairs will have relatively little trouble finding relay hosts to work around your IP-based banning. E.g. Tor, by construction, decreases the efficiency of IP banning.

Therefore I do not recommend IP address banning on a general basis: it has a high risk of disrupting service for normal users, while not being very effective against average attackers. IP banning is useful against burst situations with crude attackers (e.g. automatic attacks from botnets trying to replicate), with tools like Fail2ban, but they can backfire, so caution must be exercised.

Note that blocking accounts can also backfire:

Blocking an account after too many failures means that anybody can block the accounts of other people.
Attackers who try many login+password pairs can spread their attempts over a lot of distinct logins, avoiding the blocking feature.

Reasonable solutions involve time-limited blocks (lock an account for one minute or so after a few wrong passwords) coupled with time-limited IP banning when a very suspicious access pattern is identified (a lot of connection attempts from the same IP). They will not give strong protection (only strong user passwords will), but they may help in reducing the noise from low-grade attackers and let you concentrate on the few cases where attackers exhibit an unusual amount of competence.


How to tell if a site is securely storing passwords?

There's no legitimate way for you to directly know if a website stores passwords in plaintext, stores them in a reversable (possibly encrypted) format, stores as mediocre hashes, or securely hashes them. One possibility is to try to recover your password using their "forgot my password" functionality. If they send you your password, then they're definitely storing it as plaintext or as a reversible (possibly encrypted) format. The problem with this method is that it doesn't work the other way around; if they do not send you your password, it does not mean they're not storing it as plaintext or in a reversible format.

Bottom line is: Unless you gain legitimate or illegitimate (hacking) access to their servers to see for yourself, there's really no way to tell.


Should I remove bash from my Docker web app container?

It might improve security but it's a very strange way of doing things.

What you are suggesting is to start with an image with "unnecessary" software installed and remove some of the stuff you don't need (bash, echo,...). This does not only risk breaking things, it also increases container size because the base layer with the unnecessary tools is still shipped.

A better approach is to start with a minimal image. Not alpine, that's still a full os. The more minimal approach is to use a base image that only contains the required language runtime like googles distoless images https://github.com/GoogleCloudPlatform/distroless . For static binaries, you can even start with an empty image.

That way you get an image that is as small as possible and does not provide the "attack surface" of bash.


From your vague description, I suppose that your code gathers whatever the server sends back as a big sequence of bytes, then interprets the bytes as if they were a nul-terminated character string, and then tries to find a CR+LF sequence in it.

This is wrong on many levels. First off, bytes are not necessarily a character string, and may, in particular, lack the terminating 0. Also, while the HTTP header consists in lines ending with CR+LF, and ends on an empty line (i.e. a CR+LF immediately after the previous CR+LF), nothing prevents the response body from containing CR+LF sequences as well. Finally, there is a thing called content encoding which is how the response contents are encoded into bytes. With HTTP, there are mainly four encodings for the response body:

No response body at all. This depends on the response type. For instance, types 204 and 304 do not have a body.
Explicit length. A Content-Length header specifies the length of the body, in bytes.
Implicit length. The body extends up to the end of the transport connection. When implicit length is used, the response cannot, by definition, be followed on the same connection with another response for another request.
Chunked encoding. The body is split into chunks; each chunk has its own size, given as a chunk header. This is described in section 3.6.1. There is no standard maximum size on a chunk. Chunked encoding also supports a "trailer", i.e. additional HTTP header lines after the data.

The bottom-line is that you should not try to find CR+LF sequences directly in some bytes. What you should do is the following:

Use an HTTP library which yields the response as a stream; e.g. LibSoup (I suppose, from your use of g_strstr_len(), that you use Glib; LibSoup is a GNOME HTTP library designed to work well with Glib).
Read the response data, as provided by the library, as small chunks (e.g. by chunks of at most 8192 bytes, a very traditional value). Don't bother thinking about "chunks" as seen on the wire; this is the job of the HTTP library, not yours.
Count the bytes as you read them. I suppose you want to accumulate these bytes somewhere in RAM, e.g. in an array, for further processing. Be sure to enforce a size limit: if the response body happens to be larger than a maximum expected value (which depends on what you want), then discard further bytes and report an error.

This way, you will get the response length, and the response as well, while keeping under controlled memory size: an oversized response will not make your code allocate an oversized chunk of RAM. This will also be compatible with the various encoding types. In any case, you MUST read the complete response at some point: unless an explicit Content-Length header is included, there is no way to know the response length without reading it all; and reading the complete response is important to allow a subsequent response to use the same TCP connection.

In that sense, attacks related to chunk size work only against poorly written software who insist on allocating RAM blocks based on sizes sent by the peer and without any safeguard against "absurd" data. If you want to implement proper, not-too-vulnerable network code, you have to be somewhat defensive about the received data, which must be assumed to be hostile by default until proven benign. You must not expect the server to always send you nice ASCII characters in well-formed messages. You get bytes and you can get any byte, both in quantity and contents. Using a library designed for HTTP will abstract away encoding issues, thus doing half of this defensive job.


Linux password changed. Is this an attack or a hardware glitch?

While browsing web pages, I can't seem to scroll down. My right hand
  was on my mouse, left eating food so I'm sure I'm not accidentally
  pressing any keys. I ran showkey and discovered that every now and
  then, I'd get spammed by keycode 104 events. 104 seems to be Pg Up.

  I try to log-in to Windows 8 and, when I enter my password, I seem to
  notice that, when I enter my password (19 chars long, same as
  Ubuntu's), the cursor suddenly shifts to the first character. So, for
  instance, if my password is "password", entering it straight out it
  becomes "dpasswor".

Any more questions? :) There is either food stuck below the PgUp key or it is an electronic problem like a hair-line crack on the motherboard.

How this could affect your password file is mysterious, but maybe it didn't and it jumped around too? More probable the PgUp keystroke got interpreted as part of the password.


The whole idea that there needs to be a path from Alice to Doris is incorrect. There just needs to be a valid certificate chain from Doris to a trusted certificate in the trust store of Alice. And Doris - of course - needs to prove that she has the private key that belongs to the certificate of Doris herself.

So all Alice requires is a trusted certificate A or C. She needs to retrieve all intermediate certificates if she doesn't have a full chain (if she just has A she needs to retrieve C - usually it is send to Alice by Doris). She needs to be able to verify the signature for the certificates and the validity of the certificates in the chain. The validation procedure may check key usage, key extensions, validity period and of course certificate status/revocation etc. The chain may also consist of just the certificate of Doris if that is trusted directly (certificate pinning).

Finally the signature of the private key needs to be verified using the public key of Doris certificate. Or the private key may be need to be used to decrypt a challenge or session key.

Alice doesn't even need a certificate / private key herself. Currently my browser doesn't have my certificate either. Only those entities that are required to authenticate themselves have to have a private key and corresponding certificate.