How can non-secure or non-HTTP-only cookie affect security of an HSTS website?

The non HTTP Only cookies could be compromised if there are any XSS flaws on the website.

The non secure flagged cookies could be compromised if the user was using a browser that does not support HSTS (such as Internet Explorer 10). This would be a MITM attack on a normal HTTP connection to any server in order to redirect to the HTTP version of the domain and then intercept the sent cookies.

The Secure and HTTP Only cookies could be poisoned if the user hasn't yet visited the site in order for the HSTS policy to be set and the site isn't in the browser's preloaded list. This depends on what the site does with the cookie values, but it could form part of a session fixation attack if an attacker set the cookie value. This would be without the Secure flag being set (because they would be MITMing a HTTP connection), however the server only receives the cookie's name and value and does not know whether the cookie is marked as secure or not on the browser.


It's an information disclosure vulnerability.  The main risk that I'm aware of is that it allows users to be identified.  The NSA uses such information to target users for QUANTUM attacks.  You touched on another one which is profiling previously visited sites.  An attacker could use this information in a social engineering attempt.  I agree with you, it is a very low security risk.


Sniffing IMAPS traffic! Are there any tools for this?

The answer is stunnel! Fantastic! So to make this work.....

In the config file make a new section:

 [imaps-server]
 client = yes
 accept = 127.0.0.1:143
 connect = sslencryptedimapserver.com:993

Open thunderbird, change the account to standard IMAP without SSL and change the host server to localhost
Log with wireshark and you'll be able to see the commands!


The strength of a password is, exactly, a measure of what it could have been. The technical term for cryptographers is "entropy". The rough idea is the following: there is a set of "possible passwords" -- the passwords that you could choose. The attacker will try the passwords from that set. The attacker will be defeated if the set is large enough, because the larger the set, the longer it will take the attacker to hit the right password (on average).

For instance, if your passwords are sequence of 9 decimal digits, then the set of possible passwords has size, exactly, one billion (109). If you choose your password at random in that set, then, on average, the attacker will have to try half of the set before trying yours, so 500 millions.

Thinking about a big bag of possible passwords from which you choose, at random and uniformly, works as long as you really pick the password at random and uniformly. That's easy to do with a computer, very hard with a brain: the jelly which you keep inside your skull is remarkably good at a lot of tasks (such as image recognition), but not at randomness.

The important point to understand is that password strength comes from the password generation process. A given password is not strong "by itself". That's where "password meters" totally fail. A "password meter" sees only the password you type, not how you chose it. If you prefer, a password meter site will tell you how much time it would take an attacker to guess the password, assuming the site is the attacker, and knows nothing else about you. That's not completely realistic: your enemy knows you, much better than a lambda site on the Web. He is after you, specifically, and he must be assumed to be smart.

So, to estimate your password strength:

If you generated the password in your head, then try again: it is weak. From now on, I assume that you produce the password with a random generator (a computer with /dev/urandom, some dice, coins flipped... the choice is large).
Compute the size of the set of possible passwords, depending on your generation algorithm. For instance, if you use a 20-sided die to generate symbols (letters from A to T), and you launch the die 8 times, then the set of possible passwords has size 208 = 25600000000.
Estimate how many passwords the attacker may possibly "try". This is where the encryption details matter. GnuPG follows the OpenPGP format in which passwords are converted to keys through a hashing process which is intrinsically slow, in a configurable way (see section 3.7.1.3 of RFC 4880). This is expensive both for you, and for the attacker. The attacker has several computers which are bigger than yours, so he will be able to try a lot of passwords, but not ludicrously many. As a rule of thumb, consider that the attacker can try no more than one million passwords per second.
From the two previous steps, compute how much time it will take for the attacker, on average, to crack your password. On average, he will have to explore half of the set of possible passwords. With the numbers above (8 symbols from a 20-symbol alphabet, one million password guesses per second), you find 12800 seconds, i.e. a bit more than 3.5 hours. That's not much for comfort... but each additional symbol multiplies the attacker effort by 20. So 10 symbols with your D20 bring the attack time to about two months, at which point the attacker ought to declare that it is "not worth the effort" (which is your goal).

Hence the rules for strong passwords:

Don't trust your brain. Generate the password with a computer or dice.
Accept the generation result. Don't generate passwords until you find one which seems "easy to remember".
Stick to symbols which are easy to type. In particular, a sequence of lowercase letters is easy on a smartphone. Mixing cases, digits and punctuation symbols makes the password usage frustrating.
Use sufficiently many symbols so that the set of possible passwords is large enough. This depends on how well (or how badly) the encryption system hashes the password into a key. Unless the encryption system is tremendously incompetent (in which case you should not use it at all), 12 or 13 letters will be enough (do the math !).

In the famous XKCD password comic, the author suggests taking a list of 2048 "common words", and then selecting four such words (at random, with dice): the four words, concatenated, will be the password. The set of possible passwords then has size 20484 = 17592186044416, which is quite good. The point of the author is that such passwords are easy to remember (whatever the four words you obtain, you will find a corresponding "story"). Personally, I prefer shorter passwords which are just random letters (my brain, being that of a mammal, is bad at randomness, but it is quite good at remembering strings of symbols).

The key to remembering a password is to type it daily.


Diffie-Hellman certificate verify message

Diffie-Hellman certificates are certificates which contain a Diffie-Hellman public key (such beasts are exceedingly rare; nobody does that in practice). Such certificates can work for client authentication only if:

the server's certificate also is a DH certificate;
both DH key pairs use the same parameters (they work in the same group);
and a static DH (not DHE) cipher suite is used.

In such a situation, the server shows its DH public key as part of its Certificate message, the client shows its DH public key as part of its own Certificate message, and both DH key pairs are used for the actual key exchange (that is, the client uses its private key and the public key from the server, and the server uses its private key and the public key from the client). Client and server are mutually authenticated by virtue of the client (respectively the server) using the DH public key of the server (respectively the client) as found in a certificate duly signed by a trusted CA.

Conceptually, the signature by the CA suffices, which is why there is no need for an actual Certificate Verify message (or, for that matter, a Server Key Exchange message). In fact, we can consider that when a DHE (ephemeral DH) cipher suite is used, then both the client and server play the role of a subordinate CA, with the resulting "certificates" being the Certificate Verify and Server Key Exchange messages...

Diffie-Hellman certificates (and DSA signatures) were promoted by the US Federal government in the late 20th century because RSA was patented at that time. But the DH standard (ANSI X9.42) has never been freely available, so open-source software did not follow, and DH support in deployed systems is poor. Which is why DH certificates are a rarity. A museum piece, even.


Is it possiible to get a virus without running an exe file?

It is possible for the act of merely downloading a file and doing nothing with it to be a security vulnerability, but this is true of any file type (not just exe files), and attacks of this nature are much more difficult than simply tricking random people into opening an untrusted file. This kind of attack would be exploiting some error in your browser or download manager's programming to execute arbitrary code rather than running a malicious exe file directly. This would essentially be equivalent to getting a "drive-by-download" virus from visiting a website, except it would be exploiting the download engine rather than the browser scripting or rendering engine.

Executable (exe) files are mainly dangerous because they run a program on your computer. If you run a program you are giving it permission to do anything your user account has access to do, including installing other programs, reading or destroying data, modifying system configuration, etc. If you do not run that file then it does not execute and you have not given it permission to do anything


Why wasn't the KRACK exploit discovered sooner?

The 802.11 specification that describes WPA2 (802.11i) is behind a paywall, and was designed by a few key individuals at the IEEE. The standard was reviewed by engineers, not by cryptographers. The details of the functionality (e.g. retransmission) were not widely known about or studied by security professionals.
Cryptographer Matthew D Green wrote a blog post about this subject, and I think this section sums it up quite nicely:

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications — you’ll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.
The IEEE has been making a few small steps to ease this problem, but they’re hyper-timid incrementalist bullshit. There’s an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they’ve been public for six months — coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.


Stored XSS Cookie Stealing - shortest payload

I don't know about shortest but may I suggest <SCRIPT SRC="//X.YZ/ABC">? Unless there's CSP (which should block your exploit anyhow), injecting a script tag is a great way to exploit stored XSS. Through protocol-relative URLs and URL shorteners, you can get a very short URL that points to your script directly (or just to the root of your domain, which will serve / redirect to a script). No portion of a script tag needs to be lower-case (I'm not sure if it's strictly standards-compliant but I doubt any browser will care). The script can, of course, be of arbitrary length and characters, and can run wild with the full power of the origin it's running on (including stuff like XHR back to your server with the cookies in the URL or body).


How to find out whether a state has its own CA?

The question of whether they have a CA is hard to answer, as anyone can make a CA. The important question usually is not whether they have one, but whether they have one recognized by major browsers. There is a list of CAs trusted by Mozilla here. You can find similar lists for other browsers and operating systems (some browsers use lists included in operating systems they run on, Chrome for example).

But for example, the US has its own CA, that is not trusted by Mozilla and other browsers/OSs. It is however trusted by Android (for some reason Android trusts way too many CAs). This means if you visit a site with certificate from this CA using Firefox, you will get an SSL error.


How do I access a website on my phone without it being able to determine that it was accessed from the same phone and location?

Given a site can use browser fingerprinting methods, there no tool that would completely cover everything. The paradox is that the more you try to make your browser look like something it isn't, the more unique it becomes. You can use tools like Panopticlick or AmIUnique to investigate your current browser.
Therefore, even with Tor, it's better to use the Tor Browser with its default settings. The Tor Blog has a good article on the subject, Browser Fingerprinting: An Introduction and the Challenges Ahead:

What Makes Fingerprinting A Threat To Online Privacy?
It is pretty simple. First, there is no need to ask for
permissions to collect all this information. Any script running in
your browser can silently build a fingerprint of your device without
you even knowing about it. Second, if one attribute of your browser
fingerprint is unique or if the combination of several attributes is
unique, your device can be identified and tracked online. In that
case, no need for a cookie with an ID in it, the fingerprint is
enough. Hopefully, as we will see in the next sections, a lot of
progress have been made to prevent users from having unique values in
their fingerprint and thus, avoid tracking.
Tor + Fingerprinting
In the end, the approach chosen by Tor developers is simple: all Tor
users should have the exact same fingerprint. No matter what device or
operating system you are using, your browser fingerprint should be the
same as any device running Tor Browser (more details can be found in
the Tor design document).

If you only need two accounts and they shouldn't be linked, it's relatively easy (in theory) to:

Use different browsers to prevent browser fingerprinting.
Remember to systematically use a different IP address when using the second account.
Always close the browser before opening the other to prevent background activity.

However, it's only a matter of time when you do a mistake that could help linking the accounts.


As mentioned by echelon, Zeus source code is available in GitHub.

Availability of its source code (leaked in 2011) is one of the reasons many modern botnets are evolved from Zeus.

Be careful when infecting with your botnet several VM/computers you control, you don't want the to infect real user machines with your toy botnet!

For additional security you can put a stop date to ensure it will stop in a few days or -even better- in the past, so it only works where you explicitly misconfigure the clock.


Is it safe to use same key pair to encrypt and sign?

It is not feasible to crack a private key when having multiple encrypted/signed messages. Note that:

According to the OpenPGP standard, when encrypting a message the public key is only used to encrypt a random session symmetric key, which is then used to encrypt the message itself.
Generating a new key pair each time would involve redistributing your public key, which is actually the weak point in Public Key Infrastructures.
If your PGP key pair is DSA/ElGamal instead of RSA you already use a different key for signing (DSA) and for encrypting (ElGamal).


Why VirtualBox Windows 7 guest machine is not supporting malware analysis

If I understood it right, you're trying to deliberately infect your VM but the malwares you downloaded don't seem to work properly.

Assuming you don't try to launch 64-bit malware in a 32-bit VM, or malware created for another edition or version of Windows, the most probable cause for me is that your malwares try to detect if they are running in a VM or on a computer that's used for actual work, and disabling themselves to avoid detection (mostly to make it harder for antivirus firms to detect and study them).

As an example, some malwares in the wild have recently been found to count Word documents in the current user's folder ; they assume that if this number is close to zero the computer is likely to be only a test machine, and they stop there.


What is the current security status of Diffie-Hellman key exchange?

The weakdh.org Web site is about the Logjam attack. Contrary to what the Web site name may suggest to the unwary, this is not about DH being weak; it is more about doing things weakly when using DH.

Diffie-Hellman works in a multiplicative subgroup of integers modulo a given prime p. To do some DH, you use some DH parameters which are:

p : a big prime, called the "modulus"
q : a divisor of p-1, called the "subgroup order"
g : an integer modulo p of order q (this means that the smallest integer k > 0 such that gk = 1 mod p is k = q)

For DH to be safe, you need the following:

p must defeat attempt at discrete logarithm through Index Calculus. This means that p must be large enough, and also must not have any "special structure" such as being very close to a power of 2, because such structures allow for improvements in Index Calculus. It so happens that size requirements for DH are about the same as the size requirements for RSA, though the underlying reason for that is intricate and partly coincidental. So, basically, use a random p of 2048 bits, and you will be fine.
q should be prime or have a prime divisor whose size is enough to defeat generic algorithms for discrete logarithm. If the size (in bits) of the largest prime divisor of q is z, then generic algorithms have a cost in 2z/2. For best results, arrange for q to be a prime of 256 bits or more.
Systems that use the parameters to perform a DH key exchange must generate a random integer between 1 and q-1 uniformly, using a cryptographically strong source of randomness, of course. If q is prime and larger than 256 bits, it suffices to choose a 256-bit random value to achieve 128-bit of security. However, if q is not prime, things are more complex: if q has size r bits, and the largest prime divisor of q has size e bits, and e ≥ 256, then one may choose a random value x of size r-(e-256) bits to get the usual "128-bit security".

When p is a so-called "safe prime", then p = 2r+1 for a prime r, so for any generator g that is not 1 or p-1, the order of g will be either r or 2r, so it suffices to generate DH secret keys x as random 257-bit values. The "safe primes" are not actually any safer than other primes, except for that point: they tolerate the choice of relatively small DH secret keys for any generator.
Last but not least, DH is a key exchange algorithm that does not, inherently, provide authentication or confidentiality. DH is "safe" only when used within a protocol that uses DH and other algorithms with proper integration to achieve such sought after characteristics as data confidentiality and integrity.

Speaking of which, some (many) SSL/TLS implementations did things improperly, in that they gladly accepted to do DH with weak parameters, in particular a 512-bit modulus. The protocol itself is suboptimal in its handling of DH because the ServerKeyExchange message allows the server to send the DH parameters p and g to the client, but not q, leaving the client a bit in the dark. Thus, the client must either "play safe" and generate its key in the full 1..p-1 range, or try to use a shorter exponent (say, 256 bits, not 2048) for a reduced computational cost, but possibly at risk of weakness in case the subgroup order q is not prime. A better design would have allowed the server to send the value of q and the size of the biggest prime divisor of q. In that respect, the ECDHE cipher suites of SSL/TLS (DH translated to elliptic curves) have a better design.

For a practical answer if you are configuring your SSL/TLS server: you should use a modulus of at least 2048-bit, and a generator g such that the order of g is a prime q of at least 256 bits; alternatively, you may use a modulus p which is a "safe prime" (the order of g will then be either a very big prime, or twice a very big prime, which is almost as good). Some people feel safer when they generate their DH parameters "themselves"(*) instead of reusing existing values; if that's what it takes to allow you to sleep at night, then do it.

(*) People never generate their DH parameters themselves; they use a computer. But we are talking psychology here anyway.


Metasploit exploit which doesn't require initial user interaction

To do this, you need to attack the services running on a remote machine. There are numerous Metasploit modules that do this, and a nice, curated list can be found on Exploit-DB. The term you are looking for is a "remote exploit".


Avoid cross site scripting in XML namespace

I would not consider it XSS vulnerability, as SOAP services are usually called by another service that would not execute anything in the response.  However you could address it by validating the namespace and throwing a more generic error without including any contents from the payload.  Trying to encode it differently is just creating a moving target and not really fixing it.

XSS is only if you can get a person to go to a web site by redirecting their browser so that it does a POST or a GET to another site, and you can inject your own contents in that site that is executable client-side scripting such as JavaScript.


The main thing to understand is that your client is trying to solve an impossible problem.  Trying to prevent someone with physical access to the machine from accessing it is like trying to make water not wet.  It ain't gonna work.

If you want to do the best that you can, you can take the steps you mention, and I also suggest you research "kiosk mode".  But fundamentally, it will still be relatively easy for employees to use the computers for activities your client doesn't like.  It will be as easy as inserting a Linux LiveCD, or a gazillion other methods.  You're never going to close them all (not and leave the employees with a useful computer), and realistically speaking, you're not even going to be able to make it terribly difficult to defeat the security measures.

So I would argue that there are two important takeaways: (1) keep your expectations low; there is only so much that technical methods can provide, so don't waste too much time or energy trying to invent a foolproof defense, (2) this is primarily a matter for policy and social methods, rather than technical methods -- for instance, your client might want to adopt and promulgate a clear company policy regarding acceptable use of company computers, and be explicit about the penalty for violations.


userdel -r -f sync

With the -r option you are not only removing the user but all data below the users home. On my system the users home is /bin:

$ grep ^sync: /etc/passwd
sync:x:4:65534:sync:/bin:/bin/sync

Only, /bin is the place where lots of essential binaries are stored. Thus, it is not surprising if essential functionality gets lost if you remove /bin.

  The book suggests to remove the sync user

That's an unusual recommendation. The usual recommendation is to disable shell access for system users like sync or daemon and lock these (i.e. no valid password) which usually is already done on common systems.


Is it possible to attack car key fobs with regular RF devices?

Yes, it is, using either the HackRF or other SDR devices capable of replaying the signal.
You can jam the key fob by simply listening to the signals, the frequency on which the key fob operates gets interferred, then you are free to use the first code you got and store the later one to open the car in another moment.
To secure against this hashing the button should do it, or using time-based algorithms

Source: https://www.youtube.com/watch?v=1RipwqJG50c


This looks like a coincidence. It looks like your hard drive broke while you happened to have an SSH session open.

SSH is a point-to-point protocol. As the client, the only one you are communicating with is the server. It is also a very secure protocol specifically designed to not allow any 3rd party to eavesdrop or manipulate data. Maybe if your SSH client has a vulnerability, a malicious server could exploit it. But that would assume that:

The server you connected to is malicious. When it is a professional hosting provider, that's unlikely. Hacking your customers is bad for business.
They had nothing better to do than randomly destroy your data. That's really unlikely, because there is no benefit in doing that. There is a million better things to do when you have a remote execution vulnerability, and most of them work best when the user doesn't notice anything at all.


Which block cipher should be used in TLS 1.2 (while keeping 1.3 in mind)?

In my context I am limited by both processing power and amount of data
  to be sent, so could anyone suggest or give proof of which of the
  block ciphers supported by TLS 1.2 and future 1.3 are best in this
  regard?

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Reasons:

CHACHA20-POLY1305 cipher suites are part of TLS1.2.
Is available on LibreSSL since 2.3.0 and will be added to OpenSSL 1.1 (to be released on 2016-08-25).
Is mobile device friendly and much more efficient (especially on devices that do not support hardware accelerated AES).
Offers 256bit of security by default (unlike 128bit for AES, in most cases).
Is compatible TLS1.3 as the new version will drop static RSA and DH key exchange mechanism (RFC). ECDHE will be preferred in most cases.
Is built using an Authenticated Encryption with Associated Data (AEAD) construction like CGM (weakened. Cause: nonce reusage initial paper, BHUSA2016 slides + original paper), CCM or EAX (broken).


How does AES-GCM handle large blocks with a 128 bit key?

AES-GCM, like all versions of AES, has a block-size of 128 bits, or 16 bytes. Generally speaking, you shouldn't have to worry about the "merging encrypted blocks" as the implementation should handle encryption of data larger than a single block for you, and simply provide you with the full ciphertext that is the end result.

Likewise, you don't have to worry about generating the authentication tag.  The implementation generates the authentication tag for you. and you simply need to retrieve it once encryption is complete.

More Technically:

AES-GCM is a combination of AES-CTR and a authentication tag computed using Galois field multiplication.   The fact that it is based on counter (CTR) mode which is a streaming mode means that the ciphertext is of variable length.  The output can be the same length as the plaintext input, and does not need to be padded to make a full 16 byte final block as block modes such as ECB or CBC would require.  The authentication function is a keyed hash function computed over both the ciphertext, and an additional authentication (but not encrypted) data which will always include (at minimum) the nonce.


What are the problems with encrypted but unsigned data?

A good example is the flaw on CBC, demonstrated within SSL and in particular for password recovery in a IMAP-over-SSL setup. See for details. Briefly speaking, SSL has a MAC, but a small part of it was doing things with the received encrypted data after decryption but before verifying the MAC. Namely, the receiving system was decrypting the data, checking that the padding was correct, reporting an error to the peer if that was not the case, and then only checking the MAC. The error message was different if the MAC was wrong. So the receiver (the server, in the case of the IMAPS password recovery) was leaking a single bit of information about whether the padding found after decryption was correct or not. It so happens that SSL uses a padding which is similar to the one described in PKCS#5. Details are subtle (but not mathematically hard, once you understand that XOR is commutative and associative) but it allowed the attacker, by modifying a few well-chosen bytes, to guess one by one the plain data bytes. Assuming a regular connection attempt with identical contents (typically, an Outlook Express which checks the server for new mail every 5 minutes), the attacker had 1/256 chance of guessing a new byte at each connection. At the end of the day, voila! a full password.

This case shows what may happen in the presence of active attackers and no MAC, even when the "no MAC" part is very transient; because SSL has a MAC, only it was checked too late in the process. The correction is to always check the MAC, regardless of whether the padding was good or not, and to report bad padding and bad MAC with the same error code (you have to check the MAC, because not doing it when the padding is wrong may make the server respond a bit too fast in that case, leaking the bit of information through timing). Without that correction, the server leaks some information through its behavior, be it a distinct error message or even a slight delay (or lack thereof) when responding. That's a single bit at each attempt. Yet it suffices to mount a password-recovery attack.

That attack was published in 2002. Yet, in 2010, the same bug was still present in how ASP handles encrypted cookies, allowing an active attacker to hijack a protected session in less than an hour. The attack was demonstrated as practical in 2002; in 2010, it was demonstrated as actually practiced in the field.

We do not have an exhaustive list of the attacks made possible by a lack of MAC. So the common wisdom is that there is no proper security against an active attacker when there is not a dedicated integrity check, and that's a MAC. The common mistake is to believe that in any given situation, attackers can only be passive. Wired and wireless communications are routinely subject to active attacks by even low-power bad guys (say, bored students in a cybercafe).

When doing symmetric encryption, the proper way to add a MAC is to use a combined encryption-and-MAC mode such as GCM or EAX. These are modes which rely on a block cipher (typically AES). There are other such modes, but some are patented; these two are believed not to be.

Signatures (as opposed to MAC) are an altogether distinct matter, in particular in their relationship with confidentiality.


Can't Cloudflare sniff sensitive login data from its users' websites?

Now that Cloudflare has access to that data, do people worry about the "malicious Cloudflare employee who steals the login information"? Or do we just trust Cloudflare because it's "just too big to fail"

Yes, this is essentially boiling down to whom you trust. If you enter data into some website you trust the owners of the website to handle these data in a secure way and make sure that no unauthorized access is possible (but yes, there are lots of examples where sites fail to meet these expectations).

Similar the owners of the website need to trust their service since many such sites are located in some external data centers, might run in shared hosting or might be hosted in the cloud. This means that others outside the company would theoretically be able to get to the sensitive data.

And the same is true with CDN like Cloudflare or Akamai. It is not that they are too big too fail but they have simply too much reputation to lose.  While they are big they are not a monopoly. If it gets public that they don't meet the trust expectations then other services will be happy to point that out and fill the gap for switching customers. And compared to other services the switching costs from one CDN to the other are not that big.


Sniff network packets that don't talk to my computer?

You need to run in monitor mode; promiscuous mode doesn't always work with Wi-Fi adapters (and may not even be supported for Wi-Fi on some OSes or with some Wi-Fi adapters).

Whether Wireshark can do it by itself depends on the OS.  On OS X, it can; on Linux, it could, in theory, but for complicated reasons it can't, on most if not all distributions, in practice, so you need aircrack-ng's airmon-ng script to turn monitor mode on, and you can capture after that; on Windows, it can't do it at all except with an AirPcap adapter; on other OSes, maybe, maybe not.  See the Wireshark Wiki's page on WLAN capturing for details.


Who is responsible for leaking my personal information to companies?

It's not an unauthorised exchange unless you make your friends sign NDAs before giving them your contact details. Without that, there's an implicit authorisation for your friends to make reasonable use of the data you've given them, which includes uploading it to third-party websites. So it's your responsibility, for giving out data that you want to be held safe from disclosure without first getting an NDA in place. Treat your own confidential data in the same way as you would any other confidential data, and you won't have this problem.


Studies on Android users' attitude to security

I don't have any experience of any security related incidents personally but I have found some references to help you out a bit.

Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf
French cops cuff man over €500K Android Trojan scam
 http://www.theregister.co.uk/2012/10/19/french_android_trojan_suspect_arrested/
Lookout Security  <-- Perhaps the leaders in mobile security

https://www.lookout.com
Nice IEEE published paper <-- might need to be on a Uni network to gain access
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4768655&tag=1


Is it bad to use the same sequence of characters in each password?

It all depends on how much security you need.  The most secure case is to use very long, completely random passwords for every user, but practically speaking, that is also the least usable unless you use a password manager.  If you want to maintain the strongest possible security then that is what you should do, but for many people, that level of security simply isn't necessary.

On the far opposite side from that, there is using the same, short, easy to remember password everywhere.  This is super easy to use, but it isn't very secure because it can a) be guessed, b) if a user account is compromised in one place, even with the password properly protected, it will be fairly easy for the attacker to figure out what the password is and c) if it is used multiple places, there is a good chance that the attacker will then be able to access other accounts you have as well.

There are any number of hybrid ways you can work between these two extremes.  You can have multiple passwords for different security levels (separating basic forum users and news sites from personal data sites from banking and financial sites).  There can also be a system of making derived passwords that you can easily remember on some system, but hopefully the system isn't known by an attacker that might find one or two of your passwords, and thus a single compromise wouldn't impact your other accounts.

If there is a chance you may specifically be targeted, then this probably isn't a good idea since most systems you could come up with won't hold up very well against a determined and experienced attacker, but if you are just up against people trying to find accounts from a giant list, chances are pretty good even a simple system of differentiation of passwords will probably be sufficient to protect you.

Ultimately, it is up to you to decide what level of security you need and how much effort you are willing to go through to achieve that level of security.


A repeated visitation to a certain url of my app. Why?

So the IP address of the requestor belongs to "Rocket Science Group, LLC". Upon visiting their website, it looks like they develop applications as well. Now knowing who the requester is, does this shed some light on what the activity could be and if it is wanted? Here is a link to their website: http://rocketsciencegroup.com/


Security implications of forwarding ports 1-10000 on Airport Express?

Functionally, it would be as if the machine to which the ports were forwarded was directly connected to the Internet.  (At least for those ports.)

To the other machines on the network, the forwarding itself wouldn't be much of an issue, but if the forwarding target gets compromised, it could pose a threat to other machines on the network.

The first thing you should find out is what machine the ports were being forwarded to.  If that IP is not in use, then the forwarding should not be a significant issue.  If the target is patched with no services exposed to the Internet, then having ports forwarded is not likely to be a significant issue.  (Most clients that are compromised are done in a way that NAT won't protect you against anyway.)


Should you use a VPN while on the same network as the VPN server?

In a corporate environment using a VPN for employees while they are on-site opens up some interesting possibilities.  You might be able to organize them by group or role and assign them IPs from certain pools and then build network rules around those ranges.  When someone from the Finance department connects, you can only allow their traffic to resources they should be able to access.

A VPN across the internal network would also encrypt all of the traffic from your end-user systems to the VPN device.  If you had zero trust in your networking infrastructure (hubs and vulnerable switches where you thought people could be running tcpdump all day long) the VPN might mitigate that weakness (although, an attacker might be able to try all kinds of attacks to impersonate the VPN).


Client Side Encryption (CSE) across multiple clients

I am not sure if you want to only decrypt the files at the internal instance, or each client also has to be able to decrypt its own data.

Anyways, the solution is to use a hybrid encryption scheme with public keys.

Each client encrypts the data with a symmetric cipher like AES and a random key for each file. The random key is then encrypted with the public key of the internal instance. If the client also has to decrypt the file, the AES key is additionally encrypted with the public key of the client.

If you need to ensure authenticity, the file is also signed with the private key of the client.

You need, depending on your exact requirements, either one keypair for the internal instance or n+1 keypairs (internal instance and each client) for n clients.

One software which is able to do exactly what I described is the GNU Privacy Guard.


Hanky 웃 Panky brings up good points. However, I'd like to add to them:

You can mitigate damage by restricting connecting accounts by roles. Let's say you only allow searching on your website. Allowing only SELECT statements for that particular account will prevent anything else from running. This doesn't work if you have an account for each: SELECT, UPDATE, INSERT, DELETE, as an attacker could combine the privileges and cause serious damage.
You can also deny anyone except those with appropriate admin access to the website, whose login will likely be independent of the webhost. IP-based deny all, allow from , for example. Note that this won't completely protect you if you've been breached, nor will it protect you if your web host is the one accessing the database.

Only those with root/admin/shell access to your website can obtain the username and passwords, unless you improperly chmodded the files. If any of those are true, you have much bigger issues than having your MySQL user/pass known.


If desktop computers are within scope of your PCI boundary then they will have to be subject to the same controls as any other device in scope. This means a number of controls on the configuration, AV and malware protection, security policy (password management controls), etc. as well as processes around usage need to be considered. There is nothing specific that I have found about Windows 8 that means it can't form part of a PCI compliant solution.

Are you concerned about any specific control or process or any specific scanner result?

Remember that if a specific scan plugin fails against a device there is also opportunity to put in place compensating controls (though this is normally a last resort).


Is it possible for me to somehow verify that the PGP message blob I just generated contains what I intended for it to contain?

If you can not trust the machine you have PGP/GnuPG on and you think you might have malware on your system that has access to your Keys and Passphrase (if you signed the message) it's game over. There is no way to recover from that.

What you can do, however, is use PGP/GnuPGs method of adding multiple recipients.

gpg --encrypt --recipient alice@example.com \
--recipient bob@example.com doc.txt

and use your own identity as one of the recipients. This is popular with many email clients with PGP/GnuPG support, because it allows you to view your sent mail.

Since the same message is now encrypted for both recipients, you can veriy what you send before you send it.


Best practice for https Private Key Generation

As long as the machine in question has enough entropy to generate strongly random keys and nonces, that's totally correct. The key must never leave that server. Even more, if I were working on a critical application, I wouldn't even trust that machine and keep the key in a HSM. It might cost a lost, but it significantly enhances the security.

There is a broad spectrum of security practices, going from the best case above, to the worst possible situation, which appears to be your case. Either your colleague has a specific reason for doing so or he/she is putting the security of your applications at risk. Immediately confront him/her. If I were in charge, I would fire that "security" person at once.


Login ID should be considered public. So feel free to send it per email.


Will the sever send a 'Server Hello' if ciphers are not negotiated?

The server will respond with a handshake failure alert and will not send a Server Hello message.

This is clearly spelled out in the TLS 1.2 RFC


What would cause a server to only send over 1 SSL certificate to a client?

You have to configure your server to provide the chain certificate. How precisely to do this depends on your server.

For apache, you need to add to your config:

SSLCertificateChainFile /path/to/intermediate.crt

For IIS (and most other Windows-native stuff), you have to import the intermediate certificate into your server's "Intermediate Certification Authorities" certificate store.

For applications that don't support chain files in the configuration, you can append the intermediate certificates to your certificate file:

cat intermediate.crt >> mysite.com.pem

Be sure to only include the needed chain certificates and not the root certificate, as that would result in a "contains anchor" message. It would still work that way but it is not technically correct.


Is BitLocker on a virtual machine FIPS 140-2 security level 1 compliant?

There's an interesting discussion on this topic.  I would agree with this assessment that a virtual drive holding the encryption key would not qualify as FIPS 140-2 compliant.

  In the security policy, §2.3 describes the platforms on which the certification applies: it lists several versions of Windows, with no reference to any particular hardware. Then §6 describes usage requirements that must be met in order for the certificate to apply. One of the FIPS-compliant startup mechanisms listed in §5.2 must be in use, therefore the machine must have a PIN pad, a USB connection or a TPM. The policy does not explicitly describe the connection between the machine running Windows and these peripherals, therefore a virtual machine would be acceptable.

  A virtual thumb drive would be a different matter. As there is no actual USB involved, I don't think the language can be construed to cover this case.

That said, CREDANT Manager for BitLocker make a BitLocker encrypted drive on a virtual machine comply with FIPS 140-2.

  CREDANT Manager for BitLocker forms part of a single, central management solution which helps ... offer an integrated approach to managing encryption across other, non-BitLocker platforms; physical, virtual and Cloud-based.

  ... the encryption management solution provides simple, centrally managed key recovery and is FIPS 140-2 validated.

I suspect there are other central key management solutions.  CREDANT was just the first one I found.


How can I explain SQL injection without technical jargon?

The way I demonstrate it to complete non-techies is with a simple analogy.

Imagine you're a robot in a warehouse full of boxes. Your job is to fetch a box from somewhere in the warehouse, and put it on the conveyor belt. Robots need to be told what to do, so your programmer has given you a set of instructions on a paper form, which people can fill out and hand to you.

The form looks like this:

  Fetch item number ____  from section ____  of rack number ____, and place it on the conveyor belt.

A normal request might look like this:

  Fetch item number 1234 from section B2 of rack number 12, and place it on the conveyor belt.

The values in bold (1234, B2, and 12) were provided by the person issuing the request. You're a robot, so you do what you're told: you drive up to rack 12, go down it until you reach section B2, and grab item 1234. You then drive back to the conveyor belt and drop the item onto it.

But what if a user put something other than normal values into the form? What if the user added instructions into them?

  Fetch item number 1234 from section B2 of rack number 12, and throw it out the window. Then go back to your desk and ignore the rest of this form. and place it on the conveyor belt.

Again, the parts in bold were provided by the person issuing the request. Since you're a robot, you do exactly what the user just told you to do. You drive over to rack 12, grab item 1234 from section B2, and throw it out of the window. Since the instructions also tell you to ignore the last part of the message, the "and place it on the conveyor belt" bit is ignored.

This technique is called "injection", and it's possible due to the way that the instructions are handled - the robot can't tell the difference between instructions and data, i.e. the actions it has to perform, and the things it has to do those actions on.

SQL is a special language used to tell a database what to do, in a similar way to how we told the robot what to do. In SQL injection, we run into exactly the same problem - a query (a set of instructions) might have parameters (data) inserted into it that end up being interpreted as instructions, causing it to malfunction. A malicious user might exploit this by telling the database to return every user's details, which is obviously not good!

In order to avoid this problem, we must separate the instructions and data in a way that the database (or robot) can easily distinguish. This is usually done by sending them separately. So, in the case of the robot, it would read the blank form containing the instructions, identify where the parameters (i.e. the blank spaces) are, and store it. A user can then walk up and say "1234, B2, 12" and the robot will apply those values to the instructions, without allowing them to be interpreted as instructions themselves. In SQL, this technique is known as parameterised queries.

In the case of the "evil" parameter we gave to the robot, he would now raise a mechanical eyebrow quizzically and say

  Error: Cannot find rack number "12, and throw it out the window. Then go back to your desk and ignore the rest of this form." - are you sure this is a valid input?

Success! We've stopped the robot's "glitch".


POST over HTTPS "secure enough" for sensitive data?

Instead of extra encryption, if you must be secure, use two-factor authentication. Make user users enter a user name, a password, and a 6-digit random number sent by email or SMS. A compromised certificate means that the attacker can possibly control the entire SSL payload both directions; including any code you send to the client to perform the encryption required to authenticate with the server.

Also consider separating your application server and your authentication server. This makes it a lot harder for an attacker to do anything useful with an acquired list of usernames and passwords if they are not actually accepted by the application server; this is concept behind OAuth2. It is far easier to recover one server than it is to attack two servers (at least, in theory).


Is there a way to encrypt incoming data from Plaid and make it
  available to the user through a web UI, without me being able to
  decrypt it as the developer of the app?

Yes.  Encrypt it using the public key of the end user, and implement the client such that the private key - which is in their hands, and no one else's - decrypts the data for their consumption.

This requires a fatter client than simply using a web browser, but if you're implementing your own app, you can do that.  It also means you have to implement all your logic out at the endpoint, since the server is blinded to the meaning of all that data.

An example of a (multiplatform) application that uses this model is Keybase.  Not only do they allow the end user to have protected access to files that are stored in the cloud, they allow groups of users to share, with each other, access to files that traverse and are stored in the cloud but only decrypt-able by the right end users.

  Unfortunately private keys won't work since I would have to store them
  to encrypt the data coming in from Plaid.

Secret (symmetric) keys won't work for you for that reason.  Public (asymmetric) key pairs, where you encrypt using the public key and the user decrypts with their private key, will work.


Relating to Baron's answer, he stands corrected with supporting packet injections, but they also need to support monitor mode too. For example, when I run:

airmon-g start wlan0 - This will convert my wlan0 to mon0 or mon1 depending on the interface chipset. Inbuilt can work, but they're sometimes not as powerful as they need to be and again, some don't support the correct requirements.

  Usually the wireless adapter is unable to transmit in monitor mode and is restricted to a single wireless channel - source

To check if it supports monitoring mode, type iwconfig and you'll see wlan0 or something similar. If you have a pentesting distribution or the aircrack package with airodump etc. You can type airmon-ng start wlan0 which will place your adapter into monitor mode and changing the interface from wlan0 to mon0 or something similar.

Edit:

Adding some more info on the channel limitation, see here.


I am in the same situation as you, and here is how I understand the process:

The server sends the JWT token via Set-Cookie ... ; Secure ; HttpOnly. This will prevent Javascript on the client to read the JWT token, and hence it will prevent XSS attacks to steal the JWT token.
The server also sends a XSRF token that the Javascript on the client side can access, either in an additional header, in a client-side readable cookie, or as answer to the JWT token request. The client must then actively add this XSRF token to every request, for example as an additional header. The XSRF token is also part of the JWT token, so the server can verify that both match.

This prevents CSRF attacks, because while the CSRF attacker can cause the cookie with the JWT token to be sent along with a request, he cannot read the XSRF token, and therefore cannot add this to the request.
The refresh token works in the same way.

This does not prevent the scenario where a XSS attack executes requests by including the XSRF token himself. It only prevents an XSS attack from stealing the complete token, and using it somewhere else. However, given that XSS attacks can pretty much do anything client-side Javascript can, this is probably as far as one can go.

Protecting the access JWT token against theft via XSS isn't that important, however protecting the refresh JWT token against theft is extremely important. The access JWT token hopefully has a short expiration time, but a stolen refresh JWT token cannot be revoked, as the token is stateless, so it will grant the attacker unlimited access. One can still change the keys used to sign the JWT token, maken all JWT tokens invalid.

The hwole process also does not protect against any kind of MITM attack, so using https is important.

As the XSRF really can be anything, I don't see why one couldn't use the jti field that is already present. However, the extra effort on the client side to add this information to every request is crucial.


What prevents malicious servers from spoofing mail transfer agents and/or mail delivery agents?

Delivery from the MUA is usually done to the domain specific mail provider (MSA in your image). This communication is typically done either inside a companies protected network or to some external mail provider. Mail delivery inside the local network is usually  protected against DNS spoofing as long as it can be assumed that there is no attacker inside the local network or that he will not make itself easily visible with DNS spoofing. When using an external mail provider the connection is usually protected by TLS. TLS will protect against DNS spoofing and other traffic rerouting since the MUA will check the subject of the certificate and that it was issued by a trusted CA etc. TLS will also protect against sniffing and modifying the traffic even if the attacker manages to get in the path of mail delivery.

As for MTA/MSA to MTA/MDA communication: this happens on networks where DNS spoofing is not easy too, i.e. this is not on some public hotspot where an attacker could easily inject himself. Additionally DNSSec might be used although lots (if not most) DNS MX/A/AAAA records are currently not protected by DNSSec. But using DNS spoofing to target a specific mail is impossible due to all the caching of DNS. Using it to target all mails to a specific domain is hard too since these might come from various sources which means DNS spoofing might need to be done in various places which might make the attack too visible. The same is true for other ways to reroute the traffic, like BGP hijacking. If the attacker still manages to actively get in the path of the mail delivery though he can likely sniff and modify the traffic since usually there is no TLS enforced between MTA or that the MTA don't properly check the certificates.

None of this actually makes attacks really impossible, it only makes it less likely in most cases. Well-equipped attackers (like governments) will likely be able to mount attacks especially against less protected domains. They might not necessarily attack delivery between MTA/MSA/MDA though since such attacks are more visible to others. Instead they might do a more targeted and less visible attack directly against the victims MDA or the victims mailboxes. The latter is often done using phishing mails to get the users mail account credentials or by delivering malware to attack the victims computer and thus get access to the mails too.


I've had this issue before, with another e-mail provider. In my case, someone was able to obtain my e-mail address, but not my password.
Then, my e-mail address was used as the "reply-to" or the "sent-from" address on a spam e-mail.

It is annoying, but you're e-mail itself is probably safe. (TFA helps).

Example for clarity:
Through whatever means, I notice that a valid e-mail address is Mycroft@googlemail.com.
Now, I can authenticate to another mail server, say postoffice.com. I can then use a sendmail program that does something like this:
to: JoeBloggs@aol.com
from: Mycroft@googlemail.com
Subject: Best Diet Program Ever!!
Body: blah, blah, blah.
For more info, click here!
EOT

You will then get the mailer-daemon message, and I have not compromised your e-mail, but I have compromised your email ADDRESS.


Password for embedded devices in automatic deployment

In beginning I should mention password is not good security solution.
As per your explanation you are want to access device some times, and no user is login to that particular device.
Your password or security management should be based on data you are processing or storing on device. In addition to that you might have legal bindings as well.
You can use synchronous password. Google authenticator app use same technology. If you need highly secured password, generate dynamic password on your server and synchronize time to time. Time duration can be vary 1 minute to 1 hour/day. Then even password is disclose after specific time period it will be disabled. This is required to have proper time synchronization mechanism between server and client.
Asynchronous password management also possible for device authentication, This is not time based and purely based on algorithm. Until password is used, it will be active. Password can generate with specific hardware devices. It does not require connectivity between devices and hardware token.
But both of these technologies are using secondary factory of multi-factor authentication. But i think this will be okay.


OCSP multi stapling : how to enable it? Simple stapling is OK

To be clear, the CA (or its delegate) must support (plain) OCSP, but the server must support stapling, either single or multi (aka v2).
From http://httpd.apache.org/docs/2.4/mod/mod_ssl.html at SSLUseStapling, with emphasis added:

This option enables OCSP stapling, as defined by the "Certificate Status Request" TLS extension specified in RFC 6066. If enabled (and requested by the client), mod_ssl will include an OCSP response for its own certificate in the TLS handshake. Configuring an SSLStaplingCache is a prerequisite for enabling OCSP stapling.
OCSP stapling relieves the client of querying the OCSP responder on its own, but it should be noted that with the RFC 6066 specification, the server's CertificateStatus reply may only include an OCSP response for a single cert. For server certificates with intermediate CA certificates in their chain (the typical case nowadays), stapling in its current implementation therefore only partially achieves the stated goal of "saving roundtrips and resources" - see also RFC 6961 (TLS Multiple Certificate Status Extension).

(Although this is ambiguously worded, 'may only include [one]' for 6066 means 'it is only able/allowed to include one' not 'it is possible it only includes one'.)
So, it looks like you can't. Although I'm pretty sure mod_ssl is open-source, so you could implement a change to it yourself if you really want.


Why do phishing sites use images instead of just copying the HTML?

Using the real code from the website may increase the ability for automated detection to find and identify the phishing site. If the victim site has some specific text phrase, this could be used in searches across the web to identify potential phishing sites. Crawlers and other bots may also store complete HTML and could match against structural items. With images you do join all of the images and then do OCR, which would be very time consuming and hard to narrow down the list of potential sites imitating you.

Phishing site operators may also choose to cut up the screenshot images differently on each site and use different file names so that each site attacking the same victim is harder to identify.

Also, it may be possible to utilize CSS for the images and layout to further reduce the amount of available code and content to match against.

Remember, Phishers aren't trying to fool everyone. They less credible the site, they know the ones who fall for the scam are less likely to notice and report (Check out this Microsoft Research Report).


What are the most common infection vectors for personal computers?

The Verizon Data Breaches report is useful here ( http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf)

I can't view it right now but I seem to recall that the top routes in were social engineering, flash, document macros and pdf functionality.

Very few these days are in the OS.


How can a OAuth2 resource server relate an access token to the user that authorized it to prevent unauthorized access to other user resources?

oAuth 2.0 does not have a build in mechanism to do this, however there are a few scheme's you could employ to make this work.

use an Authentication layer on top off oAuth (like openID Connect) to retrieve the user information you need
Add a scope per user details to access said user details and only grant that scope for that user. Just be aware of the information leaks that can cause.
Use the Authorization provider as gatekeeper and have it provide the requested details for that specific user not the resource server where the pictures are actually being stored. sort of a cop out but would also work.


"Malformed URL" string when trying to inject SQL

No, it's not an indication of a successful SQL injection. Literally the error means that your request doesn't conform to the Uniform Resource Identifier (URI) standard syntax (RFC 3986, 3.):

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

It's unclear what is giving the error.

If it's your browser, the request doesn't even reach the server. In HTTP(S) the server sees the authority part on the Host: header and the path and query parts in the (GET / POST) request.
If the request actually goes to the server and the server is unable to handle it, the server would probably response with the 400 Bad Request error, instead.
Some web application firewall (WAF) could respond with a Malformed URL error, but it's more likely to give 403 Forbidden without revealing the attacker what's the exact security rule that was fired.
You could even be behind a proxy / NGFW / UTM that blocks malformed request from leaving your network. Such an appliance would probably show the error directly to you.

In any case this doesn't look like you have succeed at all. Also, organizations having bug bounty programs have probably already fixed the most obvious vulnerabilities. You would need to come up with something a lot more sophisticated. Frankly, if you were capable of that, you wouldn't be asking this question here.


Why do credit cards have chips, if I can purchase online without the chip being read?

With cardholder-not-present transactions, if the transaction turns out to be fraudulent, the retailer has to refund the money. With Chip and PIN, the retailer gets to keep the money, and either the bank or the cardholder bears the loss of the fraudulent transaction, depending on whether the cardholder has told anyone else their PIN or not. So retailers want to use Chip and PIN where they can, to protect themselves against fraud. Obviously, they can't use it for online transactions, so they have to accept the risk for those transactions.


Does "late launch"/"dynamic chain of trust" allow remote attestation?

Does "dynamic chain of trust" support remote attestation?

When a dynamic launch is used on an area of memory, specific PCR indexes in the TPM are used to used to record the state of that software. If these PCR indexes are included in the attestation request by the challenger, then that software would be attested to in the response. These PCR indexes are 17-22, as specified in the TCG's PCClient inplementation for BIOS spec, see page 30.

  Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

Intel's implementation of TXT support on Linux, tboot, has missed a detail, which they will hopefully fix soon. tboot doesn't expose the event log, which would show what software was extended into TPM PCRs as part of the TXT launch. This is a requirement for a remote challeneger to attest against dynamic launch PCRs, so at the moment, support isn't fully there. You can technically find the event log, but its not available in a TCG standard format, so all the common trusted computing tools that'd be used to parse it will not work ATM.


Router DNS getting automatically changed

That's likely caused by a classic Cross-Site Request Forgery attack from back in the day. See the image below that explains the attack. Some countermeasures:

Change the default LAN network IPv4 range and make sure the router IP is NOT 192.168.0.1 or 192.168.1.1 - make it a seemingly random one, e.g. 192.168.X.21 or something of that sort (lol @ security by obscurity).
Change your router to use an open source/third-party firmware - Tomato, OpenWRT or DD-WRT are all a great option.
If you can't use a third party firmware, get an updated version from the router manufacturer.

The problem is not related to your router being remotely accessed from the Internet (via telnet or HTTP), it's a deflection via your own web browser.


How to reliably identify a certificate as root certificate in a chain

Simply check if Issuer and Subject fields for equality. If they are equal, the certificate is self-signed and represents root certificate. Otherwise, the certificate is intermediate certificate. Of course, public key in the root certificate must validate its own signature.

Edit to follow up OP edit:

  The question is which certificate attributes or extensions I can use in which fashion to reliably identify a root CA certificate in a given chain.

you must check that isCA attribute of Basic Constraints certificate extension is set to True in all CA certificates. And this extension SHALL be marked critical.

  What happens if I create a root certificate and a derived intermediate CA certificate and, in the latter, just choose the subject equal to the issuer?

there are two outcomes:

  The authority key identifier may well correctly point to the key identifier of the root CA

you will create a loop in the chain which is detected by most certificate chaining engines. Otherwise, the certificate will not be a part of your chain with root and intermediate certificate.


Can the FiddlerCore library be used for Malware (e.g. MitM attacks)?

I think you may misunderstand the difference between malware and MitM attack tools. The former runs on the victim, the latter runs on the attacker.

If (through other means) you were able to get the victim's HTTP requests routed to you instead of their intended destination, sure. But there are other better tools that both perform the full process, not just the modifying you said was capable. So what's stopping people? Better alternatives.

The morality of the issue is a separate question, part of a an existing heated debate. My opinion? Even the tools that automate the full process are ethical in my opinion. They can/are used for testing and educational purposes. Furthermore, a lack of them will not deter determined attackers from creating their own. Believe me, it's a constant game of catchup and libraries like this aren't fueling the threat. Please though, that debate can occur elsewhere.


How risky would it be to run a Linux kernel without Spectre and Meltdown patches on a regular desktop system?

Simply put: You would undo a lot of mitigations.

Whenever a vulnerability like Spectre or Meltdown comes along, people run to see who should deploy the patch. Browser vendors (quite rightfully so), claim that fixing CPU bugs is not something they are responsible for. It would make sense to patch it on an OS level, as that would mean not every application would have to take care of it themselves.

As a result, if you would disable all these mitigations, you become potentially vulnerable to those attacks.

How unsafe would this make you?

Depending on your desired level of paranoia, ranging from "Not at all" to "They've probably overtaken my CPU already". To answer more seriously, it is entirely possible to exploit this using JavaScript. It is difficult to say if this has been exploited in the wild, and if so, if it was successful. I personally would say it's not on the top of my threat list, but I also would not want to intentionally disable security features.

So the answer is basically the same as with disabling any other security features: Proceed at your own risk.


How to not store the card during 3D Secure authentication, to be PCI DSS compliant?

Typically payment APIs fall into 3 categories:

payment page hosted on the merchant side and submitted to the merchant
payment page hosted on the merchant side and only card data submitted to the payment provider (typically via a JavaScript SDK)
payment page hosted on the payment provider side and submitted to the payment provider, the merchant receives a notification upon successful authorization

Assuming the payment provider didn't screw something up big-time you should be completely out of PCI DSS scope by options 2 & 3.

With option 2 you are not in PCI DSS scope, you never use credit card data, but a permanent or temporary token assigned to the transaction (like e4baf901-252b-4818-b826-7f89cad884db) by the JavaScript SDK of the payment processor. Other than this, the 3ds workflow is exactly like option 1, it's just that your API requests have a pan_token and not a pan attribute. See hosted fields API on Braintree as an example https://developers.braintreepayments.com/start/hello-client/javascript/v3

With option 3 you are not in PCI DSS scope, you don't really do anything, you just redirect your client to the payment provider or open the payment provider's page in an iframe or something, here's an example of this kind of API: https://ipgtest.webteh.hr/en/documentation/form

With option 1

That's a different story, yes, you are in PCI DSS scope, yes you need to have a valid certificate, depending on the region perform PEN tests, have a secured organization and all other "bad stuff", password policies, jump host for connection, secured (and preferably segmented) network, make sure the logs show nothing, "deny all" network configs, do audits yearly etc etc etc.

If you go down this road (and I really don't understand why you should, please, don't) at least you can avoid having an HSM and worry about encryption keys etc - meaning you should not store PCI DSS data to a hard drive.

Typically the simplest solution to avoid this is to store the credit card data in memcache with an expiration policy of 1h or less (15 minutes works for all implementations I did so far). The trick is to not write it on the disk (that's why not redis in most implementations for example), but a memory store like memcache is fair game. Just make sure that the access keys are something big and secure, like an uuid (ie e4baf901-252b-4818-b826-7f89cad884db).

It was not always like this in practice...

Historically, the payment companies have been very lax about merchant PCI DSS compliance, the only practical difference between "database full of PANs" and "no PANs ever touching the system" was "how many questions your self-assessment questionnaire has" (PCI DSS SAQ for merchants).

Only in very special cases when a merchant was identified as common point of sale for stolen cards was the merchant forced, very very reluctantly and with a lot of "understanding" by the credit card companies to undergo PCI DSS lvl2/lvl1 compliance audit.

This is however changing due to a series of breaches, and at least in some regions (like SEE Europe), the payment companies are now insisting on a migration away from option 1 to all merchants that do not have a full PCI DSS compliance certificate (not just an 'X' marking exercise in a SAQ questionnaire).


Can I get malware plugging iPhone into portable charger?

There are articles warning against using public charging stations because there is a trust given to physically connected systems on the iPhone. So yes, the risk is not zero.

The question I'd ask myself in this specific case though is "Would a charger from a reputable org by likely to contain such an exploit system?"

I'd personally wager the odds are low and would be OK using such a charger on a personal phone, but if this were a work device with access to sensitive information I'd probably be more careful.

You could also keep your ear to the ground, so to speak, for a period of time and see if any reports come up regarding these chargers resulting in exploits, and if you haven't heard any such within a few months, the odds are even better.


Anyone using Asirra in production? Are there similar alternatives?

Not relating specifically to Asirra, but wrt CAPTCHA in general, I will elaborate on @Graham's point and direct you to the following links:

"Has reCaptcha been cracked / hacked / OCR'd / defeated / broken?" on SO
My answer to "Practical non-image based CAPTCHA approaches?" on SO
Presentation I gave on this topic at OWASP in 2008
Best idea yet (obligatory XKCD)
RSnake's opinion of another "new" type of CAPTCHA (but mostly still applies to Asirra)
Bruce Schneier, but mostly the comments

In case you're lazy here are the highlights...
The 3 general ways of breaking CAPTCHAs are:

Broken implementation (e.g. wrong configuration, wrong settings, static images, exposing the answer, etc) - but probably does not apply to Asirra, unless its configuration-dependant
Inherent reverse-computability - If you can build a program to blur something that is still readable, I can build one to unblur it. I.e OCR is pretty darn good, at least if the image is readable by a human.
Putting a human in the mix, either by:

CAPTCHA farms: paying someone small amount of money, there is a MARKET for this: I've seen advertised on Ebay packages of 1000 CAPTCHAs "solved" for 4$, with a matching reliability % SLA
CAPTCHA Proxies, e.g. you can access pr0n if you solve this CAPTCHA... or even make a game out of it.

To sum up (as I've often done on this topic):

  CAPTCHA tries to solve the wrong problem, and it does it badly: even if it worked perfectly, the problem is not "I want to identify who is a computer and who is a human and allow only humans to use my site however they want", but rather "I want to prevent misuse and flooding on my site".
  We shouldnt be trying to turing-test the users, we should be limiting what they could do.

Or even better:

  Authentication (or identification) is a poor replacement for authorization.


Possible number of collisions in a hashing function with constant message size

Say I am using SHA-1 which outputs 160 characters string, and my input string is 161 characters, so does that mean each of my 161 character message has at most unlimited collisions and at least 10 collisions/pre-images each of 161 characters. Is my understanding correct?

No.

First it cannot have unlimited collisions since the number of messages with 161 characters is limited itself. This means even for the worst hash algorithm which maps everything to a constant hash value there will be only 256^161 images mapping to the same hash value (assuming character is an octet).

Also there does not need to be any collisions at all for a given hash value and it is not even guaranteed there is one image within your set for each possible hash value.

What you can say is that you will get on average 10 images mapping to the same hash value. And with a good cryptographic hash like SHA-1 you will also get only a small deviation from this average.


How to prevent phishing mails from being successful?

There is no one answer to this, a number of things can help, spam filters will help, but A.They won't catch everything and B. They might filter legit email (especially if you have it set to be very aggressive.) It is really a trade off.

When explaining to users the best thing is general user education.
Explain the risks, explain what to look out for and include them in the process by giving them stakeholdership over the issue, it is their problem as much as it is the organisation's problem. Explain to them that everyone has a role to play when it comes to security.

I have dealt with many diverse user groups over the last few years and have had to relay a number of IT change projects to them and making them feel part of the process has consistently been key to getting them to do is needed/wanted. The standard advice would be as follows;

Check the domain in the email address is correct. For example if you
get an email from someone claiming to be from the Acme Bank make sure the
domain part is consistent with other emails you have from them; i.e
manager@acmebonk.com is the sender address but Acme Banks email is @acmebank.com.
If you haven't had any other mail from them, then why are you getting
email now? Do you even have a service with them, if not then
something may be wrong.
Check the URL's in the mail are legit, visit the website in a browser
and confirm the domain is the same as the links.
Any attachments can be risky, it doesn't matter what they are, there
is a risk and an attack vector in anything that can be attached to an
email.


Is there a security difference between remote desktop or VPN?

The security provided by Remote Desktop applications are often not top-notch, and can be broken with a little persistence.

VPN offers and additional level of security, as data traveling to the private network is encrypted before it hits the Internet, and decrypted once it reaches the private network. This additional level of security may be a plus for most, but this type of connection suffers from slower speeds than a non-encrypted method.


Your best bet is to read the mod_rewrite documentation which explains how rewrite works. From that page:

  Summary The mod_rewrite module uses a rule-based rewriting engine,
  based on a PCRE regular-expression parser, to rewrite requested URLs
  on the fly. By default, mod_rewrite maps a URL to a filesystem path.
  However, it can also be used to redirect one URL to another URL, or to
  invoke an internal proxy fetch.

  mod_rewrite provides a flexible and powerful way to manipulate URLs
  using an unlimited number of rules. Each rule can have an unlimited
  number of attached rule conditions, to allow you to rewrite URL based
  on server variables, environment variables, HTTP headers, or time
  stamps.

  mod_rewrite operates on the full URL path, including the path-info
  section. A rewrite rule can be invoked in httpd.conf or in .htaccess.
  The path generated by a rewrite rule can include a query string, or
  can lead to internal sub-processing, external request redirection, or
  internal proxy throughput.

So the path is whatever you want it to be.


Is a "SAS 70 Type II" audited host SEC compliant?

SAS-70 (including Type II) is not a certification standard. It's a statement of what you claim to do, coupled with an attestation by an auditor that you do what you say. You have incredibly wide flexibility to define exactly what it is that you do, so no two SAS-70's are exactly alike. I don't know which SEC rules you're referring to, but SAS-70's are in any case not a precisely defined certification, so they're hard to compare with anything else.


Different SSL/TLS versions on subdomains using a wildcard certificate

That is absolutely possible.

For both Apache and nginx, you can define TLS options per virtual-host.

Taking nginx as an example, every block like the following (taken from Mozilla's TLS config generator can specify its own TLS options and preferences:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    resolver <IP DNS resolver>;

    ....
}

You can use any (hopefully valid) cert within the block, including re-using a cert between subdomains.
The TLS settings are distinct from the details of the certificate and key used.

However, although you can do this, it may make sense to consider, at least, using different certificates - it would allow you to revoke certificates for different parts of your site in case of compromise.

Using the wildcard cert, if that key is compromised, your whole site will be offline until you can get a new cert.
If you have per domain certs, and possibly a wildcard as a fallback, you make yourself better able to deal with that situation without necessarily affecting your entire service.


Why does this cause XSS? And how can I prevent it?

Escaping is context sensitive. You are escaping for HTML, but are using the variable in Javascript. Instead, correctly encode for JavaScript using json_encode:

printf('output = %s;', json_encode($_GET['q']));

Also, you are using the html function even though you don't seem to want HTML at all. What you probably want is the text function:

$("#output").text(output);


Can my school see what I'm doing on my laptop at home?

If you are using the schools WiFi to be online, then yes, everything you do can be monitored. Being a school, monitoring might not be too sophisticated, but potentially, it could.

If you are online via your internet provider at home, when you use your browser to log into a website, that website can monitor everything you do on it, but not more. Not another browser tab, not another browser altogether. Again, more sophisticated attacks exist, but they are certainly not used by your school.

A whole different thing is software installed on your laptop. This could be a VPN, proxy or any kind of monitoring software. Once locally installed, there is virtually nothing it cannot do. But software cannot be installed without you knowledge or consent (again... more sophisticated attacks exist, but are certainly not used to spy on school kids). However, whether you gave consent and installed something or let your laptop be handled by school personal unsupervised so you aren't sure that nothing was installed locally, only you can know.

To summarize:

If you are just using a web interface, like opening their webpage and
interacting with it, you are safe. At least from your school. Real
criminals are a different matter.
If you installed an actual program on your computer, then yes, they
could be spying on you. Technically. Whether they actually do is a
guess at best.


What value security wise, if any, does a digital handwritten signature have?

A signature is gold standard for authenticating paperwork.   Really I see this is an evolutionary artifact of progress technology.  For so many years we didn't have anything better,  and so it has been "grandfathered in".

I have heard of credit card companies performing automated analysis on the transaction and signature to see if it is a fraudulent purchase, but this is a very difficult problem to automate.

Personally I think signatures are nearly useless.  Perhaps they are most useful as evidence to be used in court.   If you clone a credit card,  the only evidence of the transaction is a grainy security camera,  and a signature of the transaction.


Does SMS flood cause denial of service even when "blocked"?

There are different kinds of blocking. The DoS you describe is merely a UI-based problem.

If blocked from the SMS app, then the incoming SMS is ignored and not displayed. This happens client-side. Which means there might be congestion in the network, but SMS is not meant to have high QoS, so you might never notice a problem. But it does solve the UI-based 'DoS' problem. Other SMSs from other numbers would never be affected anyway at the network level.

If reported to your carrier, then the blocking happens at the network level.

SMS flooding is different from IP network based flooding. SMS clients do not have direct access to the network, they are clients of the network, so that regulates a lot.


Is this verbose error message on the DOT website a security issue?

DOT's backend Oracle database is down due to ORA-27101.

ORA-27101 has a nice explanation here with a useful reader comment stating that it happened to them because the Windows Event log was full.

From the output, you can learn that they have Oracle, Java JDBC, Drupal, ColdFusion. You also see some SQL code. With that knowledge you can start digging for vulnerabilities in those products/technologies.

The output mostly means that the DOT Database Administrator will have a hot day and that the page should be back soon. Feel free to notify the administrator as it says on the page.


You first need to identify the backup solution used to create the file. Based on the .SQB extension, I suspect it is Red Gate, which based on this looks to be using AES 128 or 256. Searching the non-dark net I did not find any clear documentation for recovering a lost password. Assuming you have a bona fide reason for trying to crack the file, your best bet is to contact Red Gate directly.


No, iphone is not secured against this. It is a fundamental flaw in the WiFi protocol that this can happen. You need to be able to deauth clients before they are properly authenticated for other reasons, that is why this has to happen in plain text. Most likely you encountered one of the following ( from the aircrack documentation):

-Wireless cards work in particular modes such b, g, n and so on. If your card is in a different mode then the client card there is good chance that the client will not be able to correctly receive your transmission. See the previous item for confirming the client received the packet.

-Some clients ignore broadcast deauthentications. If this is the case, you will need to send a deauthentication directed at the particular client.

-Clients may reconnect too fast for you to see that they had been disconnected. If you do a full packet capture, you will be able to look for the reassociation packets in the capture to confirm deauthentication worked


How to use 'key material' so that multiple people can access protected files?

These are different security levels and they need different solutions:

Encrypting file ensures that anyone - without the proper key - could steal it but not read it.
Having a bunch of users to access some files with some credentials is a different matter.

If a user can access the plaintext version of a file then it does not matter if that file was ever encrypted as your system (and file encryption) is transparent to the user. When she logs in, she sees all the files she has access to, and she won't even know if those files are encrypted or not.

A linux system can provide everything you need here. Create different users, even set them up to log in with certificate then allow them to access files with proper user/group rights.
If a user should be able to upload encrypted files then create an RSA keypair, and distribute the server's public key to the users. With that key they can encrypt a file, and it can be decrypted on the server side.


Is there a way to guarantee removal of data after closing Facebook / Gmail / Dropbox account?

It is almost certain that whatever you do, your data will not be irrevocably destroyed.

Even if the organisation you trusted with your personal data had the best of intentions it would be an enormous effort to really physically delete all of your data from all the places it will have been duplicated to, including backups and SSD spare sectors. No organization can economically justify that effort for an account you didn't pay anything for to begin with, so that will not happen. The best you can hope for is that they will actually delete the data on the OS or DBMS level, and the remnants on the physical media will later be overwritten when the physical media location happens to be reused.

But even that is far from certain. Your data may already have been incorporated in other databases as consented by you by clicking on the Accept button when you signed up, and remain there even if your account is destroyed. The organization may be under a (possibly secret) obligation from the authorities to preserve deleted accounts for legal investigation or information gathering by intelligence agencies. It may have a policy of keeping the data from deleted accounts for a few days, weeks, months, or years just in case it'll be needed again. You have no way of knowing. More importantly, you have no way of verifying what they have done. You can only trust and hope.


How does a Certificate Private Key get transferred on import / export?

One of the important detail that I discovered about exporting and importing private keys from a Windows Server Certificate Authority scenario is that it is important that the certificate request is made on the same machine where you will be importing the request. This is why there were some instances where after importing the certificate, the private key is not present. This is common since I was playing around with a stand alone server.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/66f1181b-7a51-4943-949e-933b94b5f712/how-do-i-create-certificate-w-private-key-with-my-standalone-ca?forum=winserversecurity

I have found some documentation regarding key archival and retrieval but is only relevant if you are using an enterprise CA.

https://technet.microsoft.com/en-us/library/cc781351(v=ws.10).aspx


The problem is the \x0b character in your shellcode. It is a whitespace character (VT, Vertical Tab) and scanf stops reading at whitespace characters.
You may replace \xb0\x0b by \xb0\x08\x40\x40\x40 which contains no whitespace characters.
b0 0b                   mov    al,0xb

is equivalent to
b0 08                   mov    al,0x8
40                      inc    eax
40                      inc    eax
40                      inc    eax

There may exist shorter solutions.


If ssl certs authenticate the servers ip address, how come I can't find a whitelisted ip address in any secure certs or am i looking in wrong place?

One of the main benefits of ssl/https is the verification of the ip address of the server in question.

I think there is a misunderstanding.

SSL as commonly used does not verify the IP address. Instead it gets verified that the name in certificates subject matches the expected domain (not IP). This check protects against man in the middle attacks where the attacker tries to intercept the traffic by using a publicly trusted certificate issued for a different domain.

Thus, HTTPS does not validate that the IP is correct. But it validates that it is connected to the expected server, no matter what the IP was.
This way HTTPS protects against IP spoofing attacks - and this is maybe where you got the idea from that HTTPS checks the IP address. For more information on this see Preventing a spoofing man in the middle attack?
.


Can't see ARP poisoning packets on Wireshark and Scapy

Yes, you are correct.

You will only be able to see ARP traffic sent to you or broadcast to FF:FF:FF:FF:FF:FF.

If you want to see ARP traffic over the whole network then this depends on the network architecture. Wireshark shows some ideas on how this could be achieved such as MiTM or using a hub.

If capturing WiFi traffic, your wireless adapter could be put into monitor mode where it would then capture all wireless traffic nearby.


How am I supposed to use a revocation certificate, and can there be multiple revocation certificates for the same private key?

You use the revocation certificate, which gets generated by GPG earlier, to prove your intention to revoke the certificate

What exactly I am gonna do with my revocation certificate?

For instance, send an e-mail to all my acquaintances saying "Look, private key compromised, here is the revocation certificate?" (Why not just "Look, private key compromised."?)

Scenario: you lost your key. If an attacker tells acquaintancies "Look, I lost the key" unsigned, how can the recipient attest the authenticity? You and the attacker can't sign messages. Certificate revocation prevents DoS in this case
Scenario: the key is compromised. Both you and the attacker can sign messages and send revocation certificates. Because of this, it makes no sense to send an email "Look, my key was compromised. Here is the new certificate" because both you and the attacker can both sign messages and revocations. As soon as you warn your acquaintances, you must renegotiate a certificate out of band.

If I re-run the same command in GnuPG, will I get a different revocation certificate?

I don't have this information but I can guess-answer. The two revocation certificates may or may not be binary equal (try it yourself) as soon as they store some variable information like timestamp.
But in general the revocation certificate must be bound to the public key, which is the only information the acquaintances can know, so in general it should be the same no matter.


So I am confused about how server knows how many time it have to decode URL

Always only once. And this is true for other encodings too, i.e. binary data in mails are encoded once with base64 or quoted-printable, unicode is encoded once with utf-8, HTML encoding is applied once for characters like < etc in HTML etc.


Is it OK to do a security testing in parallel with a QA testing?

I currently work as a developer, with some responsibility for sprint planning etc. so my answer is based mostly from a 'how should testing be accounted for' approach. I'm going to talk about agile here, but the same principal applies.

I can't see anything wrong in principal with testing in parallel to QA, assuming that it's understood that anything which fails QA will need re-testing.

Assuming the business assigns estimates to work (think agile development), dev time, QA time and security testing time should be added together to give the total estimated time for a task to be completed. Without going into too much depth on agile development, the sprint is made up of a number of tasks (cards), which the total estimate for fits into the sprint length.

Once a card is complete, it goes to QA and for security testing. If either of those two steps fail, it will go back in for rework etc.

Now, in an ideal world, all the cards will pass QA and security testing. What actually happens is some cards pass and some will fail (either at QA or security testing). Assuming the business doesn't turn around and just accept the risk, there will be some rework and the card should go back to QA and security.

By running your testing in parallel, you should save some time in the sprint. When cards fail QA, the business needs to understand/accept that the card will require re-testing from QA and security. You may end up spending the full estimated time re-testing, or less/more time. That time then affects the sprint and the release date.

In order to argue either side, you should look at how much rework you usually get. If most of your cards fail QA, then it make sense that you do your security testing once QA has signed off. If most of your cards pass QA, then it makes sense to run your testing in parallel.

I've based this answer off agile, where everything should have an estimate etc. The same principle applies regardless, each stage of development will have a time cost associated with it, even if its not written down anywhere.

My suggestion would be to look at how many cards usually fail QA and work out if it's beneficial to run testing in parallel or not.


How do I check if a gmail/gtalk SSL certificate is valid?

The message you quote means: "I wanted to talk to a server called talk.google.com, but what responded there seems to use a certificate which has the name gmail.com in it, and not talk.google.com". This means that either of these is true:

some ill-intentioned third party is actively redirecting your connection to the wrong server, possibly by DNS poisoning;
some mishap at your ISP implied a bad DNS configuration which emulates the effect of DNS poisoning, redirecting your connection attempt to the wrong server;
Google does not know how to do SSL;
there is something fishy in your Pidgin configuration.

From here, connecting to port 443 on talk.google.com results in a server certificate which includes the name: subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=talk.google.com, which is correct.

Note that Google is known to play tricks with the DNS. From my home machine, talk.google.com is resolved to an alias to talk.l.google.com, which has IP 74.125.113.125. From another machine on another continent, talk.google.com is resolved to an alias to talk.l.google.com, which this time has IP 209.85.147.125. There is obviously some sort of worldwide load-balancing in action here.

Bottom-line: you cannot check "by yourself" whether a certificate is good or not, save perhaps by phoning the Google headquarters and having them spell out the certificate fingerprint (which they might agree to; they are rumoured to value such kind of humour). Actually, the message you get is a rather definite indication that you do not get the right certificate, so you'd better use the message as a symptom and investigate if you indeed connect to the right server. I suggest trying Wireshark to see what server Pidgin is actually contacting, and what happens at the SSL level.


"geolocation can be unsafe" eslint scan-js rule

According to the Mozilla documentation and caniuse.com, some browsers will allow geolocation to be served over HTTP, in which case the usual risks of a MITM apply.

This is a guess on my part, but if an attacker can uncover your physical location, they could exploit it in any of the following ways:

Find your home/work addresses, and use that for any of the following:

knowing when it's safer to break in or when's the best time to swat you.
framing you for possessing illicit material (as (nearly) happened to Brian Krebs).
covering their tracks.

Use it to create more targeted phishing attempts (we know that Pilib Uí Rólaun regularly goes to Bank A on the main street of Ballycac - so, he's more likely to fall for a request to log into this than for Bank B).
Sell it to a third party that might find it useful (for any of the above reasons).


Is there a public database of mutex names that are associated with malware?

ThreatExpert reports include mutex names, when applicable (see e.g. at the end of this report). I am not sure they provide the data in a convenient format, though.