Does excluding Tor nodes by country improve privacy?

In my opinion, this is an opinion-based question. Why? Because it does make sense to filter rouge exit nodes, but how do you know which ones are and which ones aren't? Where do you draw the line in your approach?

Excluding exit nodes by country means that you'll eventually want to exclude all U.S. nodes (especially after all of latest NSA news). Then you'd want to exclude other NSA-friendly countries like Australia and New Zealand. After that, it only makes sense to exclude other U.S. allies, like the UK, Saudi Arabia, Jordan, Israel, and NATO countries. That will shave off more than 90% of the exit nodes in the world. You'll end up with a handful of exit nodes, now guess what will happen then?

Yes, you've probably guessed right. Excluding nodes based on country to avoid surveillance will lead to fewer and fewer frequently used nodes, and thus easier surveillance.


When I tried downloading from https://www.mozilla.org/en-US/firefox/fx/ I was pointed to http://mirrors.coreix.net once, then http://mozilla.mirror.nexicom.net/, then http://mozilla.c3sl.ufpr.br.  Whether this is the way Firefox's download page is supposed to work or not, I do not know myself.

A more appropriate way to resolve this though, would be to ask:  "Where can I find official hashes of the Firefox installation files?".  This has been asked and answered on Mozilla's support forums.

Start here, and pick the version of Firefox you want.  Then, look for and open a file called MD5SUMS or SHA1SUMS (depending on your preference) in that version's sub-directory.  Within that file are hashes for all OS- and language-specific versions of the installer for that edition of Firefox.  Find the name of your installer, and compare the hash to one that you run yourself (using your tool of choice) on the file that you've downloaded.

Even better, from that starting point, you can just navigate to the folder that contains the installer you need and download it straight from Mozilla instead of a mirror.  You should still verify the file hash as described above.

Still, if you're really paranoid about downloading a virus, you may want to consider this:

Does hashing a file from an unsigned website give a false sense of security?


File Integrity Monitoring via Syslog-ng or agentless - is it possible?

PCI DSS requirement 11.5 requires a change detection mechanism (ie it doesn’t have to be FIM) for modification of files, not devices.

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification
(including changes, additions, and deletions) of critical system
files, configuration files, or content files; and configure the
software to perform critical file comparisons at least weekly.

The intent is that critical files are monitored or unauthorised changes. This is one of the rare detective controls in PCI DSS.
As the comments above indicate, this requirement is generally not intended to apply to network devices where the 'operating system' of the device is generally read-only, but to general purpose computers where critical files could be modified by an attacker.
The change control (i.e. a protective control) for firewall/router configuration files is covered in requirement 1.1.1 and requirement 1.2.2 requires that such files are secured. I'd also expect that change control would cover something like a firmware update to a network device. The standard's demands for change control are detailed in requirement 6.4
Generally when someone says "PCI DSS requires X" - always ask "which PCI DSS requirement" and then check that is indeed what the standard says. It is not uncommon for people - accidentally and sometimes deliberately - to misrepresent what a requirement says and so validating what the standard says (and reading the Guidance column) can  be really helpful. The standard is freely available and can be downloaded from https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf


SSO SAML2: validating/verifying the SAMLResponse at the ACS

The SP can verify the signature with the copy of the certificate it
holds. Is that all that's needed to prevent forgery of a SAMLResponse
hitting the ACS?

No. Replay prevention is a big part of this (more on that in a minute). In addition, determining what is signed (the assertion? the entire response?) has bearing, and then there's the decision as to whether or not any of the attributes being shared from the IdP need to be encrypted (or maybe the whole assertion does). Generally, I see administrators choosing to sign the response, and as long as the IdP isn't passing what it considers PII, then encryption won't be needed.

Or will the SP need to make further checks, perhaps with a private key
it holds?

The only time that the SP's private key comes into play is if the SP is signing AuthnRequests (which, if you are supporting SP-init, is a good thing), or if the IdP wants to send you encrypted assertions or attributes. The encryption of attributes requires it to be done with the SP's public key at the IdP, so the SP can decrypt with its private key.

Additionally, I've read replay attacks need to be protected from, but
if NotOnOrAfter exists surely that means a response is valid until
then so why would we protected from replays if the whole idea is that
a response should stay working up to some specified date?

This probably is more of a thought experiment. What is the mechanism being used to transport the SAML response? The browser, right? How secure is that? If the browser is compromised (or otherwise MITM'd), and an attacker can get the SAML response, then without the Replay Prevention the attacker can provide the response to your SP and authenticate as the legitimate user. The length of time  that Replay Prevention must be in place is the length of the session granted by the response (the period between NotBefore and NotOnOrAfter). It should be noted that some service providers (don't become one of these) drive the user's session time based on those two times. That's silly. These values should be used to manage the validity period of the assertion and set to as short a length as technically possible (thirty seconds should be enough). Speaking of short time frames, make sure your SP server time is correct - I can't tell you how many times I've found where neither the SP or IdP had their servers properly synching time to a central service. That makes putting time constraints on assertions really difficult if servers don't actually know what time it is.

Finally, I've read that I must consider recording a AuthnRequest ID so
that I can verify the IDP got it. The IDP can supply it in
InResponseTo of the SAMLResponse. Is this actually good?

There's good reason for doing SP-init - it prevents the possibility of data leakage of the resource the user is trying to get to. Consider the following... User shows up to a resource and they aren't authenticated. The resource says "hey pal, go get authenticated, and redirects them to the SP. The SP captures the referrer (which is the resource the user is trying to get to) and stores it temporarily, associating it with some immutable ID. The SP then sends the user to the IdP with an AuthnRequest that has that immutable ID. When the IdP sends the user back with that ID in the InResponseTo, then a couple of cool things can happen - the SP can validate that the Response came from the proper IdP (very important if you are a service provider for multiple IdPs), and it can properly redirect the user to the resource that they wanted. In addition, since the it's an Opaque ID, the IdP doesn't have information about what the user was trying to access (which could somehow equate to PII, or have other privacy and security implications).


The scan does not open the port, it tests if the port is open or not.

This is useful for enumeration, it can not only help enumerate that the target host may be a BSD derived system, but that the port that is being targeted is open, which you can tell by the absence of a reply.

For example.

If you send FIN/ACK to a port then the port should reply with a RST as the FIN/ACK is out of state or the port is closed, but if you do not get such a reply then it may indicate that the target host is a BSD system and the port is open, as it has been observed that many BSD derived system simply drop the segment if received on an open port.


What is the disadvantages of storing user role including admin in a session variable?

Let's say a non-admin user edits their session cookie and changes admin=false to admin=true.  Is that a problem, that any user can trivially bypass all your access controls?

You should give each user a session token like 3f235219b2cca1842b4ae2dd9ec4a1a8570f2edf that is stored in your database with a lifetime.  You check that the token exists by constant time comparing the whole string and if the user with a token exists and is not expired, then you check if the user has privilege or not.

You also probably want to have it be an HTTP only (not editable by javascript) and Secure cookie (only set via https to prevent MITM).

EDIT: http is a stateless protocol.  Meaning that each http request coming to your server starts over from scratch; the web server isn't aware if you've accessed this page for the first time or are continuing a multi-page visit to the site.  The basic way to create a session is to have some identifying variable get passed back to the webserver with each request; say through a hidden GET/POST variable, a changed URL, or more typically a cookie.  A cookie could be set in an HTTP response from a webserver like:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_role=guest
...

and then when you make your next request to the webserver:

GET /index.html HTTP/1.1
Host: www.example.org
Cookie: user_role=guest
...

Note that since the user has full control of their web browser, you can't really trust the variables they are sending back.  E.g., they could change user_role=admin.  So the solution is to store the information about the user on the server-side.  So a user authenticates with the server, then you give them a token (some long random string fSFrKtJXAnjo9wacE3XNMy) and store on the server-side that token=fSFrKtJXAnjo9wacE3XNMy is tied to someone with user=guest (and anything else you need to know about their session state).  You want http-only cookies, so its harder for XSS-style attacks to steal your session cookies, and secure so eavesdroppers can't trivially listen in.


Security consequences of a publicly accessible database?

The bells ringing in your head are correct and I would be right there with you. This is a bad practice and I am afraid I have seen it done many times.

Here are some vulnerabilities and threats that come to mind with exposing a database to a third party and the public:

Authentication via username/password is weak and subject to brute force attacks and password spraying. It will be tough to implement MFA.
Some database support TLS/SSL, some don't. Better make sure end-to-end encryption is enabled.
Depending on if you store PHI, you are most definitely not compliant with HIPPA.
Lacking a clipping level, or the ability to lock someone out after they have failed to authenticate a number of times.
Database software can be very complex, you better keep up to date on all patches. If you are late or miss one, good luck.
I hope you trust this third party 1000%, any compromise and your database is gone.
DOS attacks are low hanging fruit
Any attacker that scans your externally facing network and finds a open port that is known for running databases will likely know you are a easy target in other areas
Management. Are you going to make a username and password for each user?
It is very difficult if you have 30 users to make sure they have the correct database and table views and access. Least privilege is very hard here.

Think about possibly the correct way of doing this (there are other ways):

Exposing a API to the public. The API connects, preferably through a WAF, back to the database. The API can grant tokens that have particular rights (database views) and access time. These are easily revoked and your database is much more secure, if you do it right*. The API can be easily secured with TLS, whitelisting, MFA and other controls such as locking someone out after a number of failed attempts


How can I ensure safety when literal passwords are required

The best way to store passwords in a retrievable way would probably be to encrypt them with a symmetric cipher.  Have the passwords stored on the device that intends to use them only in their encrypted form and then perhaps on startup of the service have the key to be used to decrypt the API passwords be derived through external methods (You yourself entering a password, retrieving it from an external computer not connected to the network, etc).

Once the key to decrypt your API passwords has been loaded into memory only and not placed on the disk, you may use it to decrypt the API passwords as needed.  Make sure to keep plaintext passwords in memory as well and overwrite them after they are used.


How to prevent sharing my Internet by Bluetooth tethering?

Basically, anyone allowed to connect to your router/wifi access point can in turn make their computer (or whatever device) into a router of their own.  They can then, without your router even knowing, create their own little network and share internet amongst themselves, then relaying the traffic through one device.

You can generally see what devices are connected directly to your router from its administration page, but this will not show ones that are connected via bluetooth tethering or some other means, thus relaying through a device that does show up in the list.

Unfortunately, there's no easy way on a home router to prevent this type of thing.  I think the best approach might be to talk to him and ask him if he's doing that, and negotiate a solution.


Its correct that usually in accessing ssl encrypted website you don't need encrypt cookies normally , But its about even if someone somehow hijacked your ssl connection , the TGT should be unusable to that person.

As in the SSO scenarios things changes a lot .

Authentication Process / Request Flow

During Authentication process after your identity is verifies at KDC ( key distribution center ), Authentication Server sends two messages you.

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address
    lifetime of the TGT
    TGS Session Key,
    and is encrypted with the TGS Secret Key .

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGS Session Key is the shared key that will be used between you and the TGS.
 in next step

Your Client Secret Key is determined by prompting you for your password, appending a salt and hashing the whole thing. you can use it for decrypting the second message in order to obtain the TGS Session Key.
You can not, however, decrypt the TGT since you do not know the TGS Secret Key. The encrypted TGT is stored within your credential cache.

Now you have the TGS session key, you can request the final token to access the required service from TGS

The TGT ( encrypted with TGS secret key ) and for Example HTTP service request ( encrypted with TGS session key ) is send to the TGS

TGS now decrypts the TGT and fetches TGS session key , with this key it decrypts http authenctication request

The Ticket Granting Server then randomly generates the HTTP Service Session Key, and prepares the HTTP Service ticket for you that contains:

your name/ID,
HTTP Service name/ID,
your network address
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

Then the TGS sends you two messages. One is the encrypted HTTP Service Ticket; the other contains:

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

upto receiving the message client decrypts the second message and get http session key

Now User have access To HTTP service

What if TGT was not encrypted

If TGT was not encrypted anyone having that can alter the HTTP service request to either by forging anyone's identity in the request and get HTTP service session key

Even a user can exploit the authentication process anyhow jst by altering the TGT

so to avoid misuse of TGT encryption is done


Can an RSA signature be changed given the public key?

A malicious forum administrator cannot forge the signed text in such a way that it will look like it comes from your key pair.

However, a malicious forum administrator can replace both your public key and signed text, with his own public key and signed text, and display it to the person(s) you're communicating with, while still showing you your own public key and signed text so you don't notice the replacement.

Forum post is not a good way to distribute trust, especially if your life depends on it.


Socket closed depending on data. Am I facing an active firewall? (DPI - Deep Packet Inspection)

Shot in the dark, but maybe this is a firewall or other middlebox that can't handle ClientHello with length field >= 256 (and thus using both bytes of the encoding).

When OpenSSL 1.0.1 first implemented TLS1.2 (and 1.1) in 2012, resulting in ClientHello containing more ciphersuites and additional extensions and thus by default exceeding 256 for the first time, there was a slew of reports of breakage on servers that had not been coded correctly to handle this; I don't recall any similar problems with firewalls but it isn't impossible.

To test, try s_client with -no_tls1_2 (or more simply with -tls1 or -tls1_1 as you choose) to see what happens. You can add -debug to s_client to see exactly what is sent and received, and in particular the two bytes starting at offset 3 in each record are the (big-endian) length of the content of that record: in your example this is 011c and the 5 bytes record header plus 0x011c bytes of content matches your total 0x0121 bytes.


WebRTC P2P SSL - Where are the keys generated?

You are right encryption is mandatory for all WebRTC communications. All the communications are encrypted using Datagram Transport layer Security (DTLS), which is a derivative of SSL.

DTLS is build in to all browsers that support WebRTC. In short the the keys for the peer-to-peer SSL connection  are generated by the peers and exchanged over the signalling protocol.

The Peers use a self signed certificate (asymmetric-key) based on RSA to exchange the symmetric keys they will use for the communication. The peers use Diffie-Hellman to generate symmetric keys.

For more details information see the following post


How do I prevent this type of SQL injection attack?

When this string is decoded from its url-encoded form it becomes the following:

25' having 1=1--

This string, when placed as is into, for example, the following (PHP) database query function:

mysql_query("SELECT * FROM users WHERE username = '$username'");

Becomes this:

mysql_query("SELECT * FROM users WHERE username = '25' having 1=1--'");

Note here that the %27 (') breaks out of the argument in the WHERE clause and continues the executable part of the statement. The -- after 1=1 makes the rest of the statement a comment which is not executed.

The HAVING statement in SQL is supposed to be used within queries which use the GROUP BY operator, and should fail in queries which do not. My guess here is that this string is being used to check simply for the presence of an unsanitised variable which gets placed into an executed query.

To prevent this type of attack I would suggest using a good input sanitation function, or parameterised queries. The implementation of this depends on the programming environment in question.

Addition: The normal use of 1=1 in SQL injection queries is to cause all rows to be returned, voiding any other WHERE conditions. An example input could be:

a' OR 1=1 --

When inserted as the $password parameter in a query such as:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

The statement becomes:

SELECT * FROM users WHERE username = 'mark' AND password = 'a' OR 1=1 --

The resulting dataset will include all entries in the 'users' table, as 1=1 is always true.


A MitM attack may have more than one purpose, it may just be an information gathering project, or it may be an impersonation project.

For information gathering purposes just listening to traffic is good enough, and like Steffen mentioned in the comments, setting up a NIC in this mode would achieve the desired result. How to enable promiscuous mode depends on your operating system, in Windows it can be done with the netsh command and in Linux it involves the /etc/rc.local file (its better to search in internet for your specific case).

For impersonation projects the level of sophistication increases, often it involves somehow altering the CAM table in a switch (ARP spoofing). I will not talk about the specific implementation of an attack like this, but consider this scenario:

Marc wants to send an email to Jane. Tom is the attacker.
Marc tries to connect to the mail server, instead he sends his credentials to
Tom.
Tom uses those credentials to authenticate with the mail server,
impersonating Marc.
Tom also sends valid replies to every request
from Marc.

If you want to learn how to mitigate such an attack, and need to practice or put some tool or mechanism to test, I recommend trying arpspoof, its of course not the only tool available but an easy enough one to use.


Secure solution for unique PIN generation to external clients

I tend to agree with you that your business team is overemphasizing the need for the 'PINs' to be unique among customers, but you have to decide whether to continue fighting that fight or start working to satisfy their requirement.

I see a couple ways you can accomplish this.  The first is to create a separate repository of assigned PINs that you can consult during the new PIN generation process.  The quickest approach would be to keep this data encrypted and decrypt it only to run a search or add a new entry.  This offers some protection of the data while being very efficient.

However, if an attacker manages to gain access to the decryption key they also can decrypt this data, which is why many people in our industry frown upon encrypting secret authenticators rather than hashing them.  You can combat this risk by using hardware to store the key and manage the encryption, but that adds expense to your solution.

Alternatively you can just store the PINs in your primary authentication database however you normally would.  They'd (hopefully) be individually salted with unique salts and put through appropriate hashing iterations (using something like PBKDF2, bcrypt, argon2, etc.).  When a new PIN is generated your system would need to retrieve each hashed record, extract the salt, and use it alongside the new PIN to repeat your normal hashing process.  Then the results would be compared, and if they match you need to generate a new PIN because you know there's a conflict.

The downside to this approach is that the time and computation cost needed to complete this comparison process.  In most cases you'll be retrieving every record and repeating the hashing process that many times.  Depending on the speed of your hashing process and the number of existing records it may take anywhere from 5-20 seconds.  That's probably not an intolerable delay in a non-user facing process that only occurs occasionally, but you'll have to consider that cost given your specific environment.  This is inefficient but better preserves the security of the PINs.


What encryption prevents the tampering of Windows Identity Foundation (WIF) FedAuth cookies?

Based on the first answer of this link :

  This cookie is encrypted and signed with the DPAPI key that is associated with the IIS application pool.

For your information :

  DPAPI provides an essential data protection capability that ensures
  the confidentiality of protected data while allowing recovery of the
  underlying data in the event of lost or changed passwords. The
  password-based protection provided by DPAPI is excellent for a number
  of reasons.

  It uses proven cryptographic routines, such as the strong Triple-DES algorithm in CBC mode, the strong SHA-1 algorithm, and the PBKDF2 password-based key derivation routine.
  It uses proven cryptographic constructs to protect data. All critical data is cryptographically integrity protected, and secret data is wrapped by using standard methods.
  It uses large secret sizes to greatly reduce the possibility of brute-force attacks to compromise the secrets.
  It uses PBKDF2 with 4000 iterations to increase the work factor of an adversary trying to compromise the password.
  It sanity  checks MasterKey expiration dates.
  It protects all required network communication with Domain Controllers by using mutually authenticated and privacy protected RPC channels.
  It minimizes the risk of exposing any secrets, by never writing them to disk and minimizing their exposure in swappable RAM.
  It requires Administrator privileges to make any modifications to the DPAPI parameters in the registry.
  It uses Windows File Protection to help protect all critical DLLs from online changes even by processes with Administrator privileges.

Now, for the order between Authentication and Encryption, regarding this documentation, WIF seems to first Encrypt, then Authenticate.


Is the aggregate severity rating of "Important" for MS13-027 too low?

I'd say that as @AJHenderson says their rating of Important is down to the requirement for physical access.

That said as with any vulnerability the actual risk to an environment needs to be assessed based on the likely threats to systems and their accessibility.  In some companies the risk of this attack will be quite low (e.g. datacentre environments where physical access to systems is extremely limited), whereas in others it will be high where access is easy (e.g. any kiosk style environments that allow USB access) or where likely threat actors can get physical access to systems (e.g. financial organisations who may allow contract staff like cleaners physical access to systems (think sumitomo bank))

Ultimately I'd say that the Microsoft rating should just be seen as a starting point for a companies risk assessment and they need to take account of their own environment before deciding on how severely to treat a given issue.


Format for data & symmetric key exchange/storage

One of standards is WSSEncryption. A message can be encrypted with symmetric algorithm e.g. AES-128 or AES-256. The encryption key itself can be encrypted with RSA.

Many software products support it out of the box. For instance, if you prefer Java EE, you may want to use WildFly or WebSphere Application Server. If you prefer C#, use WCF.

The web service standards WSSEncryption, WS-Security and SOAP in general are widely used and provide very good interoperability. Every party can use any platform it prefers. E.g. one party can use WildFly, the other WCF, and client on one one platform can consume web service implemented on another platform and vice versa.


Bruteforce part of password in TrueCrypt

This is a good starting point to learn how the Mask Attack from oclHashcat works: https://hashcat.net/wiki/doku.php?id=mask_attack

You need to add the commandline-parameter -a 3 so hashcat knows your going to use a mask  attack.

Hashcat comes with some predefined mask's (you can define your own also):

?l = abcdefghijklmnopqrstuvwxyz
?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d = 0123456789
?s = «space»!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
?a = ?l?u?d?s
?b = 0x00 - 0xff

Example:

Lets take this as the password you are looking for: PASSWDfA89

You remember the PASSWD part but you didnt remember the other part: fA89

We see that the fA89 part has lowercase and uppercase letters and numbers,
then we need this mask: ?l?u?d, but hashcat doesnt have it predefined so we need to use a custom mask.

For this, we need to add another commandline-parameter: -1 [CUSTOM MASK HERE]

The custom mask permits us to create our own charsets (up to 4) but we only need one.

The custom charset should look like this: -1 ?l?u?d

At the end, our command should be something like:

./oclHashcat-plus64.bin -m 6211 test.tc -a 3 -1 ?l?u?d PASSWD?1?1?1?1 -n 32 -u 2000

This is the important part: -a 3 -1 ?l?u?d PASSWD?1?1?1?1


Is it possible to spoof the user agent of any application?

If you're trying to spoof the user agent on applications sending HTTP traffic but don't support natively changing their reported user agent you could setup an interception proxy that rewrites HTTP requests.

That's a lot of work though to setup and configure (I assume you'll also want to intercept TLS traffic), and altering requests may actually break functionality if the server responds in an unexpected manner.

The trade-off doesn't seem worth it in my estimation. There's many other ways a browser/http request could be fingerprinted other than purely the user agent.


What's stopping attackers from using our API keys to spam our logging services?

The answer is no. If you are giving the API key out publicly and the API key is the only secret required to log, then an attacker can easily obtain the API key and create log events.

You may be able to throttle based on IP address or use other attack detection to prevent abuse, but it depends on the control you have over the logging service and what it supports.

If you were to serve a unique API key to each client, you could then set up logic per-key saying things like: "This key may only be used for 100 log events before it expires and it is throttled to X events/sec." Of course, an attacker can still start requesting many new keys, so you'd have to detect if this is happening and try to limit by source IP again. Similar problem to before.


Why enable SMTP STARTTLS if OpenSSL is dangerous?

I think you're overestimating the risk of enabling STARTTLS. Sure, there have been some incidents with OpenSSL recently, but does it mean we should all stop using HTTPS?

In your situation, here is the trade-off:

Using STARTTLS may open up security holes on your machines
Not using STARTTLS will allow anyone snooping (on the network, on underwater cables...) to read the e-mails effortlessly. (Contrary to what you imply, this is not a risk - it's happening, as Snowden's documents have proven.)

Basically, you have to choose between mitigating possible future security issues and defending against current attacks.

Unless you are are a high-profile target and fear that 0days may be used against you, I'd advise you to go with STARTTLS. Alternately, if you really don't trust OpenSSL, you can probably look into GnuTLS (although it had its share of problems too) or wait for OpenBSD's LibReSSL.

UPDATE : A portable version of LibReSSL has just been released by OpenBSD... It still lacks testing, but this means you could yet get the best of both worlds, provided you trust them more than OpenSSL's developers.


How do I know which cipher suites can be disabled?

The required cipher suites depends entirely on the clients that are expected to use the service. As SSL Server Test from Qualys SSL Labs is designed for testing publicly accessible web servers, we can assume this is a web application. All current versions of major browsers are able to handle TLS 1.2+ with the recommended cipher suites from RFC 7525, 4.2, making it a good starting point for a highly secure configuration:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)

Then, from the SSL Labs report, the Handshake Simulation section is handy tool for detecting the common clients you can't serve with these cipher suites alone:

If you e.g. wish to server older Apple devices with Safari, the best cipher suite available for them is:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)  ECDH secp256r1 (eq. 3072 bits RSA)   FS  WEAK

From the list that leaves... who is using a Windows 8.1 Phone anyway. ;)

Likewise, if you need additional browsers or devices supported, you could use the browser test for figuring out a suitable cipher suite. Also notice that the variants using (Cipher Block Chaining) CBC mode aren't weak in themselves, but SSL Labs considers them weak because of the many vulnerable implementations.


Is PHP OpenSSL safer than just using MySQL AES_ENCRYPT/DECRYPT alone?

If you would do the encryption on the MySQL-server side, you would have to send the (unencrypted) data to the MySQL-server. To do this securely, you would need to ensure an encrypted connection to the MySQL-server to protect the data in-transit. Depending on your setup, the data could (partially) end up in a log file somewhere. This all adds a layer of complexity, without added security benefit.

Also read: Is “Why Should You Avoid AES In MySQL?” true?.

Encrypt on the PHP side
If you encrypt the data on the PHP side, you can make use of user-friendly packages (SymmetricEncryption or php-encryption spring to mind), and just store the encrypted string in your DB, which is a lot less complex.
Given your question about, for example, the requirement for the $iv, I strongly suggest you use a standard library!

So, in summary: Yes, using PHP OpenSSL is safer than MySQL AES_ENCODE/DECODE.


How effective is an IDS at catching targeted attacks

IDSs will probably be about as effective at detecting targeted attacks as non-targeted attacks.

I wonder if there might be some misunderstanding about what a "targeted attack" is.  The difference between a targeted attack and a non-targeted attack is in whether the attacker tries hacking everyone or hacking just you.  Targeted vs non-targeted is orthogonal from which technical method the attacker chooses to use in the attack.

Generally speaking, IDS is best used for detecting common, low-sophistication attacks.

However, a sophisticated attacker can readily evade an IDS.  Custom attacks are not likely to be detected by an IDS.  Also, an IDS is not likely to detect advanced persistent threats (APTs).  And, a network-level IDS is not likely to be very good at detecting spear phishing: e.g., targeted malicious emails, targeted attacks through social networks, and that sort of thing.  Email-based vectors probably need to be detected at your mailserver, not by something that monitors your network.  Web-based vectors are even harder for a network monitor to detect.

Generally speaking, I don't recommend relying upon an IDS as your primary line of defense.   It's OK as a secondary defense to catch some things that you might not have stopped with your primary defenses, but you shouldn't use an IDS as your only defense.  Your primary defense should use other methods (e.g., firewalls, software updating/patching, system configuration and administration, user education, good software development practices).


Find out the identity of the person that called you

Why are you assuming it is a "person" who called you?

Most people will just Google the number - typically if this is one of those spam callers you will find out some information about them on discussion groups.

I am not sure why it would be illegal to search publicly available information about a phone number that called you.


TLS: Clarification on trust in the certificate trust chain

Yes to both.

Usually you will only have the root in the trust store and the entity providing the leaf cert will also provide the necessary intermediate certs, and the verifier will build a chain linking the leaf to a trusted root ("the" trusted root if only one root is trusted).

Of course the certs need to have the correct key usage constraints etc. e.g. a certificate only used to sign OCSP responses cannot issue certificates, etc.


Does the practice of blocking an off-site "Referer:" HTTP requests improve website security?

Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it.  The usability costs are significant and outweigh any security benefits.

I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to identify defenses that people should not implement.  This is one, in my personal opinion.

Background. Based on the original question, it sounds like it might be helpful to provide a review of the relevant background and articulate more precisely the specific defenses that you are likely considering.

You seem to be considering examining the Referer: header in incoming requests.  Most modern browsers set the Referer: header on most requests to list the URL of the previous page that triggered this request or that contained this link.  Some requests do not carry a Referer: header; one example is the prior page is over HTTPS, then browsers will not set the Referer: header.

It is important to know that the Referer: header was not designed for security, and cannot be trusted.  There are many attacks to cause a browser to omit the Referer: header.  There are also attacks that can be used against some browsers to forge the Referer: header (to cause the browser to send a request with a spoofed Referer: header of the attacker's choice).  Therefore, most security folks recommend that it is not a good idea to rely upon the Referer: header as your main line of security.

It is also important to know that the Referer: header is not guaranteed to be included, and sometimes it is blocked.  The Referer: header has privacy implications: it can be used to track people on the web.  Some people feel that it is a violation of their privacy for their browser to routinely tell site B that they were just at some specific page on site A.  Therefore, some people configure their browsers to block transmission of the Referer: header.  Also, some corporate firewalls and proxies strip out the Referer: header, to avoid leaking confidential or proprietary information to external web sites.

The original RFC (RFC 2068) states that the Referer: header is not mandatory, and explicitly recommends that browsers should provide a way for users to disable transmission of Referer: headers.

For all of those reasons, some fraction of legitimate requests just don't include a Referer: header.

Now, I suspect you are proposing one of two possible defenses:

Strict Referer checking. You designate a specified landing page on your site.  If your site receives a request with a Referer: header that refers to any URL not on your site, or receives a request with no Referer: header, then the server immediately responds with a redirect to your landing page.
Loose Referer checking. Same as the above, except that requests with no Referer: header are permitted (they don't trigger the redirect).

Loose Referer checking makes no sense, from a security perspective: there are too many ways that an attacker can trigger a victim's browser to make a request and suppress the Referer:.  So I will presume that you are considering whether to implement strict Referer checking.

Security benefits. So, does strict Referer checking have potential security benefits?  Yes.  They include:

CSRF defense. Strict referer checking makes it harder to mount cross-site request forgery attacks, because other sites cannot direct the user anywhere other than the landing page.
XSS defense. Strict referer checking can make reflective XSS attacks harder, because other sites can't trick the victim's browser into visiting the vulnerable URL.
Clickjacking and framing. I don't know whether strict referer checking helps against clickjacking or being framed.  I'll have to leave that to others.

There are some caveats, though.  For each of these risks, there are better defenses known.  For instance, for CSRF defense, use anti-CSRF tokens.  For XSS defense, don't introduce XSS bugs into your software; use template systems with context-sensitive automatic escaping; etc.  For clickjacking and framing, use time-tested frame-busting techniques.

Usability costs. There are some major usability costs to enabling strict referer checking throughout your site.  These include:

It prevents deep linking. It prevents people from linking to pages on your web site.  This means you won't get traffic that others send you, because they link to something great on your site.
It prevents deep bookmarking. It prevents your users from bookmarking anything other than the landing page.  That's just annoying, from a user's standpoint.
It blocks some users. Some users won't be able to use your site, either because they use privacy mechanisms that block Referer: headers, or because they're behind a corporate firewall that strips Referer: headers, or the like.  This reduces your potential user base.  Also, some of the folks who block Referer: headers are the most tech-savvy users, who are potentially your early adopters who might evangelize your site to others; you don't want to unnecessarily block them from using your site.

Overall. So, when I look at this, I see some dubious security benefits, and major usability costs.  Moreover, all of those security benefits can be obtained in other ways that don't damage usability, simply by using standard security mechanisms.  Therefore, I don't recommend that you adopt strict referer checking.


You're using PHP? There are a couple of things to keep in mind. I wrote this article earlier this year which covers file uploads and other topics. Creative Commons so feel free to save a copy, modify, and share as you'd like:
https://keenot.es/read/thwarting-basic-web-application-attacks

"Encrypt your files, store them in a random filename in a specific non-webroot directory, and use a database to keep track of their metadata (type, filename, size). Use a script to deliver them from the filesystem, and use header() calls and rewrite directives to trick browsers into treating them like images. Cache heavily to prevent resource exhaustion."

You don't necessarily need to encrypt them; gzip compressing them or base64 encoding them will prevent execution in case they manage to directly access the file. I do recommend abstracting the filename that people see away from what is actually present on the filesystem. While this might be objected by people as a form of "security through obscurity", but if you store everything as a .txt file, nothing will ever execute through accessing an uploaded file.

One very important thing: Don't rely on the file extension or the user-provided $_FILES['abc']['type'] value. They can be spoofed.


How do websites tracker cookies and beacon work?

A Cookie allows a website to place a small file on your computer, which is usually used as an "identifier" that then can then go do a query against in their database and go "ah, this is customer X who was browsing Y earlier today" - normally (outside of security exceptions which are patched), a site can only read it's own cookies, however, many rely on a 3rd-party cookie, such as google (adwords), to handle some of the work, allowing them to focus on their own things, instead of creating their own website completely, so they may have a small piece of code that says "go to google and insert a small portion of the website into this corner as an ad" - that code does so, and leaves behind a cookie, so that then google can check for the presence of this cookie on the page that the ad led to (and thus count if you clicked on it or not) - now many websites could use the google ad service (or any other large ad service), and google can "recycle" the cookies, and use them to track you from site to site

up till now everything has occurred on a single PC - now you go to another computer, and the same process goes on, and thus google has two cookies with information about sites visited from two computers - if the browsing habits are similar enough (such as you look at profile XYZ) on both computers, google can associate that "people who look at profile xyz are likely to shop for qwerty" - and begin to show you ads for qwerty, even if you never logged in - probably the best example of this is music services that "suggest" music based on what others who listen to similar music like, even if you have never heard of the band before, and with a relatively good accuracy - not perfect, but then there isn't too much harm in them guessing wrong either (usually - exceptions will always exist), and their profits are better when they do guess, so they try their best to do so.

edit: I am not sure about Ghostery, however most browsing would be severely restricted if cookies were completely disabled, and your still using Chrome - I imagine Google wouldn't allow it in their store if it did it's job too well..


In DKIM the senders MTA signs the message and some headers using a private key only known to this MTA. The signature was explicitly designed to survive redistribution of the unmodified mail.  This kind of redistribution is what you are doing with telnet.

In other words: the DKIM signature is specific to the mail itself and not specific to the process of sending the mail. This is different from SPF which cares about the actual process of delivery only by checking the senders IP address against the claimed sender in the SMTP envelope but does not care about the actual content of the mail.


Lastpass: Can we use more rounds of SHA-256 for decryption than user authentication?

I wonder if we can make the opposite. In particular, use 5001 rounds for decryption, but use 5000 rounds for authentication.

No you can't. Since LastPass uses the same salt for both authentication and key derivation, allowing this would be completely insecure.
To authenticate a user, LastPass has to store the authentication hash in its database. Now if the decryption key used more rounds than the password, then an attacker that obtained LastPass's user database could take the hash, perform another round of SHA-256 on it and they would have the decryption key. This would also mean that LastPass itself could decrypt any user's password database any time they wanted (which would violate LastPass's claims that the users' password databases are kept secret even from themselves.)


Is OpenVPN secure if both the certificate and private key, are publicly known?

I've just been talking with the IPredator guys on IRC and it's quite interesting. I've made some incorrect assumptions.

As part of the installation process you add their CA. That's fair enough. So the whole connection happens through RSA (or similar) public-key encryption.

The key-pair is just an additional TLS encryption layer for authentication. They freely admit it offers no additional security for users but it does mean that anybody trying to connect needs that pair of keys. Requiring them has meant a sharp drop in connection-style DDoSes.

So it is still secure. The key-pair is just some additional security-through-obscurity.


How many bits of security does a hash as a verifier provide?

The security of this approach is 2^256, or the entropy of the input, whichever is smaller.  The preimage security of SHA-256 is 2^256 (note that the attack you linked to is on a reduced-round version, so it's not applicable to the full SHA-256).  However, if your input s contains less than 256 bits of entropy, then it would be easier to search the input domain, and your scheme would have as much security as the entropy in s.  That could be the case if you used a 128-bit s, for example.
If s is a 512-bit string and 256 bits are known, then the security is still 2^256, since it has 256 unknown bits.


If an attacker can control the access-control-allow-origin header then they can carry out much worse attacks than just modify this header element.  For example an attacker could carry out a Man in the Middle attack,  but authentication tokens,  like cookies are a more desirable target.

An attacker could introduce their own access-control-allow-orign header using HTTP Response Splitting, but at this point they can control the entire header and the body. An "allow-orign" doesn't help with the entire Same-Origin Policy is undermined by an XSS vulnerability.


Is there a way to estimate the difference of temperature or voltage of PC CPU per differet code command?

Woohoo, with temperature it's a no go.

With voltage/power consumption you can roughly guess how much transistors are in use, and with knowledge of the inner processor diagram and command coding (ASM "version") you may guess wich command (set of transistor) is in use, but it sounds really error prone (see end of answer).

Deriving the same information from temperature is a no go because the temperature will vary from a ridiculous small amount and there's some inertia between warming and cooling, so a set of command could be done without noticing a 0.00000001° (Choose your temperature unit here) difference (assuming you could mesure at this precision).

For what it worth, for and if are nothing in a computer, those instruction would be translated (by compilation or interpretation) to assembly instructions, an if command will be made of a bunch of ASM commands, at least a CMP and JMP one (excluding the test itself which need loading values in registers etc.).

For the cracking technique, the algorithm is usually known, the variables are not, so you can 'guess' some variables (number of iterations, complexity of encryption) from the power needed by the card, it is more a rainbow table comparison from cards with the same components used with known algorithm and variables when measured AFAIK.


What guidelines can I follow to know if I can trust a software editor?

It's really interesting because in this situation we are dealing with 'trust'.

How can you trust a software editor ?

Because it's famous would be a good answer but still it's not enough.

Look at  Sony rootkit scandal

At the moment, I haven't find any website recording editors 'trust factor'.
So the best way is to gather information about the different software he has developed. Rummage on different forums to see people's opinion about him or his software. Maybe the editor talks with the community about the software and how to improve it (Being open makes him 'more trustworthy').

In the end, you have to get an idea on him but you'll never be sure about it (like in real life).


The MD5 hash algorithm has been demonstrated to be weak to collision attacks. This means that an attacker can generate two files which will produce the same hash value. This has no bearing on file integrity checks.

To create a file that matches a previously known hash, the algorithm has to be weak against second preimage attacks. While MD5 has some theoretical weaknesses in this aspect, the current attacks are still not computationally feasible.

Of course, new attacks might surface in the future. MD5 has been demonstrated to have several glaring weaknesses. Try to use a hash function like SHA256 instead.


Is there any checklist for website security?

There is the OWASP checklist here: OWASP Testing Checklist

Recently some people have collaborated on a checklist for developers: A practical security guide for web developers

I found the second one to be more useful myself, although the OWASP list has been around for much longer.


Can the source of an SMS message be spoofed?

To echo James' response. It is entirely possible for someone to send you something for a number that doesn't belong to them. This will usually be criminals trying to get you to click a link and steal credentials. Whether this is likely will be dependant on the nature of the message received. If the message is generic and contains a link then sure it's a possibility.

If on the other hand the message is of a personal nature then the above is highly unlikely. It is far more likely to be a message that the originator is attempting to lie about sending. It takes 2 seconds to delete a single text message from a comment chain on a phone and requires zero skill. Without further information on the content of the message this is by far the most likely scenario.

There is a third possibility that someone in the friendship group sent the malicious message but I wouldn't even beginning digging down that path unless there is an specific individual with a grudge that has advanced technical skills.

Finally, the screenshot itself could be faked. There are plenty of web-services that allow you to produce fake text message chains.


Are jQuery vulnerabilities exposed by the file being served from the server of by usage of the vulnerable code?

When updating a library, you should indeed remove the (possibly problematic) code from the server. This is also true if the web application is not using the vulnerable parts of the library.

There is a good reason for that:

Served from that web server, the problematic code can possibly be leveraged in an attack that otherwise would be mitigated by CSP.

If a vulnerability in the web application does allow for (for example) XSS, the old versions vulnerabilities could be leveraged by an attacker regardless of the parts of the library the  web application (usually) uses, possibly allowing for more controlled execution.

As you can see, it would need another vulnerability to actually exploit the vulnerable code, but following the argument of that not being a problem would render CSP in its entirety useless; removing that file will keep the CSP usefull.

Additionally, it would be hard to identify whether any parts of the code still rely on the old library when it's still available, so it would be good practice to remove libraries that are no longer necessary.


CVE-2017-8295 describes an issue in WordPress where the password reset mail is sent with the current host name as the sender. If an attacker requests the password reset mail with a forged host header, the password reset email is sent with the given domain as sender. If the email bounces, or the recipient replies, the reply is sent to the attacker. This reply contains the password reset token, thus making it possible to take over the account of the victim.


Are .zip files used as a modern attack vector?

I still get a lot of email virus that use Zip archives as payload. Initially, virus authors would use Zip archives to evade detection by antivirus software that merely looks for executable files. Antivirus authors adapted and began to recognize the Zip archives and scan their contents.

Some virus authors tried some things such as nesting Zip archives in Zip archives, counting on the human user to keep on clicking while the antivirus would not be as thorough. Some have began to use Zip bombs. As usual, malware and antimalware developers are engaged in a neverending hide-and-seek game.

The real killer is when virus authors began to send encrypted Zip archives, with the decryption password being written as simple text (or a picture, or some other mechanism) in the accompanying email. This relies on the human user trying to open the Zip, then dutifully typing the password that was provided in the email "for security reasons". Some people really do that ! This effectively prevents antivirus software from scanning the Zip contents, so some antivirus simply declare all Zip files to be terminally evil and shoot them on sight.


Is it a good practice to proxy web-applications from Docker containers?

Are there any drawbacks to this model?

I don't see any immediate drawbacks, except for the overheads and the use of disk space if you deploy your applications on a rolling basis without keeping volumes in check. Keep in mind that "A Docker data volume persists after a container is deleted. " see the Docker documentation.

However, there might be a few longer-term drawbacks. For example: since you run this in production, how often do you apply security updates to your containers? Given that docker images are a step removed from upstream, security patches might not be deployed fast enough. How often do you check for updates to your containers, and redeploy them?

Also, if one of your containers gets 0wned, do you filter outbound connections? What if a trivial exploit in your app makes it part of a botnet?

  How would it be more secure?

It depends. Do you mount the host's /proc or /sys in any container? If so, beware of this kind of attacks (and search for 'docker escape' for an entertaining read)

  How exposed are the application-containers to attacks?

For attacks coming from outside your network perimeter, they are as exposed as if the applications were running as regular UNIX processes on a system.

Oddily, for attacks coming from other containers you are actually increasing your attack surfaces: assuming some containers can see others (e.g. web server can see the db server, or a log server, and so on) you have to make sure each container does not run extra services and most importantly keep them up to date.

  Are there any security considerations regarding Docker?

Yes but the question is too broad. There are docker escapes due to poor container management (e.g. mounting /proc). There are potential docker exploits. There is the occasional misconfiguration that allows local users to attack it. If you're looking for a silver bullet to deploy and forget, you'll be disappointed...


Getting the column names of a table by brute force blind SQL injection

There are several ways of getting the column names in mysql, and the kind of attacks that are feasible will depend on the application being attacked.

For a generic answer, I would recommend studying the way SQLmap is able to discover the column, table or database names.


Is there any open source SDK for implementing a KMIP server?

Came across this old question. If you are still looking for answers, found the following

https://pykmip.readthedocs.io/en/latest/index.html : This one seems to be actively developed.
https://www.ibm.com/developerworks/library/se-kmip4j/index.html : Didn't see much activity here.


Why is firefox attempting to direct me to a Captive Portal, when I'm connected to my own router?

The captive portal detection works by requesting http://detectportal.firefox.com/success.txt (or something similar) and seeing if the expected contents are returned. Possibly something on your router, or computer is altering the page, so Firefox is assuming that there is a captive portal in the way?


The short answer is NO (nothing hides all tracks)!
Here is the longer answer:
There are some researches on Tor on how to break the anonimity (track users); anonimity is the main goal of Tor.
To simplify it, let's take a look at the architecture of Tor. It has an entry point by connecting to a node in the Tor network, it will be passed to at least 3 different nodes in the Tor network before it gets out from the exit node.

Now, if someone monitors all or some entry and exit nodes, it doesn't matter how the data was gone through which called "Traffic-analysis attack". It is possible to find who requested what kind of the accesses. There are more kinds of the attacks; here you can find a short review on other attacks where I got the photo from.
So, to answer your question it is better to say "it depends". What do you mean by "hiding tracks"? from "who"? If you do not want stop hackers not to see you, that would be a good try but if you care about huge organizations or governments, it is better to find another solution for hiding yourself and your stuff.
List of some articles about attacking Tor:

Thirteen Years of Tor Attacks
Attacking Tor: how the NSA targets users' online anonymity
Darknet Security: A Categorization of Attacksto the Tor Network
Speculative Tor Attacks
Uncovering Tor users: where anonymity ends in the Darknet
Browser-Based Attacks on Tor


As you said, when you use a string comparison function which hasn't been design to resist to timing attacks, then it could be exploited to guess the string with which you compare.

Comparing unencrypted and unhashed strings will indeed leak the original string, be it a password (either stored in a database or hard-coded), a session ID, an email address or a multi-factor authentication token - meaning this attack is not limited to the common sense of "passwords".

If the strings are encrypted and the encryption function is known to the attacker (with the associated keys), then he could guess the encrypted string, then decrypt it to get the original string.

If the strings are hashed and the hash function is known to the attacker (and the associated salt, if there's any), then guessing the hash will be harder and harder each byte (due to the avalanche effect), making it very hard to guess more than the first bytes of the hash, but that may be enough to bruteforce if your original string has not enough entropy.

This recommendation is true when you're comparing any user-supplied string (either you hash it or not) with any type of sensitive data (see above, I personally consider that any information related to one user is sensitive).


Best practice for storing auth token client side

Maybe you could implement idle timeout on the server and if you see no activity for certain amount of time (say 10 mins) mark the session expired.


Are some uncommon TCP ports scanned less than others?

The way attackers go about portscans is to first target those with known exploits or commonly weak protection.

The list at http://www.iss.net/security_center/advice/Exploits/Ports/default.htm is one typical list.

Sure, you get some scanners who go for the entire port range, but as that is far less effective, this list is going to be a pretty good indication of the most scanned ports.


Can IE be made to imitate the behavior of Chrome's KeyGen element?

The simple answer is 'No'. http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html has a Microsoft engineer basically explaining why ("The problem with  is that it fails to address the requirements that people have for certificate enrolment today").
Depending on what you want to do - you may be able to get CertEnroll to produce a reasonable analog - have a look at this MSDN blog entry which contains a pretty detailed example of using JavaScript and the X509Enrollment ActiveX object.
Of course, all of these are dated 2009, but I couldn't find any evidence Microsoft had changed their thinking.
Safari also appears to have native support (http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/HTMLTags.html#//apple_ref/doc/uid/30001262-keygen).


PCI DSS SAQ A compliance with WooCommerce and 3rd party payment gateways - possible?

Question 1: Are in this case WooCommerce, my website’s host, third
  party security, backup and other plugin providers considered as
  service providers in case I use URL redirection method or iFrame for
  payments? Meaning that they should be PCI DSS validated? Or does that
  apply only to the payment processor/gateway as others are not involved
  in collecting, storing, processing and transmitting cardholder data?

If you're using URL redirection or iFrame for payments, then you are ensuring the cardholder data flow stays outside WooCommerce and related providers.  Your last sentence is correct, the PCI validated part does not apply to them as they aren't touching the cardholder data.

  Question 2: Does it mean that if I use any of these plugins as a
  payment gateway, I cannot be SAQ A eligible?

As long as those plugins are correctly doing URL redirection or iFrame payments, you're fine.  You're just taking advantage of someone writing a plugin to integrate what you'd have to do yourself if the plugin wasn't there.

  Question 3: Can any of these 3 payment gateways be set up using URL
  redirection or iFrame method? So that all collecting, storing,
  processing and transmitting of cardholder data is done by the payment
  gateway enabling me to be SAQ A eligible? For me it seems that PayPal
  Checkout allows only API that would not be compatible with SAQ A
  requirements for my company.

"Stripe Developed by WooCommerce" boasts "PCI-DSS compliance with Stripe Elements," and Stripe Elements supports SAQ A with Hosted Fields, so look into Hosted Fields and make sure you use it.

"PayPal Powered by Braintree for WooCommerce" can "Achieve PCI DSS v3.0 SAQ-A compliance using Hosted Fields functionality for card detail collection," again note the focus on Hosted Fields.

I believe "PayPal Checkout" also supports SAQ A compliance via Hosted Fields, but can't find a succinct reference.

  Question 4: Has the payment processor/ payment gateway such as Paypal
  Checkout or PayPal powered by Braintree be PA-DSS validated? On the
  list of validated payment applications available on the website of PCI
  Council, I cannot find PayPal or Braintree. Does it mean that to be
  PCI compliant I cannot use any of these two payment gateways?

I suspect these plugins are not covered by PA-DSS, which is kind of a shaky standard that's going away.  These plugins are basically ensuring that the data PA-DSS is concerned with stays far away from your site.  But caveat lector, IANAQSA.


How does default Debian boot drive encryption works?

The /boot partition is not encrypted for exactly the reason you mention in your question. Typically, files and data should not be written to that partition for exactly this reason.


Does OAuth 2.0 provide a way to reliably regenerate a key only when a session is active?

OAuth 2.0 does not specifically provide you with what your looking for but in most all cases after getting your OAuth token (in many cases when you get your oauth token) you'll have acces to a user id of some kind. The id will be different from each provider though. For Facebook OAuth in particular, they just give you the access_token and then you need to make a request to the porfile page for the id.

https://graph.facebook.com/me?access_token=

There is an example of this seen in the docs here:

https://developers.facebook.com/docs/howtos/login/server-side-login/#step6


"Prey" & "Find my ____" have limited usefulness?

If an iPad is registered with "Find my iPhone", it can't have iOS reinstalled without entering the password for the iCloud account with which it's registered. The thief can't do a wipe and reinstall. It's certainly true that it has to connect to wifi to tell you where it is, and so you should consider setting your iPad to connect to unprotected wifi networks automatically to help its chances of doing so.


How can I keep my programmer collegues informed about security issues?

If you work with these developers on a coding assignment or some other project, you can bring up security issues while you're working together. That could either be during "pair programming" if you work that way, or as part of a code review.

Should you choose this approach, you need to come up with realistic problems based on actual threats. If you mention every paranoid possibility for attacks, then it's likely you'll just annoy people and not get your message across effectively. Even when I was working for a security vendor I found the paranoiacs frustrating.


Is email sent form a Java web-app over a HTTPS connection encrypted?

Assuming that everything is done right (everything, which is not a given especially if one does it oneself), HTTPS still would't protect your email as emails are not using that protocol to be transmitted. Because you actually need to send the actual email to other servers using the "email protocol": SMTP. But even then, this is a bad idea.

For instance, what are these "other servers" exactly? If you recipient is at gmail for instance, you have to send the email to the gmail servers, right? However this is not exactly how SMTP is working: you email will hop from mail servers to mail servers until it reaches its final destination. This connection can be direct but there are no guaranty that it will actually be, far from it. This simple fact makes end-to-end encryption within SMTP impossible by design: each realy/MTA is a MitM! Yes, there were attempts at making SMTP secure but the design is still just bad from a security standpoint. See this Wiki article for instance, especially:

  Mandatory certificate verification is not viable for Internet mail delivery. As a result, most email that is delivered over TLS uses only opportunistic encryption.

Opportunistic here means that it defaults to clear text whenever someone illegitimately wants to read, if anything in the middle is broken, if anything is not configured properly, etc. And the worst is that it's not because your connection to the first relay (called MTA, in the other answer) is actually secure (because you did a good job wasting 8h of you time in configuration and thorough checks) that the connection between that very first relay with the second will be secure. You have no guaranty of that whatsoever (and again, the relays themselves can be evil).

Solutions?

Don't send clear-text emails. Use PGP/GPG, S/MIME or equivalent to crypt your emails if you want secrecy. These provide end-to-end encryption but require a fair bit of configuration from your side and from your user side. To be done properly (and actually provide privacy), you need to manually authenticate each user. This may not be possible.
Another solution would be to use a protocol already designed to be secure which provides end-to-end encryption (some IM protocols are actually quite good for this).
As proposed in the other answer, provide an email with a link to a protected HTTPS page only accessible to authenticated users (a token in the URL won't do).

However, never ever use SMTP (with or without TLS/StartTLS) if you need a guaranty of a minimal amount of privacy. SMTP is not secure.


Is a stack trace of a server application a vulnerability?

A stack trace is an information leak, which reveals information about your implementation. Whilst not a serious vulnerability, it does allow an attacker to gain certain information about your system. It may also allow them to use a debugging-based approach to exploiting flaws in your site.

One might argue that the stack trace in itself is a vulnerability, since nobody should be able to crash your site in such a way.

Ignoring the security implications, it's not exactly confidence-inducing for your customers to see a stacktrace. They'll assume the site is broken (which it is, really) and worry about whether their transaction will work, or perhaps even think that the site has been hacked.

Further reading: Is it a vulnerability to display exception messages in an error page?


What are the security risks of the Service Bus, and how do you mitigate them?

My understanding of the service bus is that it works over specific ports in the 800 range -- I think.  If you disable outbound connections over those ports, then you can't get out to the service bus to get the messages.  Also, each service bus has it's own unique endpoint specific to the service in question so you could lock down access to only known endpoints.


Bettercap 2.x SSLStrip Is Not Breaking TLS (Without HSTS)

after a lot of searching I just found out that Bettercap 2.x apparently just does not do the HSTS bypass thing.
The sslstrip from the http.proxy module works just fine, I've tested it on my network, all the HTTPS website where now HTTP, however Chrome, Firefox and so on block them cause you visited them once with HTTPS, some website are still visitable by clicking the "Proceed (unsafe)" button, for for https://google.com and/or https://facebook.com the button just won't show up.

With Bettercap 1.x HSTS bypass was basically working because it was changing the URL in order to make the browser think that this is the first time you visit that page, and so https://www.google.com become http://wwww.google.com

And well... that HSTS feature is just missing apparently, or it's well hidden cause I've not found any answer or article using it in Bettercap 2.x.

(Sorry, I would have commented instead of posting an answer, but I did not have enough reputation. Also, sorry for any stupid grammatical English error, it's not my main language.

Any help in the comment for that is really appreciated, Bettercap 2.x it's supposed to be better than 1.x, but if it does not have HSTS bypass it's pretty much useless...)

UPDATE:

After some testings, I managed to make Bettercap use the HSTS Bypass.
By running ARP spoof, DNS spoof and the sniffer module it works fine (enabling ssl strip in the modules).
This way, I got the URL modified into http://wwww.google.com
Unluckily though, the latest Firefox blocked all the web pages, still trying to get it right.


As part of a CTF challenge that I run, we had some reverse-engineering challenges last year. I posted some advice on how to perform the analysis (verified by folks that do this on a daily basis). The blogpost is here. The links point to tutorials for IDA and OllyDbg, two of the most popular tools for such analysis and there's a nice paper from one of the AV vendors. From memory the tutorials were step by step.

There's also some rootkit analysis videos on http://www.securitytube.net/.


First off, I'm not sure I completely follow this statement:

  My concern is that with people more and more relying on their browsers remembering their credentials and having sessions that never expire, or expire after a long period of time, this means that somebody might be able to just copy your token and bypass authentication altogether...

The browser remembering credentials is entirely independent from the website sessions lasting a long time. In fact, having your browser remember your credentials is a convenience so that you don't need to click on the "remember me" option on a website, so one could argue that allowing browsers to store credentials makes you more likely to logout and make your session shorter rather than longer. That being said, I do understand where you're headed with the question, so let's assume you aren't storing credentials in the browser, and instead are clicking on the "remember me" option so you have a session that lasts for a long time (maybe months). How insecure is the "remember me" option?

The remember me option is insecure in either of the following scenarios:

You are on a shared computer where someone else has access to the
same user you use, or someone else has admin access to the computer
you use. In this case another user of the computer can look at your
authentication cookies and copy your token as you suggested.
The site is using http instead of https. In this case someone sniffing the network can capture your session token in transit.

Some things you can do to help prevent from token snatching are:

Use https.
Use a short-lived authentication token in combination with a long-lived refresh token.

If implemented properly the refresh token accomplishes a couple of things. Since the refresh is only passed periodically instead of with every request, it is less likely to be compromised in the first place. When the refresh occurs, all existing authentication tokens that were created with that refresh token are automatically expired, so if the refresh is ever compromised, and two users try to use it simultaneously, there would be a continuous fight over the auth token and multiple refreshes would occur before expiration. The server could easily detect this and expire the refresh token too. Then the user would have to login again and only the real user would be able to do that. More info about this can be found here.


I'd like to first specifically comment on this statement -

  "There are so many unsecured sites using a reverse proxy and I feel
  like that doesn't protect them."

Just because you see some site is using X or Y CDN/WAF, it doesn't mean they have some/any security.
Some use free/cheap-tier plans that offer partial security, and others don't turn ON certain WAF features (even if paid for).

Like any security measure, virtual or physical, Web Application Firewalls (via reverse proxy or any other deployment format) aren't a silver bullet.

It doesn't mean you shouldn't use them, on the contrary! Using a proper Cloud WAF helps you avoid very common pitfalls many websites suffer from:

3rd-party code - You might be writing some kick-*** code, but what
about the 3rd party libraries you use? What about servers running
WordPress/Joomla/Drupal/Magento/…?

You can't be responsible for every piece of code that your system runs, and time-to-patch is critical.  A proper Cloud-WAF provider gives you virtual patching that’s magnitudes faster and more reliable than a panicking siteop.
Lower-level vulnerabilities - Remember Heartbleed? Shellshock? POODLE?

How long does it take you to deploy OS-level patching? In
some cases, if it's more than a couple of hours, good chances you're
compromised.
DDoS Mitigation - Hopefully everybody understand by now, that you can only completely mitigate DDoS using a cloud scrubbing service.
(And no, AWS is NOT a scrubbing service).
Filtering out abusive visitors - Comment Spam, Referrer Spam, Scraping, etc.

Things that, unfortunately, have anything to do with
your ability to "program correctly". Cloud-sourced client
classification and reputation gives you that.
Security at the edge – Not only content caching! You can offload many heavy-lifting and hassles to the edge.

Want to require 2FA and/or CAPTCHA on certain pages? Deliver them from the edge.
Want to block certain IPs? Filter at the edge.
Don’t want visitors from outside the UK? Filter at the edge.
Don’t want Firefox from Iran accessing /login more than 5 times per minute? You guessed it, Filter at the edge.

That’s just to give you a taste, there are many more great things a CBSP can give you (we haven’t discussed visibility at all).

Disclosure: I work @ Imperva Incapsula, a CBSP which provides Cloud WAF/DDoS Mitigation/CDN/GSLB.


Yes, sending the information using POST over HTTPS is the typical way of doing things.


Snort does not block packets.  Snort is an intrusion detection and prevention system.

The React rule option is intended to be used with TCP connections.  The react keyword, when it matches, will generate multiple reset packets to both end of the connection to shoot it down.

Since ICMP is a datagram protocol that operates at the network level, there is no way to "shoot it down."  If you'd like to block these you really need to use a firewall. :)


Is sending address, email address, etc. unencrypted over Internet - like Three UK does - bad security practice?

The answer by @Guille is absolutely correct, however there is one aspect that it might not take into account and specific to mobile networks.

The screenshots posted show that you are connected to Three via 4G which is encrypted and is very possibly never leaving to the internet and is handled directly by Three via an internal network (4G is considered secure encryption as far as I am aware at this point) therefore the traffic will only be unencrypted in transit in Three's internal networks. This scenario would be very similar to how many companies transfer all this data using HTTP, and only encrypt as it leaves their networks at, for example, load balancers or reverse proxies. In this case it is never leaving the "trusted" network.

One way to test this is to turn on WiFi and check this is still handled the same way.

I would certainly agree that HTTPS would be best practice, but it may not be as bad as it initially appears.


What popular online services allow passwordless authentication using digital signatures?

PKI isn't a very popular approach to 2 factor authentication outside the enterprise because of the overhead of protecting the private keys and managing certificates, but there are some commercial solutions available.

Take a look at Layer7.

Years ago I used to work for Baltimore Technologies (famous for the first digital signature of legislation (by Bill Clinton and Bertie Ahern)) and we looked at doing exactly what you are wanting. Two factor authentication using digital signatures. The problems really are:

Where are the keys going to be  generated and stored?
Who can access the keys? and
How to we interface between the client and the device which holds the keys?

These are not easy questions to answer, but technologies like TPM may eventually come in to answer some of them. However, keys will still not be mobile. So maybe eventually we can use mobile devices for key storage? But, what happens when the device is lost / stolen / broken? And, again, how to we link to device to the client browser for authentication purposes?

Perhaps the most interesting implementation of device authentication I have seen is that by Barclays Bank. PINSentry uses a handheld device and your bank ATM / debit card in order to provide authentication to the Barclays online services. Check it out. This isn't a PKI implementation. Its a one-time password application, but the application is executed on the smartcard.

The most popular method for two-factor authentication is one-time password. These come in a variety of forms and can be provided by dedicated devices or mobile devices. Look at Authy, VIP Access or Google Authenticator.


What are realistic rates for brute force hashing?

For a simple invocation of MD5 or SHA-1, a realistic rate is between 1 and 10 billions of passwords per second. That's what can be achieved with a good GPU. Furthermore, if the hashing is not salted, then the attacker can share the effort between several attack sessions, usually using precomputed tables (e.g. rainbow tables): an attacker, somewhere, had to hash gazillions of possible passwords once, but then the resulting tables can be applied to thousands of hashes with only a small cost.

If the hash function is proper (as described in this answer), then it uses a slowdown parameter which makes the function as slow as can be wished for. Slowness impacts both the defender (the honest server who uses the hash to authenticate users) and the attacker. We could imagine, for instance, that the defender is ready to invest 10ms worth of his own CPU on each hashing instance, which means that the defender can handle 100 password hashes per second. The attacker can throw more PC at the issue, with multiple cores, and possibly use specialized hardware (GPU, FPGA...), which may give him some boost; let's say that the attacker can be 100 times more efficient at the password hashing than the defender, leading to brute force performance of 10000 guesses per second.

The boost that the attacker can obtain through specialized hardware depends on the function (e.g. a GPU will be good for attacking PBKD2/SHA-256, not as much for attacking bcrypt). How much hardware the attacker will be able to throw at the problem also depends on external parameters (his budget, his motivation...). The slowness used by the defender is a trade-off, because increased slowness uses server resources and may make it more vulnerable to denial-of-service attacks.


How did the Facebook Originull vulnerablity of Access-Control-Allow-Origin: null allow cross-origin access?

I'm Ysrael and I'm the researcher that found this vulnerability.

Let's divide your question into 2 parts:
A. How did the Origin of the browser become null?
B. How the null Origin affect Facebook servers?

Let's start with A.
The Origin is part of the CORS mechanism and it is intended to tell the server where the request comes from.
When the server gets the request, the server can decide to allow this Origin to receive the response.
One of the ways to bypass this protection was to find an Open-Redirect within one of the pages, and then to direct the user to dataURI schema.
In the past, dataURI received the previous Origin because there was no other Origin to give him.
As a security improvement, the modern browser sets the Origin to null so the XHR requests from this dataURI page won't have the proper Origin.
In Chrome, this is the situation in any case, and in Firefox it happens only when the page refreshed via meta tag to dataURI.

So this is how the Origin became null.

The 'Originull' attack uses this behavior in order to bypass security checks that are based on the Origin, because most of the time, the programmers won't think of null as the value in this field.

Now let's get to part B. How this affected Facebook.

Facebook uses Access-Control-Allow-Origin on its Messenger servers, because they use a different sub-domain.

Most likely, the Messenger sub-domain has a security filter on the entrance, and then the requests are passed to the internal server that responds to the users.
When the server wanted to respond, it took the value from the request's Origin and returned it on the Access-Control-Allow-Origin header.
This development design allows Facebook to keep up the allowed Origins in one place only.

The messenger sub-domain also allows regular GET requests.
Regular GET requests didn't have an Origin header at all.
In many development languages, a non-exist Header returns the value null.

So, the filter has a condition that allows null to pass (so the GET requests will pass correctly), and the server takes the value that it receives in the request's Origin header (null) and returns it to the client in the Access-Control-Allow-Origin header.

Simple, right? ;)

You can find the technical details and screen shots in the full-disclosure document on BusSec's web site at:
https://www.bugsec.com/wp-content/uploads/2016/12/Blog-Post-BugSec-Cynet-Facebook-Originull.pdf


John the Ripper password cracker is viable?

Yes.  I believe JTR, Hashcat, and InsidePro are the three dominant password crackers these days.  You may find it lacking features that the others have or vice versa.

All three have teams using them pretty successfully in the major password cracking competitions, like Crack Me If You Can.


A special file as the second factor in 2FA

As described this scenario wouldn't satisfy any requirements I have for MFA from a vendor or anything, but it is, strictly speaking, a Something you Have. You're perilously close to re-inventing the wheel here, since SSL client certificates and PKI already exist.

A client certificate installed on a device/browser is a valid factor for authentication and combined with a username/password is suitably multi-factor. There are implementation issues with PKI that make it difficult, so it isn't common in many environments.

If you'd like something more whiz-bang there are several options for doing multi-factor with mobile devices that generate codes (TOTP - Authy/Google Authenticator/etc.) or do really fancy push notification and/or one-time passcode generation (Duo Security's service and mobile app).


Why are there different pentest phases/stages/methodologies?

Let's take a critical look at the collection you have:

The Wiki list is from a Cybrary article. That's basically one author's opinion, and I'm not sure you should include it in a comparison with more general advice. "Maintaining Access" and "Covering Tracks" are odd steps to include, unless you are doing specific testing on the detection capabilities of the target. "Maintaining Access" is often prohibited in pentest engagements because you do not want to introduce backdoors in a system (that could be forgotten).
The Impervia list differs from the rest by including "Maintaining Access" (imitating APTs). This, also, is a highly specific test that should not be included in a general framework of steps.

Taking the common steps together, and eliminating the highly specific steps, you end up with:

[Pre-engagement Interactions]
(Planning and ) Reconnaissance / Intelligence Gathering
Scanning

[Threat Modeling]
[Vulnerability Analysis]

Gaining Access/Exploitation
Post Exploitation
Analysis / Reporting
[Clean Up and Remediation]
[Retest]

The [] items are overhead and managerial items and not about the pentest itself.

Threat modelling and vulnerability analysis steps are explicit steps that enable the common step of "Gaining Access/Exploitation". These two steps do not need to be mentioned, yet for those who have not performed a pentest, it can be helpful to highlight these steps.

So, it's not that the collection of steps you found are very different from each other or that some sort of common, standardised list is required. It all depends on the goal and context of the pentest, and why you need a list of steps to begin with.


How to improve performance of encrypted MySQL database on Linux backend server?

Full Disclosure: I am Gazzang's Chief Architect, as well as one of the authors and the current upstream maintainer of the eCrypfs encrypted filesystem.

Hi @Dan,

ezNcrypt is a commercial product sold by my employer, Gazzang.  It is built on top of eCryptfs, an open source encrypted filesystem built into the Linux kernel and with user space utilities available in all major Linux distributions.  I'll try to address your question in an unbiased manner :-)

eCryptfs is 100% GPLv2 free software.  It's a mature encrypted filesystem widely available in Linux.  An estimated 3 million Ubuntu desktop users use eCryptfs through Ubuntu's Encrypted Home Directory feature.  Each file is individually encrypted (juxtaposed against device-mapped full-disk and full-partition encryption).  eCryptfs minimizes the performance penalty as compared to some other encryption options, as noted in this report from Phoronix, and this design document from Google's ChromeOS which uses eCryptfs.  If you know what you're doing (or with a fair bit of independent research), you could almost certainly accomplish the encryption of your MySQL database using eCryptfs while minimizing the performance impact. It will take a fair amount of effort, and your configuration will have limited quality assurance and reproducibility, though I know many people using eCryptfs for far crazier use cases!

ezNcrypt includes an open source (GPLv2) DKMS kernel module, but a proprietary user space sold as a licensed commercial product from Gazzang.  With the commercial license, customers receive first class customer support and suite of utilities that make encrypting any database (including MySQL) much, much "easier" as the name implies.  At the lowest level, ezNcrypt is still using eCryptfs, but the thoroughly-tested, database-targeted suite of tools is a for-pay, commercially supported product.


Generally, yes, it can. You can even find instructions about how to fix this problem.

More specifically, Chrome sync synchronizes (per the advanced sync settings of  Chrome v.47):

Apps and extensions
Autofill information
Bookmarks
History
Passwords
Settings
Open tabs
Themes

If any of those can be maliciously manipulated, it will likely be spread by Chrome sync. Here's malicious activities that I can think of; I'm sure there are more:

Apps and extensions - Many, many ways to do bad stuff here. These can open windows, alter page contents, redirect pages, etc...
Autofill information - An attacker could try to have online orders shipped to the their address or fill in other information.
Bookmarks - Alter your bookmarks to go to attacker's site.
History - As this is used for completion, you can misdirect the user when typing an URL to go to the attacker's URL.
Passwords - Assuming you can only set passwords and not get them, all that I can think of is that an attacker could trick a user into logging into a site as the attacker. Presumably the user would enter confidential information or do something else that would be of value to the attacker.
Settings - You mention proxies. Therer's also the settings for the new tab and home pages. I'm sure there's more.
Open tabs - Open pages with malicious content or downloads on remote devices.
Themes - Can't think of much. Perhaps change the user's theme to lots of cats?

Destroying data in Chrome sync may also be a way to spread malicious activity. For example, just deleting all of a user's bookmarks could cause great pain for bookmark-heavy users.

While every piece of browser malware may not be applicable to being synced across instances, certainly there are many ways to do it.


(spp_sdf) SDF Combination Alerts in Snort

This is when Snort detect some kind of sensitive data (email or social security number).

  The Sensitive Data preprocessor is a Snort module that performs detection and filtering of Personally Identifiable Information (PII). This information includes credit card numbers, U.S. Social Security numbers, and email addresses. A limited regular expression syntax is also included for defining your own PII.

http://manual.snort.org/node17.html#SECTION003217000000000000000


Hijacked certificate and Remote Login. Office computer compromised with a virus?

This will probably sound like a vague answer, but without further analyses of the suspect program/executable, its activity done on-system, packet captures of the suspicious network traffic, etc., this is the 'best' answer I can come up with.

Any 'unknown' program running on a corporate system of any type is inherently a security risk.  Therefore, the existence of the program can in and of itself be considered its own security risk.  Whether the program is simply 'sitting on the computer' doing nothing, or actively running and doing something is another matter to take into consideration when responding to the existence of the program.

Without more detailed dissection and analysis, it is not possible to give you a definitive answer for your first question of "Is disabling the program enough to mitigate the security risk".  However, typically just 'shutting off' the suspicious program is not enough to stop the core cause of the risk; without more in-depth analysis, however, to say whether this is enough to disable the security risk is pure speculation (and more often than not it is safer to assume "No, this is not enough", from my experience).

However, this is not the right question to be asking.  The proper question that the IT team (and/or any relevant information security officers or teams) should be asking is "How did this program get there?"  This question is important because if it is a program installed by an end user that happened to have admin privileges, that's one thing.  If it's a program that got in there without anyone's knowledge, then you have enough to suggest that there may have been a breach somewhere - whether a user went to a site that exploited a vulnerability in the specific system or not or whether the system was hacked into by an external source or not is still to be determined.

As to your second question about whether a known Windows 10 exploit/attack vector was used to get this program to run in your environment, we can't answer that.  Any statements saying "yes" or "no" are pure speculation, and cannot be backed by any evidence.  Such evidence would be gained through analysis of the system to determine any suspicious network traffic to/from the system, any suspicious remote logins, suspicious system calls, etc., of which we can then use the data found in those investigations to determine whether or not a "known issue" was exploited or not.

As a whole, therefore, the best thing I can say in answer to your questions is this:

  Disabling the program or service, alone, is probably not enough to mitigate the risk.  However, this is not a certain answer, and without more in-depth analysis the best conclusion I can give you is that there is a potential security risk of unknown scope and risk factor on the system in question, of which additional analysis of the program's activity and behavior can help to determine such scope and/or risk factors.

If I absolutely had to make recommendations to your IT team, then it would be these, to start:

Remove the affected system from the network, and provide a new, clean machine if possible to replace this affected machine.
Submit the suspicious executable to VirusTotal or similar for analysis.
Analyze network traffic on the affected endpoint system(s) or on the network at-large to identify suspicious traffic, and from there determine potential infection vectors or system breaches through which threat actors could utilize to hijack endpoint systems or to 're-implant' the application in other systems.

But these alone are not fully-informed suggestions backed by evidence, and are more 'general' suggestions that many in the Information Security field will be giving you in response to any suspected breaches or infections; in each and every case, deeper, more in-depth analysis of the affected system and suspect executable/program is necessary to give any truly informed recommendations.


How can I detect possible spyware/keyloggers in my computer?

You could check who is hooking the keyboard API in the system using something like this or this and work back from there.
However there are many other techniques to achieve this so unless you are experienced with win32 systems and plan to spend a bunch of time I would recommend you to just do a clean install.

p.s
If you want to validate your assumption you could create a new account somewhere and monitor whether someone logs into it, sort of a honeypot account...