Does a client certificate identify the owner to unrelated websites? If I install a client certificate in my browser, which websites can see any information about this client certificate or the CA that issued it?

I once visited an ssl diagnostic site that immediately reported back information from one of my client certificates, including my name (which I had put in the CA that issued the client certificate).

This is related to: Protecting information in TLS client certificates
But that's about how the certificate is sent to the website that the certificate is intended for.  I'm asking about unrelated websites.

Interesting question! I just so happen to have a browser full of test certs, and a number of test sites to connect to! Let's test this!

(Skip to the bottom for a summary)

Investigation

Testing on Firefox

Firefox loaded with certs, a test site that requires a TLS client cert, Wireshark.

I restarted Firefox to get a clean session. Then I entered the URL of a website that will ask for a TLS client cert, and stopped once I got the "Please choose a certificate" popup. This is the wireshark packet capture up to that point:

Things to note:

The client sends a generic ClientHello.

The server sends a ServerHello that includes the server cert, and a request for a client cert.

At this point Firefox presents the popup for me to select which cert I wish to send. If I hit Cancel, then there is no further network traffic, ie nothing is sent to the server beyond the generic ClientHello which contains no personally identifiable information. (apart from the list of supported cipher suites, which could be used to determine which version of which browser you're using)

Note1: I tried the same test with only one client cert in my browser, and I even clicked "Remember this decision" on the cert selection popup, and get the same result. So I am unable to reproduce your result of private data being sent to the server without me clicking "OK".

Note2: As pointed out by @JohnWu in comments, you can change Firefox's behaviour in settings in which case it behaves in the same insecure way as Chrome below. Default setting is:

Testing on Chrome

Exactly the same test scenario as above, but with Chrome. (Note that Chrome does not have its own cert store, but instead uses your Windows cert store, which is a bit trickier to manipulate than Firefox. Details for that not included here.)

BINGO!! Chrome immediately starts sending client certs up to the server without any user prompts. This cert got rejected by the server because that cert was for a different website. Yup, that's a privacy concern alright.

Note1: @JohnWu points out that it's possible to change this behaviour and have Chrome prompt, but it's not the default behaviour, and you have to go diving in Windows group policy (GPO) to do it.

Note2: the reproducibility of this may depend on how your Windows OS was configured since Chrome tends to inherit a lot of its security settings from IE.

Summary

In my testing with the two browsers that I have in my test environment (Firefox and Chrome), Chrome exhibited the behaviour you describe (spamming client certs at the server regardless of whether they are from a different site), while Firefox politely asked me to confirm which cert to send, even when I only had one cert installed.

Conclusion: If you care about privacy, then Chrome is not your friend. Use Firefox instead.


Why would you need a salt for AES-CBS when IV is already randomly generated and stored with the encrypted data? I was looking at this code and came across these comments which says encrypting without a salt is insecure. Why would it be insecure when you are already using a random IV for each value? I think the comment might be incorrect, but it is a popular gem so I wasn't sure. I think it is treating key really as a password, and I just wanted to verify.

https://github.com/attr-encrypted/encryptor/blob/master/lib/encryptor.rb#L57

  if options[:iv]
    cipher.iv = options[:iv]
    if options[:salt].nil?
      # Use a non-salted cipher.
      # This behaviour is retained for backwards compatibility. This mode
      # is not secure and new deployments should use the :salt options
      # wherever possible.
      cipher.key = options[:key]
    else
      # Use an explicit salt (which can be persisted into a database on a
      # per-column basis, for example). This is the preferred (and more
      # secure) mode of operation.
      cipher.key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(options[:key], options[:salt], 2000, cipher.key_len)
    end
  else
    cipher.pkcs5_keyivgen(options[:key])
  end

I'm intending to write something from scratch, and only use base libraries. My key comes from SecureRandom.base64(32) and I will store that in the code and Base64 decode it to get the binary key, and use that for encryption/decryption, along with random IVs for each data element. I don't think I need a salt for that. Would like to confirm.

You need both a salt and an IV when you do... two distinct actions, one needing a salt and the other an IV. That's your case here.

The salt relates to turning a password into a secret key. That's what is used in your example code: PBKDF2 is a password-based key derivation function. As anything which uses passwords, PBKDF2 needs configurable slowness (that's the "2000" parameter) and also uniqueness, which the salt grants. This is a subcase of password hashing, which is explained there.

The IV is needed for the actual encryption. CBC mode is a sequential algorithm, in which each data block is first XORed with the output of the processing of the previous block. It must start somewhere... so the IV is the arbitrary "previous block" to be used for the first block.

Generally speaking, CBC mode requires an IV which is uniformly random and cannot be predicted by an attacker who is in position of choosing part of the data which is to be encrypted (the BEAST attack on SSL is of that kind). However, trouble arises only when the same key is used at least twice. Therefore, the two following tricks may be applicable, and avoid the need to transmit an IV along the encrypted file:

PBKDF2 can be used to generate an output of configurable length. It is possible to generate with PBKDF2 enough bytes for the key and the IV.
A conventional, fixed IV (e.g. "all zeros") is used.

Both methods are valid only if the specific encryption key is used only once. This means that if the same password is used to encrypt two files, then a new random salt must be generated for each file. This implies that if the password-to-key transform is computationally expensive (and it should be), and many files must be encrypted with the same password, then the total cost can become prohibitive.

If the same salt is used for several files (with the same password)(*), then the consequence is that the same key will be used for all these files, which is fine... as long as each file also gets its own IV. So the IV must be stored somehow in the file header. On the other hand, if all files use the same salt, then maybe you can mutualize the storage space for that salt ?

The generic, safe method is to use a random IV (generated from a cryptographically strong PRNG) for each encryption run, regardless of how the key was obtained. This avoids making implicit assumptions on the key generation process and how often it occurs in the overall protocol. Also, this allows mutualizing the password-to-key transform if many files are to be encrypted as a batch process with the "same password": as long as each file gets its own random IV, the same key (derived once from the password, with one salt) can be safely applied for all. This is somehow what happens in TLS (version 1.1 and more): all records in a given connection get encrypted with the same key, but each record gets its own IV, and this is safe (in TLS 1.0, each record gets its own IV by copying it from the end of the previous encrypted record, which is vulnerable to BEAST because these IV are then predictable through observation; in TLS 1.1+, each record has a new, specific random IV).

(*) NEVER reuse a salt value for distinct passwords. Never.


What's the possiblity of my ISO being compromised? This has concerned me for awhile. I had downloaded and installed many different operating systems and have always verified the integrity and authenticity of the ISO files by checking the hashes and comparing the digital signature to it.

If I had an infected machine or an infected web browser what are the chances of my ISO file being compromised while it's downloading or even after it has been downloaded? Also what if I downloaded the file from a malicious or unofficial source but everything matched (checksums etc.)? If everything matches, does this mean that my download is the way it was meant to be?

While I cannot give you an exact possibility, I can answer your other questions.

There are three main ways to corrupt a download:

a malicious server,
insecure transport & a malicious carrier,
a compromised host.

While checksum and hash checking can help against (2) and maybe (depending on how the signature is distributed and you establish trust in the signature) (1), you can not mitigate (3).

Supposing a machine is compromised, it is a lost cause to do anything, really, with it, except a nuke from orbit.

malware could alter the download when written to disk,
when transferred to another Medium or
download the image from where you are not trying to load it and modify the tools you use to validate the correctness of the file so that all your checks come back positive while they actually are not.

As you see: when you cannot trust the machine you are workin with, anything might happen.


Does letsencrypt.org support non-default ports, i.e. ports other than 443 for SSL certificates? I would like to get a letsencrypt.org SSL certificate for a service which runs on a non-default root-reserved port, i.e. port other than 443 and < 1024, e.g. 446. I'm uncertain whether letsencrypt.org supports this setup because I only found a feature request and a github.com issue which run into a discussion loop and are closed for no apparent reason. Maybe someone knows the answer right-away or cares to extract a clear statement which is hard to do for me because there're tons of references and developers and non-developers are talking confused.

I tried to specify domain:port as domain to letsencrypt console client which fails because it's not FQDN (sudo letsencrypt certonly -a manual -d [domain]:446--test-cert fails due to Requested domain [domain]:446 is not a FQDN) and adding --http-01-port 446 doesn't help.

Yes you can use non-default ports and it's recommended for compability with browsers and firewalls to use port above 1024 like 8443. You do not need to specify port when obtaining certificate. You just do it as usual and then you can experiment with changing ports.

Some configurations and software may refuse to pass HTTPS traffic to ports below 1024 other than default 443. For example, some corporate firewalls.


Understanding Windows local password hashes (NTLM) I have recently dumped some hashes from my local machine because I'm trying to understand the process in which Windows 7 hashes it's passwords.

I have discovered my local password hash that looks (similar) to this: Jason:502:aad3c435b514a4eeaad3b935b51304fe:c46b9e588fa0d112de6f59fd6d58eae3:::

Now what I would like to know is what the different sections mean, so:

We have this hash: Jason:502:aad3c435b514a4eeaad3b935b51304fe:c46b9e588fa0d112de6f59fd6d58eae3::: that looks to be separated by : if we separate this by the : we end up with this:

[Jason, :, 502, :, aad3c435b514a4eeaad3b935b51304fe, :, c46b9e588fa0d112de6f59fd6d58eae3, :, :, :]

I'm assuming the first part Jason is the username, that's the most logical to me.
The third part aad3c435b514a4eeaad3b935b51304fe is the ntlm hash would be my best guess.

If my assumption is correct then that leaves c46b9e588fa0d112de6f59fd6d58eae3 and 502 left.

I'd guess that the other hash (c46b9e588fa0d112de6f59fd6d58eae3) is the derived key, that is created from the password itself.
The 502 would be the binary data of the user.
And the : is just a separator or a padding.

Now for my question, am I correct in my assumptions on what each part of the hash represents? If not can someone please explain to me what each part represents?

Using

[Jason, :, 502, :, aad3c435b514a4eeaad3b935b51304fe, :, c46b9e588fa0d112de6f59fd6d58eae3, :, :, :]

as the example

Jason is the user name
502 is the relative identifier (500 is an administrator, 502 here is a kerberos account.)  (adsecurity.org/?p=483)
aad3c435b514a4eeaad3b935b51304f is the LM hash
c46b9e588fa0d112de6f59fd6d58eae3 is the NT hash

Details on difference between the hashes can be found here:
LM / NT Hashes


How in-house certificate authority works (e.g. EJBCA) I have a simple question with respect to EJBCA. I have been exploring how in-house CAs work and issue certificates. However, I am not able to understand who will be trusted on the top level in a certificate chain.

Let me try to clarify. When I buy a cert from say Comodo, I know that the certificate chain will end up at the Comodo root CA which is trusted by the browsers.

So, in case of EJBCA, which root certificate will be used and how to get that?
If purpose of EJBCA is to have full control over the CA, then wouldn't it need a well known root CA which would be trusted by browsers? Also, does it mean, although I have EJBCA on-premise, I still have to purchase a root level cert for my organization from a third party vendor like Comodo?

I know that I am horribly missing some concepts here. However, I tried reading the EJBCA documentation, Google documentation on in-house CA, etc., but they all talk about how to install, configure, manage, etc. My search did not lead me to a documentation which would explain how this whole thing works.

Any pointer to documentation would be really helpful.

What you are describing is basic Public Key Infrastructure.

When you run your own Certification Authority, you have to manage the root CA cert. For it to be recognised, you have to deploy it to your clients, which can be done using the "well known root CA" of browsers, but won't be until you can get recognised as a proper CA (see here).


Is this code snippet good enough for password hash and salt After a few days reading up about salting and hashing passwords, I found an actual bit of code that tells how to do it. This is what I found:

$blowfish_salt = bin2hex(openssl_random_pseudo_bytes(22));
$hash = crypt($data, "$2a$12$".$blowfish_salt);

Is this a good way to do it?

It's easier to use the php 5.5 password_hash function, or if you're using an older version, the compatibility library
openssl_random_pseudo_bytes sometimes suffers from performance issues. Consider mcrypt_create_iv (size, MCRYPT_DEV_URANDOM) instead.
salt encoding is tricky. Hex doesn't use the space optimally, and normal Base64 uses invalid characters.

$salt = substr(strtr(base64_encode($randomSalt), '+', '.'), 0, 22);

should do the trick.

Combining these you get

$binarySalt = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);
$salt = substr(strtr(base64_encode($binarySalt), '+', '.'), 0, 22);

Check Seven Ways To Screw Up BCrypt on ircmaxell's blog for further reading.


Questions about user authentication over REST API I'm now trying to implement user authentication on my android app. I, however, have a few questions.

I use a REST API. How do I safely request and send data to and from the phone? I'm assuming that I should encrypt the user's password before it's sent from the phone to the server.

Parts of my app return JSON data (from my API) that are specifically made for that user (based on their identification). After authentication, how can I request data based on the user's identification?

I have heard others mention something about a token (OAuth?). Would this token be saved both on the phone and within my server's database? Would the token then be included in each API request and verified with the server database before returning any data?

Is there anything else I should know? Links to tutorials? Security?

Thank you!

You can take a look at JSON web token.

SSL is required!

The user submit his username and password the first time.

After verification you just send a token to the phone which will be used to verify the user and the permission on each request.

Details are available on http://jwt.io/.


add another layer of protection on top of oauth 2 My Rest API is protected using Oauth2. My main client is a native app.

it's working great but there are certain calls to the API that i want to make sure that are performed from my client - meaning that if the user obtained the access token - he will not be able to use curl in order to call my Rest api.

For example if i have a Rest api for Achievement unlocking, how can i make sure that an authenticated user will not be able to call this rest api in order to unlock the achivment?

Solutions that i thought of:

Sign the request with a special header - But i think that it's breakable

As soon as you deploy your client to a device you cannot fully control, there is no way to be absolutely sure anyone can tamper with the requests.

What you can do though is put some measures in place that will require work from the attacker, for example, you could encrypt and/or sign your data using embedded keys in the application. In order to send data to the server, the attacker would have to perform the task of encryption/signature to send you valid data. This means he would have to reverse engineer the application or find a way to use your app to do the work for him (which should not happen). Someone motivated enough will eventually succeed since all the data are present on his device. The idea is to be time consuming so that he will find it not worth the effort.

OAuth only solves the problem of authorising a specific user. So you should be able to ensure that a user can only tamper with it's own requests and not the requests of others.


Is a connection that uses 0.0.0.0 in Foreign Address, secured? When I run my application on Centos the specific process opens port that listens for connections from localhost, but uses 0.0.0.0 in Foreign Address. Is it secured?

netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q     Local Address               Foreign Address             State       PID/Program name
tcp        0      0     127.0.0.1:5555              0.0.0.0:*                   LISTEN      17332

All this is indicating is that the process listening on that address and port has 'requested' the ability to receive connections from any IP address on any port. Until a connection is made the process appears as being connected to nothing in this way (asterisk).

From the netstat manpage:

  Foreign Address - The IP address and port number of the remote computer to which the socket is connected. The names that corresponds to the IP address and the port are shown unless the -n parameter is specified. If the port is not yet established, the port number is shown as an asterisk (*).

Because this process is listening on 127.0.0.1, it is secured in that only addresses in the 127.0.0.0/8 range can make a connection, which is a range exclusively reserved for connections only possible by other processes running on that system.


App-based 2FA versus Hardware-based 2FA How do apps like Symantec VIP / Okta Verify and similar implementations compare to using a hardware auth token such as the recent U2F devices?

How real is the possibility of an Android system being hijacked and 2FA app authentication tokens or otherwise secret keys being extracted?

Besides not needing another device, are there any other advantages to app-based 2FA?

Given that with app-based 2FA you authenticate a request or login session in real-time, is it not vulnerable to real-time authentication replay phishing attacks?

Edit: This seems to be sort-of answered here Can a smartphone strictly be viewed as the 'something you posses' factor for 2FA when it has no hardware token capability like smartcards?

Have a look at this answer here for more detail. But here's the salient bits for your question:

The problem with 2-factor as implemented by  Symantec VIP and Okta Verify has less to do with the fact that it's implemented in software, and more to do with the fact that the code can be intercepted.

In this sense, Symantec VIP, Okta Verify, and RSA SecurID are all in the same boat as Google Authenticator; none of them will protect you from phishing because the same technique the attacker uses to get your password can also be used to get your 2nd factor code; usually by getting you to type it into a fake login page.

But U2F is different.

With U2F, you don't type in a one-time-password to show you have your token. Instead, the browser communicates directly with the hardware token, and part of the process is that the browser tells the hardware token the hostname of the site that is requesting identification, and 2FA identities are tied to the individual host. And the browser (unlike the user) cannot be fooled regarding which host is requesting authentication because the browser checks the TLS certificate.

This means that an attacker's website can't get the correct 2nd factor code, and it means that even if a clever social engineering attacker managed to trick a user into giving up their password, the user can't give up their 2nd factor code.

The 2nd factor token can ONLY be used if the browser is communicating with the correct site, and only if the browser is physically connected to the U2F token. This pretty much eliminates any attack that doesn't involve the physical theft of the victim's hardware.

U2F could be implemented (and has been) in software, so you're depending on software on your computer rather than a physical device. This is still better than OTP-based 2FA such as Symantec VIP for phishing resistance, but in this case physical theft is no longer a requirement for exploitation. Instead, if your token is implemented in software, then any intrusion on your computer (virus, etc.) could make a copy of your authentication device and use it on their computer without your knowledge. So it's not quite as good as a physical device, but it's a lot less expensive.


Need some help on Wordpress issue When I am accessing my Wordpress website, for example:

https://example.com/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

it's returning a page containing zero.

Is this a vulnerability? Can someone help on this issue? If this is a vulnerability, how to protect against it?

I am getting lot of logs for particular website."example.com/wp-admin/…; i dont know what the intented output but when i tried accessing the url i got "0".

Since you never know, when new vulnerability will be found, my suggestion for you is to install mod_security on server side.

It's not 100% security, but at least, it will make harder for hacker to perform attacks such as LFI, RFI etc.


In PGP how can I be sure about the public key? I was reading about Protonmail's system and I couldn't find an anwser to something. In PGP communication is encrypted using assymetric cryptography: public and private keys. If you want to send something securely to a recipient you use they public key of the recipient.

To my understanding: in nowadays internet systems to gain the public key of someone usually you (or the client software) looks for the public key from a keyserver. If so this system prone to MITM attacks, in other words it is a single point of failure.

Am I correct that this is the way public keys are distributed usually?
Through a central publicly available server? I know TLS/SSL during keyexchange can prevent the attack, but that PKI system also has it's centralized aspects so, I am asking  disregarding that.

Actually, the naiive approach of just grabbing a key from a keyserver isn't vulnerable so much to a man-in-the-middle attack as to a poisoning attack.

In a poisoning attack, an attacker provides an alternative piece of information, in this case a public key, and somehow tricks you into using that instead of the real one.

In a man-in-the-middle attack, the attacker sits (logically or physically) between you and the system, or recipient, you're talking to, appearing to each end point as the other end point.

That said, you are correct that keys from a key server cannot be trusted immediately. They do need to be validated somehow.

In the PGP/OpenPGP/RFC4880 trust model, that validation is primarily via key fingerprints and signatures.

For the sake of an example, let's say Alice wants to communicate securely with Bob, but neither of them have ever met, nor is it likely that they will be able to meet. Both, however, have access to an OpenPGP implementation and can upload public keys to key servers. Both have gone through the preliminaries of setting up e-mail accounts, creating key pairs associated with those e-mail addresses, and uploading their respective public key to a shared key server.

So can Carol, who would like to be able to read what Alice and Bob are sending to each other. Carol has also somehow gained access to Bob's e-mail account. (Maybe Bob used a weak password.)

The easy way, if Alice is able to communicate with Bob out of band, is for Alice to contact Bob using some other medium, and ask him for his public key fingerprint. If that matches the key that Alice has, and Alice can trust that the person responding is actually Bob and not Carol, then she can very likely trust the key to belong to Bob.

Even if she can't, however, there is a way.

Bob isn't alone in this world. While Alice can't meet Bob in person, a number of other people can and have. Those people can sign Bob's key, which is a statement that they have verified Bob's identity, and that the key they are signing actually belongs to Bob, and not to an imposter. Carol can't get those people to sign her key as belonging to Bob, because that would raise questions on the form "hey Bob, why're you changing keys?", ideally asked in ways Carol cannot control. For example, Dave might pull out his phone book and call Bob on the telephone to ask, since he recognizes Bob's voice, or might ask him at work, because they work for the same company.

So Alice can look at the set of signatures on the key purporting to be Bob's, and then the set of signatures on those keys, and so on. The purpose here is to trace the signatures back to a key Alice trusts, either because she has verified it herself, or because it's a widely trusted key in the community. (For example, the widely distributed official key of the creator of the software, or that of someone associated with a large free software project, can likely be trusted if its fingerprint can be verified.)

Why not just look at the signatures themselves? For one thing, nothing prevents Carol from creating keys and signatures that appear at first glance exactly like the signatures on Bob's actual key. But while Carol can create a trust chain among the keys she create herself, she cannot anchor that trust chain elsewhere. So the trust chain might eventually lead to a key purporting to belong to, say, Werner Koch or Phil Zimmermann, but Carol can't actually anchor the trust chain there because presumably Werner Koch or Phil Zimmermann are very careful about verifying the identity of the owners of the keys that they sign, and the keys that the trust chain leads to wouldn't match their official keys. Finding a chain of signatures leading back to a high-profile key which can be validated as belonging to that individual means it is very likely that the key one started out with has not been falsified.

Alice can also ask others for the fingerprints of those anchoring keys. If multiple people agree that Koch's key has a certain fingerprint, and this matches the one she has, that significantly increases the trustworthiness of Alice's copy of that key.

Yes, there is a fair bit of work to be done if Alice wants to do this properly. That's the price one has to pay for not having a set of super-trusted keys at the root of every trust hierarchy, the way the TLS CA ecosystem (as used by web browsers) works. The flip side of that coin is that every user can decide which keys they actually trust to sign other keys.

Once Alice has verified that Bob's key is legitimate, she'd usually sign it locally (add a non-exportable signature of her own) to it. It'd be non-exportable because she hasn't actually verified the identity of the key holder, so she doesn't want to tell others about that and thus degrading the trustworthiness of her actual key signatures, but she does want to indicate to herself and to the software on her system that she has done some degree of verification of the key, thereby silencing any "this key isn't trusted!" warnings.

Simple, isn't it?


Private key Proof of Ownership Given 2 entities, A and B:
A has a public key( x ) and a private key( x* ).
B has a A's public key hash( let's call it h(x) ).
A has to prove ownership of x* to B.
How could this be achieved, considering the fact that B is not allowed to see A's keys( neither x or x* ), but only A's public key hash( h(x) )?

Question related to A Decentralized Digital Identity Architecture, section 5.4. Achieving Unlinkability With Blinded Credentials

Diagram(Step 4 - Phase B("Online") - prove owner x*):

The general idea behind such proof is that A signs some  message ("challenge") created by B with its private key - and that this signature can be checked.
B creates a random challenge which is then signed by A. It is important that this challenge is not predictable in order to avoid replay attacks. A then sends the signed challenge and the public key to B. B can compare the provided public key against the already known fingerprint (public key hash) and can check the signature with the verified public key. If the signature is as expected then A is the owner of the private key, assuming that the private key was not compromised.

... considering the fact that B is not allowed to see A's keys

The public key is considered public, hence the name. It is not a secret and A can send it to B.


Is there a combination of Windows permissions that allow execution of a .NET executable but not reading nor copying its content? I suppose that if a file is executable by anyone, in other words, if a user has enough permissions to execute an executable in Windows, it will be possible to read the contents of the executable and copy it in another directory in one way or another. However, I have tried to give just execution permission and not read permission to an executable and I've been able to do it when the file is an EXE but not when the executable is a .NET file.

In that case I used this combination of permissions:

Is it possible to just allow the execution of a .NET executable and disable copying the file to another directory or opening it with a dissassembler or debugger?

(Warning: here I am making some "educated guesswork", notably by analogy with what happens in other operating systems.)

The behaviour you describe is normal: a .NET executable is actually a kind of script. From the point of view of the operating system kernel, there is no ".NET". The kernel knows of executable files. For the kernel, a file can be accessed for reading (an application opens the file and then read the bytes with calls like ReadFile()) or for executing (see CreateProcess()). When executing some binary files, the file contents are mapped into RAM through the MMU; at the MMU level, pages have both read and execute rights enabled. However, if the file to execute is a script, then the binary file which actually gets mapped into RAM is not the script file itself, but the interpreter. The interpreter then reads the script contents as data.

Thus, when an executable file is a script, then the actually required access rights are "execute" on the interpreter, and "read" on the script file. The OS will also require the "execute" right on the script file before accepting to locate and launch the interpreter.

A .NET executable file is, from the point of view of the Windows kernel, a kind of script; its interpreter is the CLR virtual machine. For the kernel, the CLR is nothing special. The CLR will read the .exe contents, find the bytecode and interpret it (that "interpretation" will include some JIT compilation but that's another story).

In any case, even if a user has only the "execute" right on a binary file but not the "read" right, then chances are that the user can attach to the resulting process and then read the file that way -- because, at the MMU level, the pages containing the code will be both executable and readable. It seems most unwise to rely on these access rights to prevent reverse-engineering.


Understanding AES Keys and Passphrases I am trying to get my head around how AES works and in particular I have queries around the key generation and 'passphrases'.

My understanding is that AES has a 128 bit block size but the key length changes depending on which variation you use, e.g AES256 uses a 256bit key.

If the encryption is reliant on the key, should you be using a cryptographically secure psuedorandom random number generator in order to generate a 256 bit key?
Looking at this site it also allows you to set a passphrase when generating a key. What role does the passphrase have when generating the key?
If you were required to rotate an AES key due to policy, would the encrypted data need to be decrypted using an old key before re-encrypting with the new key? I'd assume this would need to be built within the application login?

This question is both too broad and too narrow, but I'll see what I can do.

Your understanding about AES block and key sizes is correct.

Usually, yes, you'd want to use a cryptographically secure (P)RNG to generate encryption keys (for any cipher, AES included). However, there are times when this isn't practical, such as when a human needs to be able to remember the key (or remember some data that can be used to generate the key). For situations like that, there are key-derivation functions that turn a "secret" (potentially a password/passphrase) into a key. KDFs don't actually add any entropy, so the resulting key is far more subject to brute-force than a truly random one (a truly random 128-bit key is practically impossible to brute-force, much less a 256-bit key), but sometimes that's a risk you have to accept. KDFs are usually deliberately slow and sometimes (relatively) RAM-intensive, to make brute-forcing the key from a (usually large) pool of potential secrets much slower / harder to parallelize.
I don't know what that site is doing, and without examining its source code I couldn't say with confidence even if it has a "what am I doing?" write-up somewhere. It doesn't require the passphrase (though it produces buggy-looking output without it). It might be using a PRNG (secure or not) to generate a "salt" and then generating a key from that salt and your passphrase using a KDF. It might be using a PRNG - secure or not - that allows you to "add entropy" and inserting the passphrase as added entropy then generating the key out of that PRNG directly; this is not technically insecure but is generally pointless and may be misleading. (For example, Java's SecureRandom class can accept additional entropy but there is approximately never a good reason to do this.) If you want more info about that site, ask it in a separate question.
If you need to rotate any encryption key (AES included) for any reason (policy included), then you need to decrypt the data using the old key before the old key is discarded, or the data will be lost. You then need to re-encrypt the data using the new key, or the data will be in plain text. The usual way to do this performantly is to generate a "master key" that is the one actually used to encrypt and decrypt data, and encrypt (and decrypt) the master key with a user key (which might be derived from a passphrase, stored in a file, whatever). The master key is never stored in plain text, and is only decrypted briefly when it is necessary to encrypt or decrypt the data, or to rotate a user key. This way, rotating the user key just requires decrypting the master key and re-encrypting it with the new user key; you don't have to decrypt and re-encrypt the entire body of data. Since the master key is itself stored encrypted and is never exposed to the user or to any other system (at least, not in plain text), it does not, itself, need rotation unless you suspect it to have been compromised. This is how many systems that need to encrypt large amounts of data, such as full-disk encryption utilities, work.

Without a lot more information about how your application works and what its goals are, I cannot comment on when or where the key rotation process would happen. If you want help with designing a specific cryptosystem, you could ask another question here but you really should hire somebody who is familiar with designing cryptosystems. Cryptography is hard, and rolling your own design - while probably safer than rolling your own implementation of a primitive, much less designing your own primitive - is still a risky business.


What are the exact security risks of having JavaScript enabled? There are a lot of websites out there that state that you should disable JavaScript because of the possible security risks. There's also a reason that an AddOn like NoScript has been developed and is used a lot.

Now, the times I have used JavaScript to enrich user experience the most harming code I was able to have run in the browser was basically just a loop with spamming alert messages, this is more of an annoyance than a security risk though and can easily be disabled by the user on up-to-date browsers.

However, NoScript exists and thus JavaScript can probably do more harm than just message boxes. What real security risks can be exploited when having JavaScript enabled and visiting a website that has malicious JavaScript code? (Assuming a modern JavaScript engine and browser (Chrome, Firefox))

Can information outside of the browser be accessed and sent off to the server?

Can files be downloaded to the client computer without the client's consent?

What serious security threats are there that solely rely on the client JavaScript code that the browser allows?

What serious security threats are there that solely rely on the client JavaScript code that the browser allows?

One risk are buggy implementations which can be used to crash the browser or execute code by using heap spraying attacks or similar. These can be kind of mitigated within modern browsers by using ASLR, DEP, sandboxes and similar techniques.

More interesting are attacks like Cross Site Scripting (XSS). These attacks can be used to steal authorization credentials (i.e. passwords) or hijack existing sessions. This way they can be used for identity theft or misuse. They work because the same browser is used for different web sites (i.e. banking and looking at cats) and this way it tears down security borders between these sites. Same Origin Policy is only of limited use in these cases.

A typical case of such attacks is the inclusion of third party scripts into a web site. This can be external Javascript libraries, tracking code like google analytics, buttons for social networks or advertisement. This included code is out of the control of the original web site but still has full access to the site inside the browser and can thus read information from it, fill in forms or read their content, navigate the user to different sites, press like buttons,  inject advertisements or malware etc.

Apart from that Javascript can be used to fingerprint the browser in a more detailed way which might be a problem especially when trying to be anonymous.

  Can information outside of the browser be accessed and sent off to the server?

It should not be possible to access files on the local machine (at least not without notification) but with attacks like DNS rebinding it can be possible to read the contents from intranet web sites and forward these information to the attacker.

Also bugs in local or intranet servers can be used to hijack connections to third party side like done in this example of same site scripting.

  Can files be downloaded to the client computer without the client's consent?

This can usually not be done with Javascript alone but is often done by using bugs in Flash or Java.


Security concern for Single Sign On implementation I'm trying to build a single sign on system that connects app A to B and B to A. Unfortunately, the option to use OpenID/OAuth/SAML is not possible right now, so I am building a basic solution myself, here's how it goes:

User logs in to App A
User clicks on "Go to App B" link
Server for App A generates a JWT token containing the user ID and expiry date, saves a hashed output of this string in a shared location (like Redis) and redirects to App B's endpoint along with the token
App B hashes the token it received and checks if it matches the hash that's in the database. If it matches, then it checks to see if the token has expired and rejects/accepts the request based on the evaluation.
App B makes a call back to App A along with the token and a "SUCESS" message.
App A again hashes the token and checks in the database to see if the two hashes match. If they do, then App A issues a temporary authentication token to the client.
For all future requests to App B, App A passes along the temporary token (which App B validates against a secret key) and App B grants the request (if not expired and rejects if expired)

This is the approach that has been implemented and functional, but I wanted to know how secure is the logic. Do you see any obvious security concerns with this implementation?

As the colleagues have pointed out, your SSO logic is sound here.
To improve it a bit and make it faster perhaps, you may end at Step 3 as long as you use the private key in Server B to validate the JWT generated by Server A.

Of course, we are assuming a few things here at each step, for example:

Encryption => we are assuming the whole system is using a robust encryption mechanism to pass these JWT tokens back and forth and are safe from prying eyes.
Server A and Server B validates input from each other - in other words, Server B does not implicitly trust that Server A will always send JWT tokens, because requests/responses can be intercepted.
Denial of Service Attacks - the system can fend off these attacks.
Speed - sufficiently fast
Alert admin of other security attacks


Font risk in unopened email in inbox This is obviously not from PayPal, but the font in the word account displayed using odd looking font, is this a security risk to me that Outlook.com displayed this font? See below, Outlook has preview text enabled as default

Nope, that's not actually a different font, it's Unicode. There's no exploit at work here.
Specifically, it's either another language's character set or, more likely, mathematical alphanumeric symbols like these, which are all rendered from the same font:

For other examples of abuse regarding mathematical alphanumerics, search twitter for fakeunicode mathematical or just follow @FakeUnicode, an account dedicated to the oddities of unicode and unicode abuse.
This is a technique used to evade spam detection.
Here's what a computer sees given  rather than Account:
$ echo "Here's what a computer sees given  rather than Account" |hd
00000000  48 65 72 65 27 73 20 77  68 61 74 20 61 20 63 6f  |Here's what a co|
00000010  6d 70 75 74 65 72 20 73  65 65 73 20 67 69 76 65  |mputer sees give|
00000020  6e 20 f0 9d 99 b0 f0 9d  9a 8c f0 9d 9a 8c f0 9d  |n ..............|
00000030  9a 98 f0 9d 9a 9e f0 9d  9a 97 f0 9d 9a 9d 20 72  |.............. r|
00000040  61 74 68 65 72 20 74 68  61 6e 20 41 63 63 6f 75  |ather than Accou|
00000050  6e 74 0a                                          |nt.|

This hex dump shows that  is not ASCII.  is represented by three bytes, 0xf0 0x9d 0x99, which is U+1D670. Contrast with A, which a single byte, 0x41.
Most anti-spam systems parse text using patterns and/or models of word frequencies. By altering the text, your spammer has altered how the anti-spam systems see the message. This message's subject does not technically use the word "account", so a rule seeking that pattern or a model using that word won't recognize it.
Smarter anti-spam systems will account for this in some way by massaging the text into ASCII and/or by specifically hunting this sort of obfuscation technique. Word frequency models can learn about "words" like this as well.


Drawbacks of using ADFS for SSO for external users Is there any drawback for creating a separate AD forest for external users of organization to authenticate them to access some web applications? Is there any performance and synchronization issues when the number of external users reach over 20,000 or 50,000?

Is it a bad idea to create a separate domain and authenticate external users against AD and build an SSO using ADFS; or it makes sense to use third party identity management and SSO solution like auth0, Okta, CA?

What benefit I would get if I rely on these commercial third party solutions?

The only reasons to create a separate AD domain is to have a different password policy, to segment replication.

You can minimize risk of a compromised DC only by having a new forest.  Any domain in a forest can result in compromised Enterprise Admin credentials.

The ADFS server must be trusted by both domains, so a Domain trust or a forest trust is needed.  If you don't do this, then home realm discovery will become difficult.

If you intend to use MSFT online, Azure AD for synchronization, multiple domains and forests are supported but it's more complicated.  Just know that when you provision in one location (US) it doesn't allow you to share the same namespace in the UK.  (e.g. user@domain.com is country specific).  This is a temporary limitation that will be corrected soon.

ADFS vs Ping vs Auth0?  Well who are you integrating with?  What are your in-house skills?   do those providers have the PII protections you require?

Yes, AD can scale to over a million of objects (the US Army/Navy has a massive AD forest). This info is from 2007 so I'm sure it's much higher now.

Question for you - what do you have resources for: one perfectly robust AD infrastructure, or two infrastructures?  (e.g. isolate the outages/load)


Using Tokens to Keep Users Logged In I'm a PHP web developer who has been reading up on security recently and consequently this question entered my mind: How to properly and securely authenticate already-logged in users with a token? I've seen the technique mentioned several places, but I haven't found a demonstration of it.

I implemented a version of it myself that works like this:

The user logs in using his username and password. (Stored using a 1024-bit pbkdf2 hash)
A random token is generated then MD5'ed using the following PHP code: uniqid(mt_rand(), true)
This information is stored in the database, a PHP session, and a cookie.
When the user accesses a page, a function is called that checks whether the token in the session or cookie matches the token stored in the DB. If it does, the user stays logged in, if not, the user is logged out.
Every time a request is sent to the server, this function is called and steps 2-3 are repeated.

A good thing to do when proposing a security concept, is to create a list of scenarios, that it needs to protect against. Without that framework, it is hard to comment.

Let's compare it with session handling:

The user logs in (or accesses the site)
A random token called sessionid is generated
The sessionid (and other information linked to it) is stored on the server (in a database, filesystem or memory)
When the user accesses a page, a function is called which checks the session id and reads associated information. If the sessionid is valid, the user stays logged in. If not, the user is logged out.

So the main difference is step 5, in which you generate a new token for the next request.

So if one request is missed, the user will be logged out. This might help a user to detect that he was a victim of a CSRF attack. But being logged out will most likely not raise much suspicious to normal users.

You force a strict order of requests. If two requests are processed in parallel (e. g. opening two browser tabs within a short time frame), both will send the same cookie. As a result, one tab will fail and the user will be logged out.


How can I promote good password practices in an organization that doesn't currently care about that? I work with an organization that uses some very poor practices such as using default user accounts, default passwords (or passwords the same as user accounts), sharing password information between users, ect.

I've tried to keep my parts of our codebase/ect secure, my programs use proper database logins and permissions, strong passwords ect. But my programs are vulnerable to the greater organization's flaws. If, for example, someone could get ahold of certain account information, the security in my applications is meaningless.

Can I help here and there to change this company's security practices or are my efforts doomed because of the "weakest links"? For the most part my security practices are only as safe as theirs.

I recently came across this article written by Ross Anderson. Apart from pointing out to your colleagues how quickly bad passwords can be broken, it is worth noting that their research showed some benefits in just reminding people some good rules for passwords and having a basic induction into password choice.

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf

If possible, look for why people are choosing default passwords or sharing accounts and see if there is a way around this. Consider the example of ssh-ing into multiple servers  and allowing some of the support staff to do the same. Rather than having a single password that everyone knows, you can use keys here so that they don't need to remember anything. They just log in with the key. If you need to revoke the key, remove it from the server (this is obviously just an example).

Education is the key as well as ensuring people can still easily get on with their jobs. Just demanding everyone chooses a length 16+ password, with multiple cases & special chars which they then have to type in 25+ times a day is not an acceptable solution. They simply won't do it and will fall back to using a 6 character password they use everywhere else as it is easier.


Public key encryption confusion I'm learning Linux, and currently SSH. But there are details that I don't really understand.

I've seen and understood how Diffie-Hellman key exchanges work from a mathematical point of view, but what I would like to understand is the symmetric key that is generated for further communications. Everything starts with a large prime number g (generator) and n, that we use combine in some ways using discrete logarithms with a private number to generate the public key which is only used for encryption. This key is a number, so how can a number encrypt a message?
Even the symmetrical key obtained is also a number, that will be used for encryption and decryption. Suppose the calculated symmetrical number obtained is 16, how can 16 encrypt a message Good morning that I send to someone and then the same number 16 decrypts the message at the other side?
I've also read that after a key exchange algorithm, AES symmetrical algorithm can be used for further communication. So is AES the symmetrical key generated by Diffie-Hellman key exchange? Is AES a number obtained after calculation using discrete logarithm?
I've also read that RSA can be combined with Diffie-Hellman to enhance security to avoid a MitM attack. So what does RSA really add to the existent key exchange algorithm?
After executing ssh-keygen -t rsa, a key pair has been generated, but when I open them in a text editor, I don't see nothing like prime numbers. It's a different format.

Now I'm really confused about how all this math is related to encrypting data exchanged between 2 computers.

This key is a number,so how can a number encrypt a message?

A number is represented as a sequence of bits - this is the key.

  is AES a number obtained after calculation using discret logarithm?

AES is an encryption algorithm - see wikipedia:AES. The algorithm uses a key (sequence of bits, see last point) to encrypt some payload and the same payload is used for decryption. Think of something like XOR where the same "key" can be used to "encrypt" some message and "decrypt" it again - only much better than XOR.

  ... so what does RSA really add to the existent key exchange algorithm?

RSA in the context of SSH adds nothing to the key exchange algorithm itself. But it is used for authentication so that the client can be sure that it does the key exchange with the expected server and not with some man (attacker) in the middle (MITM).

  After doing ssh-keygen -t rsa command,a key pair has been generated,but when i open them in a text editor,i don't see nothing like prime numbers,it's a different format.

Again, a number is a sequence of bits. Such a sequence can be encoded in a variety of ways, like as a decimal number, as some hexadecimal number, as a sequence of 1 and 0 and much more. What you see there is a specific encoding of these numbers and also some additional packing information.

  Now i've got reall confusion about how all thoses maths are related to encrypt real data exchanged between 2 computers like,messages,photos,videos,etc.

It looks like you are confused because you think as numbers only as something written down as sequence of digits between 0 and 9. But this is just one specific encoding of how numbers can be represented. For the computer everything is just a sequence of bits - everything else (digits, characters, images ...) is just what a specific sequence of bits means for the human.


WireGuard / CVE-2019-14899: How secure the protocol really is? I've been using OpenVPN and SSH tunnels for a multitude of scenarios over the years and recently I've been earning a lot of buzz around the simplicity and security of WireGuard. Now I've found some troubling information about CVE-2019-14899:

An attacker that controls your L2 link (i.e., your WiFi or LAN) can
send specially crafted packets to your device. The attacker can then
use those packets to actively probe for certain properties of the TCP
connections originating from your device. In other words, by
controlling a device’s access point to the Internet, an attacker can
infer if the user is connected to a specific host and port.
Additionally, if a TCP connection is unencrypted inside the VPN tunnel
(if you visit a page that uses HTTP instead of HTTPS, for instance),
the attacker can inject packets into that specific unencrypted stream.
This would allow an attacker to feed your device fake HTML content for
that particular stream. That would be dangerous, but as previously
stated, the attacker must target a specific TCP connection, so it is
not a simple vulnerability to exploit.

Source: https://protonvpn.com/blog/statement-on-cve-2019-14899/

Is this information technically correct?
Some sources on the web also state that anyone controlling the WAN of the server will also be able to take advantage of this flaw. Is it true? Can the server's ISP exploit this?

Assuming the information is correct:

Why does it matter if the "TCP connection is unencrypted inside the VPN tunnel"? In theory one uses a VPN exactly to go around this issue - to make sure nobody can see the contents of the communication between two machines;
If anyone controlling the client's LAN can inject packages, how is this even considered a secure protocol? From my understating authenticity validation is a must in scenarios like this. The server should be able to check the authenticity of new data instead of blindingly accepting it... Isn't there some kind of key exchange for this?
According to Wireguard's website "mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface." How is a 3rd party (that doesn't have the right keys) able impersonate the client, send data and then how the server decrypts it using the client's real key without errors?

Thank you in advance.

Is this information technically correct?

Yes, but please note that there is a modification of the previous attack which cannot be stopped by the previously recommended mitigations - see Blind In/On-Path Attack Disclosure FAQ.

Some sources on the web also state that anyone controlling the WAN of the server will also be able to take advantage of this flaw. Is it true? Can the server's ISP exploit this?

This is a completely different scenario. The connection from VPN endpoint to server is not protected by the VPN anyway. If the attacker controls this part much easier and more dangerous attacks are possible.

Why does it matter if the "TCP connection is unencrypted inside the VPN tunnel"? In theory one uses a VPN exactly to go around this issue - to make sure nobody can see the contents of the communication between two machines

The attack is able to inject packets into an existing TCP connection. A normal TCP connection has only limited protection against this (i.e. random source port and sequence numbers) which are bypassed by the attack. If the connection is additionally protected by cryptography than this injection will no longer work. Note that "encryption" is actually neither required nor sufficient, but the point is integrity protection. But proper encryption protocols like TLS also include integrity protection.

If anyone controlling the client's LAN can inject packages, how is this even considered a secure protocol? From my understating authenticity validation is a must in scenarios like this. The server should be able to check the authenticity of new data instead of blindingly accepting it... Isn't there some kind of key exchange for this?

From the perspective of the server the data don't look wrong, i.e. nothing can be detected here.

According to Wireguard's website "mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface." How is a 3rd party (that doesn't have the right keys) able impersonate the client, send data and then how the server decrypts it using the client's real key without errors?

This is not an attack against the encryption at all. The original attack CVE-2019-14899 worked by the client accepting plain data on a different interface and treating these the same way as the decrypted data from the VPN tunnel interface, thus making injection possible. That's why the attack is also independent of the actual layer 3 VPN technology used.
In other words: the OS (not the VPN) is merging trusted data coming out of the VPN interface (after decryption) with untrusted (attacker controlled) data coming from a different network interface. It is not an attack against the VPN layer itself but how the VPN is integrated into the OS.


What is the term to use when logging an event where a user downloads or prints PHI? My application logs accesses to PHI. I need to add a log item for things like downloading and printing.

Is there a general term that I can use to describe these events? I'm thinking something like "export" or "externalize".

I want to represent that the user took an action which yielded a file or hard-copy of PHI which my software can no longer track.

RFC 3881 details a format for capturing security audits in healthcare applications.  It is the starting point for audit logs in the DICOM standard and IHE.

In any case, it discusses Export and Import events specifically in the case of printing and creating media. I would stick with the term Export.


What to add to a repeating security checklist? I work in a smallish company (100-200 computers and a handful of servers) and I am trying to come up with a checklist of things to check at a regular basis, such as weekly, monthly, etc.  We use Windows servers and Lotus notes.  I currently have: check logs, check for users in AD and Notes that no longer work here, check admin rights and check for holes in the firewall.  I have basic security knowledge so where else should I look to clean up security holes as well as check for signs of an unnoticed attack?

CERT's Windows Intruder Detection checklist is a good start.

  This document outlines suggested steps for determining whether your Windows system has been compromised. System administrators can use this information to look for several types of break-ins. We also encourage you to review all sections of this document and modify your systems to address potential weaknesses.

It points out in particular that logs, while possibly useful, are not reliable for detecting intrusion.

  Proactive auditing and monitoring are essential steps in intrusion detection. It is ineffective to audit altered data or compromised systems -- their logs are unreliable. Establish a baseline for what you consider normal activity for your environment so you can determine unusual events and respond appropriately. See section C16 of this document for more information on audit settings and events useful to detect successful attacks or attacks in progress.

At a broad level, their checklist is

  A Word on Rootkits
  Examine Log Files
  Check for Odd User Accounts and Groups
  Check All Groups for Unexpected User Membership
  Look for Unauthorized User Rights
  Check for Unauthorized Applications Starting Automatically
  Check Your System Binaries for Alterations
  Check Your Network Configurations for Unauthorized Entries
  Check for Unauthorized Shares
  Check for Any Jobs Scheduled to Run
  Check for Unauthorized Processes
  Look Throughout the System for Unusual or Hidden Files
  Check for Altered Permissions on Files or Registry Keys
  Check for Changes in User or Computer Policies
  Ensure the System has not been Joined to a Different Domain
  Audit for Intrusion Detection


Software updates APIs authentication We need to improve a system that delivers software updates (firmware/software files) to a Bluetooth device through a "companion" application installed on customers smartphones (ios/android).

The update process is implemented through calls to a REST API server (ASP.net, TLS 1.2) and being "userless" (but with different apps) we used OAuth2 with "client_credentials" flow, until now.

We used the "client_id" and "client_secret" couple to identify the caller application and then inject some claims into the bearer token, useful for example, to give different firmware to different applications. At the same time we used this system to prevent unauthorized API requests.

It works, but i never loved this system completely for various reasons, for example:

Without users, the token server doesn't create only overhead?
Storing client id and secret (in clear text) into mobile apps is secure?

I've read of API keys, but as this post says are not enough.

I think that we're "stretching" OAuth2 purposes to our needs, there are better ways to manage this?

Storing the client_secret in plain text is not a good idea, ios does enable data at rest encryption by default but for android you need to do some work yourself

As for the way you are using OAuth2 I can just say, it works for your use case. Perhaps this article will help you come to terms with your current set up, among the important parts it states:

  "...one of the key reasons for OAuth2 to exist is so that Client
  applications do not need to collect user credentials (as they did with
  Basic authentication).

  The Client has to obtain an access token, and to do that it has to be pre-registered with the Authorization Server, and it has to authenticate itself at the token endpoint.

So I would argue that, as per design and in terms of security, having to request the token is one of the strengths of OAuth2.

If you are looking for alternatives to deploy your software updates my opinion is that using the default app stores should be sufficient. An update does not need to be the most minimal piece of data needed to accomplish the business goal, it can be the same package as before with new data for use, what I mean is that your software update is the wrapper application which gets pushed to the app store and upon installation tries to push the updated data (not necessarily the entire app) to the bluetooth device.


When using https but not DNSSEC, under what situation, a client is vulnerable? So DNSSEC is to ensure that returned IP address is not poisoned. And https is to verify the remote server.

My question is that when protected by https, under what circumstances, a client is vulnerable?

Say I go to https://www.facebook.com, even if I'm not protected by DNSSEC, what damage can an adversary cause? Let's assume no DigiNotar stuffs.

Thanks

Properly used https can mitigate the risk of not using DNSSsec because it is checked if the endpoint is the expected one by validating its certificate. Also, the data transport itself is protected. There are several things which can go wrong with https itself (weak ciphers, errors in validation process, too much trusted root CAs with same rights....) but if we assume that all this is handled properly (which is often not) https will give you the following protection:

You talk to the correct server.
The traffic between browser and server is protected in transit against sniffing and modification.

That's all you get.

Notably absent are protections against attacks caused by insecure web applications or bugs or design errors in the browser, that is CSRF, XSS, exploits using Flash, Java, Silverlight, ActiveX, include of 3rd-party code by the site you visit (i.e. social networks, tracking, advertisements...) and all the other typical attacks in today's web. And https will also not help if your computer is already compromised by malware or some security or helper software which does more harm than it helps.


Can Snort inline/blocking mode block traffic from one host to another on internal LAN? I'm putting Snort on a wifi router. My understanding is when in inline/blocking mode, I have to bridge a LAN interface to the WAN interface for packet inspection. If this is the case, it does not seem possible to detect/block an attack from one host to another host on the same LAN because the traffic will not go out the WAN interface.

Is this correct? If so, is there a configuration that would support detecting / blocking an attack from host to host on the same LAN?

It depends GREATLY on the configuration of your network. To simplify this, I'll assume you're running on a flat network.

To have Snort inspect all LAN>LAN traffic inline, you would need to ensure that there are no L2 devices interconnected below the Snort device,which I'm not sure is practical.

In a normal network configuration, all inter-LAN traffic would take place at layer 2, and would never reach the Snort box, as it would never leave the layer 2 switching infrastructure.

I don't know that there is a practical way to have Snort act as an IPS on entirely LAN-based traffic unless it's in-line at layer 3 between two different LAN networks.

Probably the best solution if it is a flat network you would like to monitor would be to mirror a port on an L2 switch and send all of the traffic to Snort there, acting as an IDS. Note that it must act as an IDS in this scenario because while it can SEE the traffic because it is being mirrored to it, it cannot act on this because it is not responsible for forwarding the traffic as it would be in an L3 inline configuration.


Multiple CAs signing a single Cert/CSR? Just saw this suggested on Slashdot

  So I've seen quite a few people wanting a switch to self-signed certs (who IMO mostly don't understand what making that secure actually involves), and an idea to check certs from different network paths (which doesn't work if your only path is compromised, and how do you secure the communication to the service that does the check for you?).

  So here's an alternative idea: Require multiple CAs.

  Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

  Compromising multiple CAs in the same timeframe to create a cert would be considerably harder than creating one. More importantly, it'd make revoking large CAs much easier.

  Let's say that the new norm is to have a site's cert is signed by 5 different CAs, and that the minimum acceptable amount is 3 signatures.

  Then, if Verisign gets compromised there's no problem with pulling their cert: you're down to 4 valid signatures on your certificate, which is still fine. That should put considerably more pressure on CAs to perform better.

  Even Verisign wouldn't be able to trust that their security problems would be let go due to their popularity, as even the largest CAs would be completely expendable without the end users needing to care much. The site would just go with a different 5th CA to return back to the full strength.

It sounds like this would work (although you'd get a security rating as opposed to binary cert validates/doesn't validate). What about viability? Could it be done within existing standards? I can't comprehend if one would issue the same CSR to multiple CAs, then provide a whole bunch of certs to the browser...of if you'd just have one cert signed in sequence by multiple CAs.

On changes to SSL/TLS: the SSL/TLS protocol sends certificates as anonymous blobs which can have any size, up to about 16 MB (which is ludicrous). The protocol itself needs not be changed if one wants to use some new certificate formats.

SSL/TLS implementations expects the blobs to be encoded X.509 certificates. Such a certificate has room for a single issuer (the CA name is written in it) and a single signature. So you cannot have a "multi-signed certificate" within the bounds of the existing X.509 standard. You could get several certificates, with the same public key in each, and then you would only need some sort of convention so that the SSL client software does not mind receiving more than one certificate for the server, and checks them all.

About issuing the certificates: a certificate request is just a vessel for the requester public key, and his intended name, and any kind of information which the CA is free to replicate, or not, in the issued certificate. There is no theoretical problem in having several certificates, even from distinct CA, which all contain your name and your public key; actually, any CA could issue such a certificate without needing any interaction with you. They could all use the same certificate request. In practice, it would require some changes, because existing CA issue certificates as part of Web-based scenarios, where the buyer's browser is instructed to generate a new key pair, and send the public part to the CA without any interaction with the human buyer. Since the idea of having each server own at least 3 certificates basically triples the market of server certificates, I am quite sure that commercial CA would be willing to implement the relevant tweaks to their platform.

On the soundness of the idea: requesting multiple validation is a sound idea (the OpenPGP format already does it, mostly to deal with the inherent unreliability of a web-of-trust CA) but it may backfire: if having a single rogue or compromised CA does not impact general security, chances are that the next Comodo-like event will receive less publicity, possibly none at all. Multiple validation tends to encourage general leniency and loss of responsibility.

On Convergence: what the slashdot quote talks about is Convergence. This is a new system trying to get a foothold. See this answer for some details and pointers on the protocol.


Is there a reason to use both SSL & IPSec together? As I understand, IPSec protects packets at IP layer and SSL/TLS at transport layer?

Is there a scenario in which we might want to use both?

Absolutely. In fact, I'm posting this answer using both IPSec (via VPN) and TLS (via HTTPS). As you noted, the technologies are similar as they both provide confidentiality and integrity on communications. Sometimes, as discussed in gowenfawr's answer, there is little value of using the two combined, but sometimes there is value.

Both protocols encrypt the contents of messages but leave the envelope unencrypted. The envelope contains information about the protocol being communicated and the site that you are communicating with. So, someone watching my home network connection can see that I'm using IPSec to connect to my VPN provider but they cannot tell that I'm posting on StackExchange. If I wasn't using VPN, someone monitoring my home network connection would see that I'm posting on StackExchange (specifically security.SE), but not be able to see what I'm posting or to what question I'm responding to.

I should point out that the VPN doesn't totally hide my connection to StackExchange, it just hides it between my home and my VPN provider. Someone watching my VPN provider's outbound connection would see the posting to StackExchange, they just wouldn't be able to match it to me.

So this answer posting is IPSec and TLS encrypted between my home and my VPN provider and just TLS encrypted from my VPN provider to StackExchange.

Whether this is an interesting distinction or not is up to you. It will likely depend on the task you are performing.


Security Assessment v/s Security Engagement Breakdown I had this couple of threads in here which talks about security assessment v/s risk assessments, but here the idea is completely different. Suppose, I had to breakdown qualitative tasks from the quantative ones, I would end up breaking these.

I came up with this model and was wondering if I am on the right path to understand them more better. Here's my model:

I break up the 'security' into two - quantitative analysis and qualitative analysis
I again break them into specific tasks which I found via the WWW

So in particular, the first segment i.e: 'security assessment' fits more to the quantitative tasks and 'security engagements' fill up more towards qualitative task. This is how I look at it now:

Security Assessment

Risk Assessment
Threat Assessment
Security Compliances

Security Engagement

Code Review
Vulnerability Assessments
Penetration Testing
Red Team Enagagements

The first pointer has all the assessments and compliances compiled up and the second one is more of defensive + offensive approaches taken to 'quality' test the risks accessed in the first pointer. The defensive ones are code review and vulnerability assessments since the organization is taking up the engagement from teh defensive viewpoint and the latter two are offensive since it's challenging an auditor to find loopholes, break-through and actually exploit.

My question at this point is all of this concept is true or I have been missing on something since there are lot of more terms!?

There are plenty of risk assessment methodologies. You first question should be "why building yet another one"?

The ones which exist are either generic (COBIT-based, NIST SP 800-30, Mehari, ...) or specific to an area (the EU Critical Infrastructure Protection for instance).
By using an established methodology you build credit in what you will deliver.


How does encryption/decryption work when one generate random key? I am new to this and want to ask a basic question. Suppose I used my password (say "ABC123")

to generate a key using the PBKDF2 algorithm (or any such algorithm). For encrypting a file I'll

input my password and a key will be generated. This key will be used to perform encryption.

Now, suppose if I want to decrypt the same file, I have to enter the password ("ABC123") again.

The key will be generated again to do decryption.

My question is, will the keys generated during encryption and decryption be same?

PBKDF2, as the name suggests, is a key derivation function. It means that the algorithm takes some parameters (including a password since it is a password based key derivation function) and produce a key of arbitrary length. Even if PBKDF2 is expecting some random values as parameters (for instance, the salt), when you pass the same parameters to the function, it always returns the same key.

It means also that when you are using PBKDF2 to encrypts a file you also have to store all parameters (i.e. for PBKDF2: the Pseudo-random function, the salt, the number of iterations, the length of generated key) along with the encrypted file. Indeed, these parameters will be necessary to recompute the same key from the same password when decrypting the file.


Security of SPF vs SPF and DKIM in email I am looking for an email provider that I will use with custom domain, one provider is cheaper but has only SPF while the other is more expensive but uses both SPF and DKIM and I'm not sure if paying more is worth it if the other factors are similar. I read about SPF and DKIM and I have some questions about them and also some about email security in general.

What benefit would DKIM provide if SPF is already used?
Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?
If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?
Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?
If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?
Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?

What benefit would DKIM provide if SPF is already used?

If a domain has SPF configured the receiving mail server can check if the claimed sender of the mail according to the SMTP dialog (i.e. MAIL FROM) is allowed to send mail from this IP address. This helps against sender spoofing only a bit since only the sender based on the SMTP dialog is checked but not the From header of the mail. But mail clients usually care only about the latter one.

With DKIM the outgoing mail server signs a mail and this signature can also be checked by the sender, i.e. not only by the receiving SMTP server. This signature might include the whole body but might also be include only part of the body. And while the From header is part of this signature it does not mean that the From header must be from the signers domain which means spoofing is still possible.

Spoofing of From is only addressed by configuring a DMARC policy which requires that the domain in the From header is either protected by SPF or DKIM and which specifies a policy when the requirement is not met.

  Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?

E-mails don't claim to be from a specific server but from a specific domain. And like I said both SPF and DKIM alone don't protect against spoofing the From header. And DKIM only protects part of the mail against modification: usually it protects the full body but might be configured to allow extending the body. And it only protects some headers but not all.

  If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?

Mail is delivered hop by hop and even if it is encrypted with TLS this only is relevant between the hops. So there are many parties involved which have access to the unprotected mail and could modify it.

  Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?

If the attacker can spoof DNS MX records which specify how a mail gets delivered or if the attacker can intercept the mail on unprotected transport or at one of the hops the attacker can modify it. But the attacker cannot simply put a server on the internet and declare it to be the responsible server for the domain, he must other parties convince that they send the mail through this server (i.e. spoofing DNS MX record).

  If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?

The messages travels encrypted from your mail client to the mail server of your provider, is decrypted there, modified (Received header added, maybe DKIM header) and the re-encrypted again to transport it to the next hop which might be google already or might be another upstream mail server.

  Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?

While the attacker can add a Received-SPF header to the mail and thus claim the it did check for SPF a mail server (MTA) on the edge between internet and intranet receiving this mail might check again from which IP address the mail really comes, i.e. it will not trust the Received-SPF header. This header is mainly used by spam checkers which want to incorporate the result of the SPF test into their reputation check but don't run at the mail server and thus don't have access to the original IP of the sender.


What to share (OpenPGP key ID or fingerprint) once key uploaded on key server? I have uploaded my public key on:
https://sks-keyservers.net/

When sending mails, I want to notify the recipients about my public key just in case they want to use it.

Since the key is on key server, I want to know what to share in the email: key ID or fingerprint?

Fingerprints and key IDs are related: short and long key IDs just form the lower 8 respective 16 hex digits (32 respective 64 bites) of the fingerprint.

An example using my own fingerprint:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

Shorter identifiers imply larger chance of collisions (malicious or by chance). Never use short key IDs, at least rely on long key IDs. If providing the full fingerprint is not an issue, share the full fingerprint. Short key IDs can be collided within seconds using graphic cards. The long key ID is considered save for now, but only unless somebody figures out more advanced attacks: there is not much buffer left that prevents brute-force attacks. The space of possible fingerprints is vast, and collision attacks are not feasible.


OpenVPN through company proxy and surfing history Been trying to find an answer to no avail. Probably I just don't understand the terminology... So if anyone may shed some light in plain English, that would be awesome.

I connect to a paid VPN through the OpenVPN protocol and at work, I connect through the company proxy, so I have set up the VPN to use the company proxy. That works fine.

How secure is such a connection? Does the company proxy know where I connect to and can the proxy know what websites I surf to?

OpenVPN is the only protocol the proxy allows me to use. PPTP is somehow blocked.

Thanks for your answers.

OpenVPN is a 'SSL VPN'.

Therefore, the IP address your VPN client connects to is known to the company proxy.  The traffic within the tunnel should not be visible to the proxy.

OpenVPN's long-running SSL connections are also a giveaway.

However, if you are using a Windows workstation provided by the company, chances are that it has anti-virus and other monitoring software on it and there is a good chance that admins can know what you are up to because your browser history and the network requests to the local workstation's networking subsystems are still loggable.


What key attributes indicate candidate potential for future success in a security career? So you are looking to hire a fresh graduate to work in an entry-level/trainee IT security role that covers a wide range of tasks: vulnerability research, penetration testing, secure software engineering.

Assuming that you will invite to interview candidates with general degrees in CS/IT and no specific experience of security; what key attributes would you be looking for?

e.g.

An interest in security (obviously)
An appreciation of current problems in the field
Understanding of cryptography

Related question: I see entry level security skills as a problem for industry - what can we do about it?

[can't add new tags: recruitment]

Generally, you can't expect domain knowledge of a fresh graduate in any field, so you're looking for someone who can solve problems, shows interest in /your/ problems, and will be pleasant to work with. For example, cryptography isn't even common on Computer Science courses, and it's not only CS graduates who will be applying for jobs.


A Question about Database Encryption I've been looking around for an answer to this for some time now and I felt that this place would be a good venue to ask this.

How can one improve the security in a MySQL database?

The database that I am currently playing around with only has its data encrypted. This being the values in the tables are encrypted before being placed in the database.

Other than that, how can I improve the security and what do some readings mean by "database encryption"? I've read about some third party programs that can encrypt the whole database and maybe even a certain table only.

Also, to what kind of data do this programs affect? I imagine them only affecting only the "Data at rest". Or is it that there are live applications out there that interact with a live encrypted database?

I know that my question may seem to be all over the place but to sum it up:

1) What does "database encryption" mean? Is it field-value encryption or whole database encryption?

2) Do database encryption programs apply to live databases? Or only to archived/backup-ed databases?

3) If live databases were to be encrypted, surely the code of the application that uses it would need to be changed, right?

4) What are some programs that you guys recommend for "database encryption"?

5) Would using Bitlocker to the drive where the MySQL data is stored be a good alternative?

1) Yes, both are available.  Databases can support field level, table level or full database security.  They can also support externally controlled keys (provided by the client on connection to the DB) or DB managed keys (that are stored in the database and protected by the client's login credentials.)

2) Database encryption that doesn't apply to a live database would just be file encryption, though database encryption does still protect a live database that has been archived or backed up.

3) Not if the encryption is handled by the DB itself.  The login account can unlock encryption keys stored in the DB and a good DBMS can handle the encryption/decryption transparently.  If the encryption keys are handled by the client, then the connections would have to be updated to provide the key when accessing the data.

4) Any good DBMS should include built-in support for database encryption.  You should not need a third party tool.  A third party tool is not going to do as good of a job since the DBMS needs to know how to access the encrypted records to do a good job.

5) It is not a bad alternative, though it is not nearly as secure.  Encrypting a database protects not only against data at rest, but also against data being compromised while the server is running.  If the server itself is compromised while running, Bitlocker will do nothing to protect the database.  Database encryption on the other hand will protect the data even if both the server and the DBMS are compromised (though a severe DBMS compromise might allow leakage when records are accessed by a legitimate user).


If not using HTTPS/SSL/TLS is such a security risk, why don't sites/browsers force HTTPS for all sites that have it? From my other question Besides Plain-Text passwords, is there anything to worry about with sites that don't use SSL?

there are answers that mention all sorts of things that can happen if there is no SSL, including malicious attacks.

If there is such a risk of bad things happening, why is HTTPS not forced?  I can understand why a site might not have it enabled, but wouldn't the browser automatically set it up? I was searching Google and it mentions that there are ways to enable it for browsers in not so easy ways i.e., Chrome was said that you should enter "X" into the URL to force HTTPS, but not sure why this isn't a normal setting?

Because that's not easily automatable

  If there is such a risk of bad things happening, why is HTTPS not forced?

Because that can easily break the site. And then users will just abandon that browser and pick another one that does not break their sites.

I run the "HTTPS Everywhere" plugin in my browsers. And they try to do something similar. But even they have to use a massive 22k-file ruleset. (From what I understand the rules are partially generated and partially hand-tuned.)

And judging by these comments in the Amazon-Ruleset, it's not that easy to write working rules that stay working:

  <!--    Amazon has a history of breaking us soon after
        adding rulesets, so these are here to detect that.

(Test-URLs omitted)


SSL on domain will affect un-secured sub-domain I have a plan to buy a SSL certificate for my domain. I don't have much budget so I decided to buy standard SSL with no support for sub-domains. I have a WCF web-service that works on sub-domain. This WCF service is consumed by the website on the main domain. So, I want to ask that if I add a SSL certificate to main domain, will sub-domain will be effected by it? I mean it is compulsory for both to have SSL for both to work properly?

SSL and certificates don't actually know what a "domain" is.

When a client (e.g. Web browser, or an application which calls a Web service) connects to a SSL server, it will look at the server's certificate (as sent by the server itself) and will accept it only if the certificate contains the intended server name. If the client wants to talk to https://www.example.com/foo.html, then the client will require that the certificate contains www.example.com.

A "domain certificate" is a fancy name for a certificate which contains the name *.example.com, also known as wildcard certificate. The client will consider it as good enough if the intended server name is anything.example.com for any value of anything.

No part the whole thing has any awareness of the "domain" as a whole. Server foo.example.com will not mind that bar.example.com uses or does not use SSL, regardless of any certificate contents; and any client connecting to foo.example.com will be interested only in what it finds in the certificate sent back by that server; and it will be interested only in whether foo.example.com appears as a name in the certificate, as such or under the guise of a wildcard name.


Is it acceptable for security engineers to have admin access to production servers? In my organization, our server infrastructure team has historically held all admin access to production servers. We're recently trying to strengthen our security posture, so we have hired several new security engineers. We are investing significant funds in new toolsets for them, and we are also trying to identify where we need to change our policies and security models to enable them to do their jobs effectively.

Some of the security engineers believe that they should have admin access to the production servers, in order to investigate suspicious activity, as reported by their new tools.

It has been proposed by the server infrastructure team that they could grant access to individual servers on an as-needed basis for specific incidents.  The security engineers argue that such a high-friction process would potentially slow down investigations, which by their nature often take place in situations where minutes count, and where they don't really know which servers they will need access to until they're elbow-deep in the investigation, and pausing every few minutes to request access to a new server would be unnecessarily cumbersome. The server infrastructure team argues that the security engineers' tools should provide visibility into the broad majority of the data the engineers need, and they are reluctant to grant blanket admin access to the engineers.

Are there recommended best-practices for such situations?  I understand the server infrastructure team's desire to maintain principle-of-least-privilege for security's sake.  But I also understand that security engineers are somewhat implicitly trusted by the nature of their role.  In large organizations, how is security engineers' access to servers typically managed?

Good question. This is a difficult topic. The easy answer is, "it depends" and there is no perfect answer. Also, it's not possible to give a prescriptive answer whether they should have this access without considering detailed scope of the teams. But I'll attempt to provide better context.

First, work must get done and the Security Engineers have a good point if they can't accomplish their work. Make sure that the Security Engineers need access. We should break down the problem to identify whether Security Engineers need access or not. These initial steps might be obvious, but I'll list them anyhow:

What tasks do Security Engineers need to accomplish? Be specific. The answer to the question heavily depends on the scope of the Security Engineers' work!
Of these tasks, what gaps exist in their current access?
Is there any means of giving them access to the needed information / controls without providing them direct access?
Is it worth doing so? Often it may be too much work or too expensive (i.e. not worth it) to try and implement a solution for them to have the information and controls needed. And in this case direct access is the best/cheapest solution.

If the Security Engineers require access (most of the time they do), then you need to employ defense in depth to try and be as safe as possible. In other words, the company needs to attempt to take steps to prevent an incident and have a proper response capability. By doing so the risk can be reduced to a manageable level.

Some considerations:

Incident Prevention

Least Privilege: Give the fewest number of Security Engineers access as possible. More accounts with access increase the attack surface. For each account you need to worry about:

the account being compromised, and
the employee causing either intentional or unintentional damage.

Strong Authentication (multifactor): Enforce strong authentication to prevent the account being compromised and help enforce non-repudiation.
Limit accessibility: If possible, reduce the ability to reach the system of the network by requiring access to the intranet, VPN, or from a jump box.

Incident Response - if an incident occurs these will help you deal with the situation

Non-repudiation - Administrator access to systems must be well documented and audited in a means that prevents, as much as possible, an Administrator from denying he/she executed the actions.
Separation of duties - For example, Security Engineers shouldn't have the ability to modify logs. This helps with non-repudiation. Also, make sure a Security Engineer can't do irreparable damage by not giving them access to backups of configurations/software/data.

There are many more, but personally I feel as that if the above are well established then the Infrastructure Team would feel more comfortable with giving the Security Engineers access.

In summary: Give the teams the access they need to do their job. Don't limit their access to necessary resources. Yes, this means you're increasing your attack surface, but you can use defense in depth to minimize risk.