How can you fake geolocation in Firefox?

If you want to spoof your location for the HTML5 Geolocation API you can follow these steps:

Go to about:config.
Type in geo.provider.network.url [it was geo.wifi.uri in previous versions]
Change the value to something like this:
data:application/json,{"location": {"lat": 40.7590, "lng": -73.9845}, "accuracy": 27000.0}

(The lat and lng values determine the latitude and longitude of your location.)

Congratulations, you're now on Times Square! (You can test the result here.)

Note that if you want to prevent websites from deriving the location from your IP address you can't do that on the application layer - the only way will be a proxy.


apache http https redirect server still listenting on port 80

It depends on the specific setup if this is a security concern or not. If any access to port 80 only results in a plain redirect to the https:// site on port 443 with no cookies set (or at least no sensitive cookies) then there should be no security concern. If instead it is possible to reach different actions by accessing some page within the plain http:// site  or if the redirect to https:// already sets a sensitive session cookie or similar then there is a problem since this cookie is transferred unprotected.


The main things a cloud data center could inject into its hardware

Amazon can do absolutely anything they want with custom hardware.  Make copies of your passwords before you get a chance to hash them?  Sure.  Send every credit-card number they see to the Russian Mafia?  Sure.  Corrupt the results of your scientific-computing effort, then publish a paper with the real results before you get a chance?  Sure.  It's all a question of how much effort they're willing to put into it.

From the 10 Immutable Laws of Security:

  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

With cloud computing, it was never your computer to begin with.


Securely storing clear passwords where one-way encryption/hashing is not an option

Your idea for a separate server is good. You need to change the interface between the web app and the password database a little. The password database needs to support two operations:

Set password for user
Get session for user

The password database NEVER reveals passwords. To fetch a session, it connects to directly to Apple, logs in using the credentials it has stored, then returns the session ID to the web application.


What's the risk in downloading a .pdf from a phishing email?

Check out this thread on superuser, which explains how PDFs can do damage:

  PDF files are both complex (so easy to have bugs in parsing code that can be used for malware) and have Javascript, which can be used for nefarious purposes as well.

A PDF exploit is one way in which these file types can be dangerous:

  Earlier this month, Belgian researcher Didier Stevens demonstrated how malicious PDFs could use a standard feature of the PDF specification to run attack code hidden in the file; he also demonstrated a way to modify an Adobe Reader warning message in order to further trick users into opening such documents.

If I recall correctly, and a post in the Stack Overflow thread "Safely opening .txt files" supports my recollection, the only safe file type is .txt, but I could be mistaken.


Can an attacker use a tarbomb to override vital parts of my system?

Actually, according to wikipedia and gnu.org, gnutar won't allow absolute paths and parent directory references, meaning that, no, the tar cannot overwrite files in '~bashrc' and compromise your system.

By default, (unless you add in any additional parameters), most tar unarchivers should extract the files contained in the tar archive to a folder named after the tar archive. Actually, some unarchivers will extract into the current directory, though you could avoid annoyance caused by this by "first creating a new, protective directory and then moving the tarball into it before untarring."

I would assume that if there is a folder with the same name as the tar archive, the tar archive would be extracted to a different (renamed) folder, but that would depend on the unarchiving program that you would use.

As far as other formats go, again, it depends on the unarchiver you use, but the same concept should hold.


How to securely run Puppeteer / Chromium in a Docker container?

It looks like the best option is to use a custom seccomp profile

You can see an example here

Other links to the file you need in case they disappear:

wget https://raw.githubusercontent.com/jfrazelle/dotfiles/master/etc/docker/seccomp/chrome.json

wget https://raw.githubusercontent.com/Zenika/alpine-chrome/master/chrome.json

Sample usage:

docker container run -it --rm --security-opt seccomp=$(pwd)/chrome.json zenika/alpine-chrome


How well is the SSL/TLS handshake protected against modifications?

In "hash" of the handshake messages, as used in the Finished messages, is computed with the PRF, which uses the master secret as additional parameter (in SSL 3.0 the computation is different but the master secret is still used; the 36-byte values are sort-of-HMAC with both MD5 and SHA-1). If the attacker alters one of the previous handshake messages, then he must be able to fix the first Finished message accordingly. That message is the first one that gets encrypted.

The consequence is that even if the encryption system is awfully weak, the attacker must be able to break it with no known plaintext whatsoever if he wants to simply learn the Finished message contents. This must be an online break, meaning that any failure on his part implies impossibility to complete the handshake. As such, even 40-bit encryption would be highly effective at thwarting such attacks.

Let's suppose nonetheless that for some reason, the encryption layer is completely transparent to the attacker (e.g. the cipher suite is TLS_RSA_WITH_NULL_SHA, with no encryption at all). Our attacker still faces two formidable challenges:

The MAC is HMAC (or sort-of-HMAC in the case of SSL 3.0), for which there is no known attack, even when using MD5 as base function (see this, and then that). To make a baseline, there is a known forgery attack on HMAC with MD4, but even that one is still very expensive and thus theoretical only.
The PRF itself is based on a lot of HMAC, so the attacker will have a hard time computing his modified Finished. Mere forgery attacks on HMAC would not be enough; he would have to be able to recover the key (the master secret).

Notably, in TLS, the Finished messages have length 12 bytes (36 bytes for SSL 3.0), while the master secret has length 48 bytes. This means that it is mathematically impossible to recover the complete master secret from the first Finished message, however weak the PRF may be.

To be able to break the handshake integrity, we have to assume a very weird interaction of the PRF with itself, since the PRF is used to compute both the encryption and MAC keys that are applied to the PRF-generated Finished contents. This looks implausible. Alternatively, break through the key exchange mechanism itself. The key exchange (RSA, DH...) looks like the only non-ridiculous attack path (as far as we know).


Clear and concise for PCI audit? No problem, as of now, enable SSL 3.0, disable the rest.

But you also want something more general and you want to combat BEAST? That makes things no longer clear or concise.

There are multiple lists, including some that include handy powershell scripts to do it for you.


It is technically possible for a USB mouse to do something bad. But unlike a keyboard, a mouse can't easily control things on your computer since it can't see the screen to know where to click. To do something bad, it would have to turn in to a device such as a keyboard or other device with a driver that could be exploited.
Next time you'll have to capture your kernel message log and see if new USB devices were plugged in. For example, if your mouse changes in to a flash drive, you'll see the new device being recognized by the kernel in the logs.


What does this suspicious activity in my log suggest?

Yes, it is likely to be a bot scanning your network - probably looking for vulnerable versions of Asterisk running exposed to the Internet.

You might want to implement fail2ban or something similar in order to auto-ban such IP addresses. Better still, if you know where your Asterisk connections will be coming from, just whitelist those and block everywhere else.


How critical is it to keep your password length secret?

Well, let's start with math: If we assume that your password consists of lowers, uppers, and numbers, that's 62 characters to choose from (just to keep the math easy, real passwords use symbols too). A password of length 1 has 62 possibilities, a password of length 2 has 62^2 possibilities, ..., a password of length n has 62^n possibilities.

So that means that if they know your password has exactly 17 characters, then they can skip all the passwords with length less than 17, and there are only 62^17 passwords to try.

But how many passwords are there with length less than 17, compared to 62^17?

Well, if we add up 62^n and divide by 62^17 we get (sum from n=1 to n=16 of 62^n ) / 62^17 = 0.016 (link to calculation), so checking only passwords of length 17 is only 1.6% faster than checking all passwords up to length 17

If we have a password scheme which allows all 95 printable ASCII characters, then the savings from not having to try passwords shorter than 17 drops to 1.06%
 (link to calculation).

An interesting mathematical quirk about this ratio of the number of passwords shorter than n, over the number of passwords of length n, is that it doesn't really depend on n. This is because we're already very close to the asymptote of 1/95 = 0.0105. So an attacker gets the same relative, or percentage, time savings from this trick regardless of the length of your password; it's always between 1% - 2%. Though, of course, the absolute time that it takes grows orders of magnitude with each new character that you add.

The maths above assume a simple brute-forcer which will try a, b, c, ..., aa, ab, ... Which is a good(ish) model for cracking properly-random computer-generated passwords, but is a terrible model for guessing human-generated passwords.

Real password crackers are dictionary-based, trying words (and combinations of words) from the English dictionary, lists of leaked passwords, etc, so those calculations should be taken with a grain of salt.

Another effect of knowing your length is that they don't have to try any passwords longer than 17, which for brute-forcing algorithms that try combinations of dictionary words, could actually be a huge savings.

As mentioned by @SteveSether, @xeon, and @CountIblis, disclosing the length (or entropy) of a password can also effect whether an attacker even attempts to crack your password by deterring them away from strong passwords and instead attracting them to weak ones. So if you know you have a strong password, then disclose away! However, disclosing the password lengths (or entropies) for all users in a system has the effect of making strong passwords stronger, and weak passwords weaker.

Bottom Line:

Telling someone the length of your password isn't the worst thing you can do, but I still wouldn't do it.


How is there a preview for a fake docx file in gmail

Most probably, those attachments aren’t attachments—they’re embedded images designed to look like attachments that link out to a fake Google sign-in page.

Below is a screenshot of gmail phishing attack where the attachment is not a pdf file but an image:


Best practices on securely storing access tokens

The sum of what the client stores and what your server stores must be sufficient to recover the user-specific secret data (e.g. Facebook access token). What the client stores is, mostly, the user's password (the only permanent storage area on the client side is the user's brain, if we want to allow the user to use several distinct machines at will). If I understand correctly, you do not want your server to store the data "as is": in case your server is fully compromised, the user's secrets should still be safe (as much as is possible).

This points to password-based encryption. From the user's password is derived a symmetric key K which is used to symmetrically encrypt a bundle which contains the user's secrets, e.g. the Facebook account. Technically, this would look like this:

When the user registers, he chooses his password P and sends it to your server.
Your server generates a random salt value S and computes PBKDF2 over P and S, to produce 256 bits of output T. Let's call A the first 128 bits of T, and K the other 128-bit half.
The first half (A) is stored in the server's database; this will be used to authenticate users.
The second half (K) is not stored; this is the symmetric key for that user. User's secrets will be encrypted with K.
When the user logs in, he sends his name and P to your server (over HTTPS). Your server retrieves the salt S for that user (as stored in its database) and recomputes T (using P and S with PBKDF2). If the first half of the recomputed T matches the stored A, then the user is authenticated and the second half of T is K. The server can then decrypt the stored bundle and access the Facebook access token.

With this setup, the server never stores (on its disk or in its database) the cleartext Facebook access token, but it can access it when the user logs in; it is up to the server to remember (in RAM) the Facebook access token as long as it needs it.

Note that when the user changes his password, this also changes K (the server must also generates a new salt S, but even if the server mistakenly did not, K would still be changed); thus, the server must decrypt the stored bundle with the old K and encrypt it again with the new K when the password is changed. This is not hard to integrate because password-change interfaces customarily ask for the old password and the new password, so at that point the server has both.

Also note that when the password is forgotten, the bundle is lost. There is no recovery for that case. If the user forgets his own password, then you will have to do some password reset, which is akin to a new registration; and a new Facebook access token will have to be obtained.

In all of the above, we see that your server still sees the user's password. If your server is fully compromised and hijacked, then the attacker will be able to observe users' passwords and users' Facebook access tokens for all users who log in while the attacker controls the server. Preventing that is much harder. Arguably, if your server presents a Web interface only, where all "intelligence" on the client side is Javascript sent by your server, then it is impossible to do better than what the scheme above does, in that situation.


How far a VPN service is legal? Does it makes my data vunerable for hackers?

A VPN is a virtual private network. It can literally be understood by simply breaking down the words:

  Virtual - Because instead of being physical it's virtual or artificial
  (software only)

  Private - Because the communications between your computer and the VPN
  are protected through encryption, virtual tunneling protocols, or the use of dedicated (private) connections.

  Network - (obvious)

When you connect to a VPN, you're really making an encrypted (or otherwise private) connection to another device to be able to access a virtual network on that device as if you were physically connected to that network (just like a LAN). If the VPN acts as a "gateway" and is itself connected to the Internet, then it can share its Internet connection with any device connected to it. This means that when you're using the Internet on your VPN-connected device, it's really utilizing the Internet capabilities of the VPN itself (bypassing any Internet-based restrictions on the device that's connecting to the VPN, and replacing them with any possible restrictions set on the VPN itself).

Since you're relying on the VPN to give you Internet access, it will usually degrade not only your ping time, but also your bandwidth. Also you will have to trust that VPN not to perform Man-in-the-Middle type attacks on your Internet, and to not attempt to access your physical LAN or LAN-connected devices. So yes, there is a degree of risk involved in that aspect.

As for the legalities, it could very well be illegal and more than likely is illegal to bypass any kinds of restrictions that your government had set in place. However in order to find out for sure I would recommend doing your own research on that subject. My advice is, just don't do it. Wait 48 hours and see what happens.


Mount Iphone for Forensic Analysis or Take Forensic Image

You can try with iFunBox or iExplorer, but the really juicy stuff isn't available that easily.  Most forensic tools go through a process which involves having the iPhone do a backup through iTunes, and then the tool will analyze the files stored in the backup.

Without having forensic tools available, you can try one of many tools like this:
https://code.google.com/p/iphonebackupbrowser/

This will let you browse the files inside the backup.  Realize that everything might not be available because Apple is the gatekeeper.  They decide what files to stuff into the backup.

Edit:
You cannot think about an iOS device as a drive.  Android works as a drive because its design allows for us to grab a drive image.  iOS is designed to only allow you access to what they decide you should.

There are many forensic tools that support physical acquisition***.
http://elcomsoft.com/eift.html (see the chart at bottom)
http://www.oxygen-forensic.com/en/compare/devices/software-for-iphone (statements at bottom)
http://www.cellebrite.com/mobile-forensics/capabilities/ios-forensics (expand support section at bottom)
All of these tools have exceptions that state you cannot acquire a 4S or newer.  There is an exploit in the non-updatable bootloader code on the 4 that allows physical acquisition, otherwise it would be a no-go as well.

You can read through Apple's security design and see why we have such difficulties.
http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf

The iTunes backup is the most forensicly sound method of acquiring data from iOS because it uses the phone to do what it is programmed to do naturally.


Presumably you are using svn to keep source code or configuration data or something similar, and having an unauthorized modification would be bad. Passwords are just one layer of security in protecting from an unauthorized modification.

So the rule of thumb would be to have "good" passwords. I personally dislike "complexity requirements", as most people doing this ignore that it's about entropy and not complexity:

Why do password strength requirements exist?
XKCD #936: Short complex password, or long dictionary passphrase?

But if your svn repository is susceptible to a brute force attack (eg, on the internet) you probably don't want your users to have passwords like "1234" or "password".

In addition to that though, you should consider:

Putting the svn behind a firewall, accessible only to internal network
Using SSH keys for authentication instead of passwords
Having branch permissions and a code review process to prevent unwanted changes from getting in the mainline / "trunk" source code


How should hospitals handle the use of sharing credentials to access sensitive information, especially in critical situations?

The ER model:

Everybody gets a proximity card (preferably the active kind that can't be passively copied).
The nurses' desk has a number of active but unissued cards in envelopes.
Authentication is single factor; a valid card is valid access.
Sessions log-off from inactivity or manual action. Card logons should be fast enough that nobody feels bothered.

Security comes from control of cards. A nursing manager can be in charge of associating a card with a new cardholder and deactivating their old or broken card. Availability comes from the fact that any employee can quickly get a new card. Accountability comes from ensuring that cards are quickly associated with employees.

See also: http://healthcareit.stackexchange.com/q/254/37


Firefox jetpack store.json stores all my visited domains!

Why does Firefox store all my visited domains, even when I'm using
  "never remember history" and clear all cache, use bleachbit to clear
  out thing?

  Question: Is this a privacy issue? Why does Firefox do such a thing?

Only you can decide if this is a privacy issue. As long as noone can read the files in your profile, probably not. Otherwise it might be.

Firefox itself should not do this if you set "never remember history". However, an addon may do this on its own.

  How to find out which add-on causes this?

You can look at the name of the file to find out.

The filename you give is:

  /home/user/.mozilla/firefox/aaaaaaaa.default/jetpack/aaa1-aaaaaaaaaaaaaa@jetpack/simple-storage

The part after "jetpack" ("aaa1-aaaaaaaaaaaaaa@jetpack" in your example) is the ID of the add-on responsible for this directory. You can look up this ID in addons.json in your profile folder.

If the ID is not in addons.json, the add-on is (no longer) installed - in that case the files may be left over from a deinstalled add-on. In that case there's probably nothing to worry about, because the file will no longer be updated. You can probably delete it (keep a backup though, just in case).

If you still want to know what deinstalled add-on was at fault, you can search for the add-on ID on the web. This will usually tell you what add-on uses this ID.


Apparently As of December 2014, the common driver for this device does not support monitor mode on Linux. Kernel.org showed that monitor mode was untested however I did find this link https://wikidevi.com/wiki/ALFA_Network_AWUS036NHV


What exactly does it mean when Chrome reports 'no certificate transparency information was supplied by the server?'

Note: If you're here because your certificate isn't trusted by Chrome, this is not the reason. Chrome will still trust certificates without CT information. If your certificate isn't trusted, there is an additional factor that you may have missed.

This has to do with the concept of Certificate Transparency.

The Problem

Browsers currently trust certificates if four conditions are met: (a) the certificate is signed by a trusted CA, (b) the current time is within the valid period of the certificate and signing certs (between the notBefore and notAfter times), (c) neither the certificate nor any signing certificate has been revoked, and finally, (d) the certificate matches the domain name of the desired URL.

But these rules leave the door open to abuse. A trusted CA can still issue certificates to people who shouldn't have them. This includes compromised CAs (like DigiNotar) and also CAs like Trustwave who issued at least one intermediate signing certificate for use in performing man-in-the-middle interception of SSL traffic. A curated history of CA failures can be found at CAcert's History of Risks & Threat Events to CAs and PKI.

A key problem here is that CAs issue these certificates in secret. You won't know that Trustwave or DigiNotar has issued a fraudulent certificate until you actually see the certificate, in which case you're probably the perpetrator's target, not someone who can actually do any real auditing.  In order prevent abuse or mistakes, we need CAs to make the history of certificates they sign public.

The Solution

The way we deal with this is to create a log of issued certificates. This can be maintained by the issuer or it can be maintained by someone else. But the important point is that (a) the log can't be edited, you can only append new entries, and (b) the time that a certificate is added to the log is verified through proper timestamping. Everything is, of course, cryptographically assured to prevent tampering, and the public can watch the contents of the log looking to see if a certificate is issued for a domain they know it shouldn't have.

If your browser then sees a certificate that should be in the log but isn't, or that is in the log but something doesn't match (e.g. the wrong timestamp, etc), then the browser can take appropriate action.

What you're looking at in Chrome, then, is an indication as to whether a publicly audible log exists for the certificate you're looking at. If it does, Chrome can also check to see whether the appropriate log entry has been made and when.

How widely is it used?

Google maintains a list of "known logs" on their site. As of this writing, there are logs maintained by Google, Digicert, Izenpe, and Certly, each of which can maintain the audit trail for any number of CAs.

The Chrome team has indicated that EV certificates issued after 1 Jan 2015 must all have a public audit trail to be considered EV. And after the experience gained dealing with EV certificate audit logs has been applied, they'll continue the rollout to all certificate issuers.

How to check the logs

Google added a Certificate Transparency lookup form to their standard Transparency Report, which means you can now query for the domains you care about to see which certificates for those domains show up in the transparency logs. This allows you to see, for example, which certificates out there are currently valid for your domain, assuming the CAs cooperate.

Look for it here: https://www.google.com/transparencyreport/https/ct/

Remember that if you want to track a given domain name to be alerted when a certificate is updated, then you should follow the logs directly. This form is useful for doing point-in-time queries, not for generating alerts.


Which part of the eapol packets contain WPA password Hash?

The hash is not passed directly in the string of bits. It will not just be there to grab in one packet. In order to attack WPA/WPA2 you must capture the entire four-way handshake. The key itself is not really sent as part of the message, since both sides know the key, they just need to prove to each other they know it, not send a hash for verification. One you have all parts of the four-way handshake capture, you then just brute force passwords until you get one that fits.

References:

Benefits and Vulnerabilities of Wi-Fi Protected Access 2 (WPA2)
Details of Key Derivation for WPA

Edit: Please see details in this question and answer. The answer is about the same, but your question is slightly different so it may not be merged as a duplicate.


Why did Chrome show my connection to Youtube as not secure?

HTTPS not secure can be caused for multiple reasons but usually has to do with the certificate being used. In chrome you'll want to view the certificate details and see if anything is awry such as ...
- untrusted issuer
- name mismatch
- date is expired
- date is the future

It could also be that your PCs systems clock is way behind or way ahead causing chrome to think the certificate is bad when it really isn't.

Sites like YouTube are load balanced too so perhaps 1 of its 100 servers are hosting up an invalid certificate and you just happen to get that one.

Perhaps could also be related to ad advertisement or script being served up insecurely on HTTP.

This blog explains a bit
https://www.rankya.com/how-to/how-to-fix-the-https-not-secure-message-in-google-chrome/


See the contents of https/ssl data weeks after leaving the wfi

No, he cannot have recorded your traffic then decrypt it later. That takes an incredible amount of power and time.

As for "downgrade attacks", those require an active connection. You manipulate the negotiation of the security between the server and the client and force a weaker level of security. That's obviously not possible when there is no connection or on recorded traffic.

Could he have been able to see your traffic while you were there? Yes, using the methods you read about in the workplace questions you mentioned. Primarily by installing a certificate on your devices so that the lock would be there, but he was logging all the details because the lock was to him and not to the site you were browsing.


How should passwords be stored if they must be recoverable?

Don't force yet-another-password on your users.  Use PKI, hardware tokens, or some other method like OAuth or OpenID that leverages some Identity Provider site which sits outside of whatever jurisdictions you're worried about.

Note that the actual requirements of the 2004 French law in question Loi pour la confiance dans l'économie numérique aka Act on Confidence in the Digital Economy are not clear and it seems that some reporting has misinterpreted or exaggerated the effects.  For example it sounds like it may be sufficient to simply provide law enforcement with some other access to the user's account, e.g. for a child pornography investigation, in a way that doesn't tip the user off that their account is being accessed (as a typical password reset would).


I would not treat the <title> tag any differently than I would treat any other tag, lika a <div>. The context you are talking about (inbetween HTML tags) is what OWASP call "HTML Element Content" in their XSS prevention cheet sheet. They recommend the following substitution rules:

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;
/ --> &#x2F;

However, I can not for the life of me figure out how you would be able to do any mischief without < or >, so I think (as opposed to know) that you are safe. Still, there is no harm in following the OWASP recommendations to the letter.

In other contexts other sanitation rules are required, so do not take this as just endocing < and > is always OK. It is not.


Is it possible to specify a content security policy in browsers?

No browsers that I know of has this built in.

It would surely be possible to build such a plugin but it wouldn't really be useable. Why? Setting a CSP just for one site can be a pain in the a** even when it is done by the people maintaining it. Even if you know your site well, it is not trivial to know exactly what domains things are loaded from. Make one mistake, and boom, you break something in a far off corner that you might not even notice.

Now imagine that you have to do this for all sites without even knowing how they are built. Will Stack Overflow break if I disable inline JavaScript? I have absolutely no idea. And more importantly, it would take forever to figure out. Now multiply that by thousands to cover all the sites you visit.

I am sure there are creative ways that the user experience could be smoothed out, but in the end this would just be a usability nightmare.


Sign a document as created with an authorized software build

You're correct in saying that embedding a key in the software is no good, because an attacker could read out the same key.

One thing that stands out as a worthwhile place to look is the (new-ish) hardware modules called Trusted Platform Modules, or TPMs. There are published schemes that use TPMs to, for example, detect cheating in online games by ensuring the game binary and memory state has not been externally modified. Without inspecting them in detail it's hard to be sure, but that sounds like something you could use.

The fundamental idea here is that you're asking for confirmation not from your software, but from the computer's hardware. The hardware can, say, hash your binary and sign it with a private key stored only in that hardware: it doesn't even go to the CPU. That does imply that Intel or whoever makes the chips could, were they so inclined, mask the existence of a fake version. They might have back doors, up to and including copies of the private keys embedded in the chip. Nevertheless, protecting yourself from everyone short of those with the leverage to bully or bribe security hardware manufacturers probably covers your use case.


May have been hacked, tips on how to proceed?

Personally, these are the steps I would take if I thought my personal computer had been compromised enough that the traffic was being captured. The following assume you have a friend with non-compromised media.

Go to a friends house and use their computer to login to all accounts and set them to new, secure, unique passwords. If 2 Factor Authentication is available do it. Bank accounts, phone bills, etc. etc. All of them changed.
Wipe the personal computer with Darik's Boot And Nuke (DBAN) on a bootable flash drive created at your friend's with your friend's flash media
Reinstall Windows from a fresh media created using friend's flash drive and computer.
If you can be sure your backups haven't been compromised, restore from backup.


Is there a security issue in using the same certificate for all a company's services?

Using the same certificate does not in any way affect the fundamental security of the connection that is established using it.

The only possible "weakness" introduced by using the same certificate is that if that certificate expires or is leaked all your sites will be affected. Since this certificate is on multiple servers and some of them might be test servers with less security there is the possibility that the private key of that certificate can be inadvertently leaked or exposed from one of these unchecked servers.  This is is certainly not a failure of the security provided by the certificate, but rather a failure in keeping the certificate's private key secret.

The alternative would be to use separate certificates for all your sites which would mean that you would have that administrative burden of having to renew, protect and monitor multiple certificates.

If you properly protect the private details of that one certificate there is no reason why using it would introduce any additional security concerns.


Security concerns of user-provided relative URL in Location: header

Open Redirect

Where does the next value originally come from? POST requests are not generally vulnerable to open redirect.

But assuming that it is controllable by a previous GET request:

Your approach solves one problem. Before, an attacker could inject .evil.com and thus be redirected to someserver.com.evil.com which is under the control of the attacker. Even if . is not allowed, if the url is eg someserver.co an attacker could inject m and be redirected to someserver.com.

Your solution introduces a new problem though. If an attacker injects /evil.com they will be redirected to //evil.com, which is a protocol-relative URL.

Other Issues

Appart from open redirect issues, being able to internally redirect isn't of too much benefit for an attacker. If the authentication is open to CSRF, it may provide some benefit in login-CSRF attacks (eg to redirect the victim to a page that contains some XSS payload). It may also be possible to bypass referer-check based CSRF protection for GET requests.


Exfiltration through FTP using XXE on a Tomcat server

I'm not sure what exactly is going on, but it looks like the client (your target) is sending the file's contents to the server as if it contains FTP commands. What if you just listen with netcat? Either just listen with nc -lp 2121 (or whatever your netcat variant wants for arguments, iirc some want nc -l 2121), or maybe the client expects a response in which case you could do something like this:

echo -ne '220 Ok\r\n' | nc -lp 2121

Note that FTP is a text-based protocol. Binary files will be troublesome if the client thinks it has to convert them into ASCII for the control connection. Do try, but it might be that that's your next obstacle.


I have a conceptual idea for a network that could obfuscate the geolocation of a mobile station. I would appreciate short, critical feedback

The "data footprint" of your actual session will probably be fairly easily distinguished from your decoy points from an attacker who can dedicate any amount of time to the problem.

a) Let's say that on Monday, your packets originate from Lesotho, Seattle, and Moscow. On Tuesday, they are from London, Mexico city, and Seattle. On Wednesday, they come from Seattle, Tokyo, and DC. On Thursday, they come from Quebec, Kathmandu, and Seattle...

b) "Gibberish" data would be pretty easy to recognize from data with a purpose. Even it is encrypted, the patterns of the metadata would stand out.

c) Your control messages (power off true location, power on decoys, vice versa) need to be sent out of band and securely or they will give the whole thing away.

Who are you trying to hide from, and what level of resources do they have? That's a good question to think about.


How do you get a CA trusted by Certificate Transparency logs?

So your question boils down to this:

We are a small CA supported by some browsers. We are trying to offer EV certs but are running into issues because we're not logging our certs to CT logs. How can we get the CT logs to accept our certs / SCTs?

I agree that it's surprisingly hard to find any information on this. My first hint comes from Chromium docs:

Locally-trusted CAs
For CAs that have been manually installed, provided those certificates are not or have not been publicly-trusted, it‘s not necessary to enable support for Certificate Transparency. Further, Certificate Transparency Logs will not accept certificates from those CAs, thus it’s not possible to support CT.

Alright, that's a hint that CT logs will only accept SCTs from publicly-trusted CAs. But what does that mean? The whole point is that logging to CT will increase your public trustworthiness, so that seems a bit ... circular.

Next bit of useful info: Chromium CT Log Policy:

When applying for your CT log to be included in Chrome the CT Log Operator must provide the following information about the new CT Logs in their application:

The set of Accepted Root Certificates of the Logs

So that tells me that each CT log operator gets to decide which CAs to accept into their log. That means each CT log is likely to have their own policies for who they accept.

From the same Chromium CT Log Policy, I see

Logging Submission Policy
Accepted Root Certificates
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. Note: This restriction may prevent a CT Log from being accepted by Chrome for inclusion.

The plot thickens. So while it's technically up to the CT Operator which Root CAs to log for, they had better log for all roots in the Chrome Root Program. It doesn't say that the CT log can only accept submissions from roots in Chrome. So you're not totally out of luck yet.

Here is the official list of CT logs recognized by Chrome.
As per the Chromium CT Policy (see section "Embedded SCTs"), you'll need to get your CA into:

2 CT logs if cert lifetime < 15 months
3 CT logs if cert lifetime >= 15 and <= 27 months
4 CT logs if cert lifetime > 27 and <= 39 months
5 CT logs if cert lifetime > 39 months

Of those at least one must be a Google-operated CT log and at least one must be a non-Google CT log.
Since you asked about Google Pilot in particular, here's a Chromium bug tracker thread that says:

HTTP(S) endpoint: https://ct.googleapis.com/pilot
Description: Google's first CT log, operating since 2013-03-25 (has been monitored by http://ct-watch.tom-fitzhenry.me.uk/#/logserver/google-pilot). Will log any certificate that is anchored in a root trusted by one of the major browser vendors.

Which is again a bit circular; "We'll log for you if the browsers trust you"
Soooooooooooo I think you need to pick some CT logs from that list and start sending emails. I expect you'll get asked A) if you're in the browsers, B) if you're eligible to be in the browsers. Sounds like if you're not compliant with CA/B Baseline Requirements, and have not passed a WebTrust audit, then you'll probably be fighting an up-hill battle to get them to include you.
... which I think doesn't really tell you anything you didn't already know. Sorry if none of this is helpful.


How do I stop attack on my email id from hackers?

This is because SMTP does not offer great spoofing protection, so typically you can connect to a server and claim to be someone else. The best way to fix this would be to set up an SPF record with a hard fail, which is expressed using a- and typically is at the end of the record as -all. You would have to be certain of where your emails are coming from. You can use other domain names or IP addresses for this. Below is an example of the TXT record you'd need for SPF. There are many how-tos available. If you are concerned legitimate messages will be dropped, you could also enable DMARC reports before actually turning on a hard fail, and instead using the soft fail which is expressed as  ~.

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"


What is the difference between "full" and "ultimate" trust?

Ultimate trust means that the key is allowed as introducer in the web of trust. This means, if a key is ultimately trusted, all certified keys are considered valid, no matter if there is a trust path to the ultimately trusted key. This does not require you to posses the private keys, but you usually will do.

Full trust (by default, this can be adjusted) also makes keys certified by the fully trusted key considered trusted, if and only if the fully trusted key is valid itself (thus, there is a certification path from an ultimately trusted key).

Marginal trust works similar to full trust, but requires multiple incoming certifications from other marginally valid keys.


7-zip (or any other similar utilities) encryption is designed to protect archived files. So, as long as the tool designers did their job well, you are safe for the second case (somebody getting his hand on the encrypted file and trying to crack it).

However, such utility are not designed to protect you against your first mentioned case (someone getting access to your account data on your machine and/or you accessing the file content regularly). Indeed, someone having taken a full (or even just minimal, no need to escalate privileges) access to your system will see you use this file and will also be able to capture your keystrokes while you type your password. Even worse: an attacker will actually will not even have to bother with this since the file will most probably be present in clear form in your Windows Temp directory.

So, for your first threat, I would definitively recommend you to use a tool designed for this usage, like KeePass which will avoid to store decrypted data in temporary files and will provide a minimum protection when typing the password.


Production frontend server receiving several unknown requests

As @multithr3at3d alluded too in his comment, it is very common to be "scanned" by random nodes on the Internet.

There are a lot of attackers who will just try all sorts of combinations to see what services you are running or to try to take advantage of known exploits. Sometimes the attackers do recon and target their attacks, but other times they just try anything they want - maybe they try a lot of different websites when a new exploit is found.

While this activity can at first be scary, its relatively common. There is also more benign activity like search engine spider. Another possibility is that there is some automated script with legitimate purposes, but was accidentally configured to point to your server, though its more likely you are just being scanned.

If the scanning activity is coming from one specific IP or a list of specific IPs you can just block them at the network firewall level or in your web server config. There are also WAF technologies and vendors you can put in front of your site, but that usually only makes sense financially and time wise if you are a large commercial website.


Storage of API authentication token in single-page-applications

Here's the simplest example possible to show how to store values securely in JS code:

var api = (function(){

    let secret = prompt("enter a secret phrase"); // Only the api object can reach this

    return { // a method to compare guesses to the secret
     auth: phrase=> phrase == secret
    };

}()); // end privacy wrapper

// test it in console by entering bingo at the prompt:
[api.auth("one"), api.auth("bingo"), api.auth("cheese")];
// evaluates as [false, true, false]

In a real application, the secret is fetch()ed by ajax, a cookie, or whatever else you use. The crux is just that the only access to the secret is via the methods defined within the wrapping function that defines the "private" variable. This pattern is called a "privileged method" in JS, being made available to code outside only through the terms and conditions that your "api" object stipulates.


Can Simultaneous Logins Occur When Two Users Have Both Pieces Of Two-Factor Authentication Information?

It depends on the type of the OTP method and implementation details.  Whereas [RFC4226][1] (the counter based OTP) can be understood to forbid reuse, as it says:

  the server's counter value is only incremented after a successful HOTP
  authentication

But that may not be a guarantee that there is no time window that the same HOTP token will be usable - multithreaded authentication servers, with concurrent database access may overlook this detail.

It is also describing that:

  RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.

Which implies they don't consider it the property of the protocol to protect against reused tokens!

Similarly, for time based OTP [RFC6238][2] explains that it's a good protection against attacks to reduce the time window when a token is valid.  But it is mentioning the token is consumed, which, to some may imply it cannot be consumed again.

  First, a larger time-step size exposes a larger window to attack. When an OTP is generated and exposed to a third party before it is consumed, the third party can consume the OTP within the time-step window.

I, personally do not think a copied second factor should be valid, but this is not necessarily what the standards say, so there may be variations on how this is interpreted.  Other 2FA vendors may not even adhere to any of the standards, and may have stricter or looser requirements.  Let me also note that it may be difficult to implement a reliable method of locking out all but the first use of a token within widely distributed networks, for all cases.

Update: now that I think of it, I can see two additional ways of preventing access with duplicate OTPs - one is at the preparation: making sure there's only password login out there that is in progress of accepting an OTP until the authentication timeout.  The other is invalidating the already granted session, in addition to the duplicate one.  This can be easy in a web-based service, but not as convenient with a computer shell access.

Also to be considered that you can't be sure the valid user is the first one, so it can be a hindrance for the them as well.  In the case of true MITM, the attacker can even stop the genuine attempts by them so that there can't even be a notification over the same channel.

As you can see, it's not as simple of accepting or not accepting the duplicate OTP - you need to consider the user of the service, how they can get into this situation and how they will be the least harmed, or best served.  Perhaps this is why the standards won't discuss these details, and leave it up to you.

[1]: https://tools.ietf.org/html/rfc4226 RFC4226-HOTP
  [2]: https://tools.ietf.org/html/rfc6238 RFC6238-TOTP


security of cryptsetup(8) luksRemoveKey, feasibility of extracting MasterSecretKey and using it later

You are correct, although I wouldn't call luksRemoveKey "weak", it accomplishes what it is meant to. There are plenty of situations where it's easier and quicker to only change the KEK (key encryption key) so long as the DEK (data encryption key) was never leaked and all old copies of the LUKS header can be wiped to prevent use of the old KEK.

If you need to prevent someone who had the ability to access the DEK from later decrypting the volume, you will need to either recreate the volume as you suggest, or use cryptsetup-reencrypt to change the DEK in-place (be aware the manpage warns it's not resistant to hardware/kernel failure).


It is probably because the authors of that documentation couldn't think of a scenario where it may be ok to use an implicit intent, but didn't want to rule out the possibility that someday, somebody might think of such a scenario and want to use an implicit intent inside a pending intent, without it being a security issue. Hence, they left open that possibility.


Sending an encrypted PGP email to someone who doesn't yet have my public key

They don't need your public key at all to decrypt.

You need their public key to encrypt the message, which they decrypt with their private key. The only thing they need your public key for is to verify that the message comes from you. In that sense it doesn't make sense to attach your public key, unless, for instance, you plan to confirm fingerprints over the phone soon after.


Good question. To my knowledge, this is where most of the Trusted Computing confusion comes from.

Yes, it's important to understand that while the TPM collects measurements (PRCs) from DRTM (e.g. Tboot) or SRTM, it cannot not take action on them. The value of those measurements can only be seen with the seal()/unseal()/quote() operations.

Imagine we booted within an environment we believe to be clean (e.g. a fresh install). SRTM/DRTM filled the measurements of the boot process within the TPM's PCRs. We can use the seal() operation to encrypt data using the values of those PCRs. Yes, the PCRs becomes the key (or part of the key). In other words, the signature of the running environment is the key to our data.

Now imagine we rebooted and want to get back this encrypted data. We need to use the unseal() operation which will use the current PRCs to try to decrypt our data. If the environment is the same, no problem we get our data back. If the environment changed, no luck. Keep in mind we cannot forge PCRs value - only SRTM and DRTM can.

If you run this scenario while considering that the data we encrypted is actually a key used to encrypt our hard drive, you now understand how Trusted Computing (TPM) can prevent someone from accessing something without actually talking decisions - without actually being active (being dumb).

I suggest you read this answer.


Android security document comparable to Apple's security document?

Official documentation on Android security can be found on the AOSP site. However, I would expect a non-programmer to only understand a subset of that documentation.


Is it secure to use 3rd party apps like WASender for bulk WhatsApp messaging through WhatsApp web?

...  is there a way the integration could bypass WhatsApp's encryption?

It does not need to bypass any encryption. It is a browser extension and as such it has access to the messages the same way as the Whatsapp in the browser has - in fact, you grant the extension access to web.whatsapp.com and thus to all your messages since these are no longer encrypted in your browser.

  Is the data safe?

Which data, against what? The messages are send using your WhatsApp account. They might be changed by the extension before sending but they are delivered encrypted from your phone to the recipient. The extension could also read your existing messages.
 I'm not saying that the extension does anything like this but it could based on the permission you grant. And even if it doesn't do this now it might do it later, or never, or instead send their own ads using your contacts ...
If you feel comfortable with this then it might be safe enough for you.


Would it be possible to create an external mac address spoofer?

This is called a layer 3 bridge. It can be done with common hardware and a common OS like Linux. All what it is needed is a hardware with two network cards and to configure the OS as a layer 3 bridge. The outgoing data from the bridge in the direction of the rest of the network will have the MAC of the bridge's network interface and not the original MAC.
Note that care must be taken to rewrite the MAC not only inside the IP packets but also in payloads which connect layer 2 with layer 3, i.e. within ARP. See for example Bridging Network Connections with Proxy ARP.


How does the server-client scheme work in a botnet?

The Client-Server model in botnets is just the same (with maybe some pimps from botnet family to other) as any client<->server model, its setup like a network with one or more main server(s) that control the transmission of informations from and between each client. As for RATs the botmaster have usually a Command and Control (C&C) server (or servers) in order to orchestrate slaves (clients). This model is called Centralized. While there is also Peer-To-Peer model and Hybrid models

Know:

  How does B (the attacker) even know when A (the infected) is online,
  if B (the attacker) does not have a server running listening for
  connections incoming from infected machines?

While far from being exhaustif, here are some ways described in the following slides:

Internet Relay Chat (IRC)

Port 6667 or custom port
join hardcoded channel send
command/instruction via joined channel (PUSH)

HTTP/HTTPS

Port 80, 443
Php based system
Post request (PULL)
Snd.php (register the botnet)
Update.php (update the binary file)
Stat.php (get the command)

P2P

UDP
No fixed port
Supernode (locate where the C&C server)

There are several maneer to perform this, and keep in mind that usually (if not always) that it's A that notifies B of its presence,whether as a new infection or as an online/offline activity.  There is always some kind of Push and Pull methods.

For example once a client of Zeus botnet is infected, he tries to download a config file from the server (B) via HTTP/Getnotifying this way the server of a new infection (called registering):

Some Botnets uses IRC , by setting up some IRC servers, A reports to B and B commands A via IRC commands.

Kraken Botnet for example uses UDP/447 to the C&C server resolved from a fully qualified domain name list.

There is no generic answer, it all depends on the topology/model and how the developers  of the botnet in question are smart/skilled.

You can learn more on how botnets communicate from these links. "Detecting Covert Botnets Using Communication Patterns", "Botnet Communication Patterns"


The output is a stack trace, and it looks like the current parameter you are testing is not vulnerable to SQL injection. It's not clear if the application is vulnerable to SQL injection or not.

A stack trace is simply a listing of where in the process's callstack an exception occurred.  In your case, it's a "java.lang.NumberFormatException"  That means that the application can't cast the input string (a single quote, in this case) as a number.

When you come across exceptions like that, try googling them.  You'll often find a wealth of information.  For example, I google the com.sun.jersey.api.ParamException$QueryParamException error message, and discovered that the application is using a RESTful framework named Jersey.   See if you can find the api documentation for the error message, and see if the Param its talking about is referring to parameterized SQL, or if it's just referring to a query string parameter.


How does adding a random serial number improve a certificate's security?

Short answer. The benefit is from an unpredictable serial number, not from any old serial number.

Indeed, a sequential serial number adds no security, as it is easily predictable.  But randomizing the serial number (so it is hard to predict) does make it harder to exploit the known collision attacks on MD5 to get a forged certificate.  Let me explain.

Background. When a CA issues a cert, it includes a signature on MD5(P), for some certificate payload P that includes a public key, a domain name, and a serial number.  The known collision attacks on MD5 allow the attacker to choose two values P and Q that have the same MD5 hash.  This can be used to attack CAs that use MD5, as follows.  The attacker uses the MD5 collision attacks to find P,Q with the following property: P is a benign certificate payload that the CA would willingly sign (e.g., a cert for some new domain that the attacker controls), but Q is an evil certificate payload that the CA would never sign (e.g., a cert for microsoft.com).  The attacker sends a cert request corresponding to P to the CA; the CA signs it and returns the signed cert; and then the signature on this cert will also be a valid signature on Q.

Note that this attack requires the attacker to predict the value of the serial number that'll be used when the CA signs the cert for P.  If serial numbers are assigned sequentially, this prediction task is easy.  But if serial numbers are (say) a cryptographically-random 128-bit number, then the attack no longer applies.  Therefore, some have suggested using random serial numbers as a mitigation.

Further details.  See the following research paper for more details:

Short Chosen-Prefix Collisions for MD5 and the Creation of a Rogue CA Certificate, Marc Stevens and Alexander Sotirov and Jacob Appelbaum and Arjen Lenstra and David Molnar and Dag Arne Osvik and Benne de Weger, CRYPTO 2009.
Website: http://www.win.tue.nl/hashclash/rogue-ca/

Recommendation. The best defense is: don't use MD5!  Just stop using it.  CAs should use a modern hash like SHA1 or SHA256 or SHA2.  They should never use MD5 when issuing certs.

But if for some reason you are forced to use MD5, randomizing your serial numbers is a reasonable mitigation.  Actually, using a random serial number might not be a bad idea, no matter what hash algorithm you use, as a form of belt-and-suspenders defense-in-depth.


Does storing bank account-routing number combinations fall under PCI DSS Level 1 compliance rules?

Since PCI stands for Payment Card Industry the short answer is no.

However that information is sensitive so you should treat it like any other sensitive data and store and transmit it in a secure, encrypted form.

PCI is a great baseline for dealing with any secure data so it certainly wouldn't hurt to treat it the same.


How secure is connecting to the Internet via Windows XP (or even older) nowadays only for e-mail?

The argument "I am not of interest to anybody. Why would anybody want to attack me?" assumes that an attacker would only take one specific angle - that of a targeted attack.

However, more often than not, criminals will just run automated scripts that check for vulnerable machines and try the attack that will most likely work for that machine. Depending on the exploit, they can then use that machine for a number of malicious purposes, such as:

Sending out spam
Using it as proxy for other attacks
Deploying ransomware
Conduct DDoS attacks
Distribute malware
Etc.

  But what about NAT and firewalls?

It depends on your setup and the kind of exploit. For example, Windows XP doesn't support modern browsers, so you are stuck with legacy versions of other browsers. Just to illustrate this, the last version of Chrome available for Windows XP was Chrome 49, which came out in February 2019. That means any bug fixed after that date will forever stay on Windows XP.

If you are stuck with an old browser, you open yourself up to all kinds of horrible browser-based exploits, which attackers can easily employ on the web. A firewall or a NAT will not help you at all there.

  Are people even bothering to look for vulnerabilities in such old software?

Surprizingly, yes. Usually not specifically to Windows XP, but if someone were to find an exploit in some software, the vendor will then attempt to find when the bug was introduced in order to see who is affected.

In many cases, the bug was introduced in a very old version of the software, and if that happens to be the one you are using, then you're out of luck.

Furthermore, new technology to increase security gets employed. HSTS or OCSP Stapling, just to name some. If you use a legacy OS with legacy software, you will not have access to any of those, which will mean you are worse off.

  But I only receive e-Mails from trusted parties. I'm not in danger!

Yes, until you don't. Forging an e-Mail to look somewhat passable is not as difficult as it may seem. Phishing is a difficult topic, because many people will think that they "are too smart to fall for this", until they're in a hurry once, just quickly want to check their mails and open an attachment. Sadly, their version of Office was too old to detect the macro in the document was issuing OS commands in the background.

  But is it not secure enough?

Let me ask you a different question: Why are you not just getting a modern OS?

If all you do is check your e-Mails once in a blue moon or play some Solitaire, then get yourself a modern Linux distribution. Lubuntu, for example, runs decently well, even on Windows XP-era hardware.

And if your hardware is up-to-date and you just miss the look-and-feel of Windows XP, then use Windows 10 and get yourself one of the billion tools that make it look like Windows XP.


CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

If it really is "default", then no update is required: OpenWRT has always used uClibc for its libc by default, it will not be vulnerable if so.

However, OpenWRT also supports glibc (and musl, which will be the default in the next release), so it is possible to have a vulnerable OpenWRT. Given the size and complexity of glibc, it's most likely that memory/storage constrained devices will not run a glibc version.

If you have a shell on the system, this should be useful:
https://unix.stackexchange.com/questions/120380/what-c-library-version-does-my-system-use

If you built/configured it yourself, check CONFIG_LIBC in the .config in your build directory. Otherwise, check with the provider of the OpenWRT installation.

(It is also possible, though very unlikely, to have multiple libc instances. The OpenWRT build system does not support this though.)


How to get "Policy: X509v3 Any Policy" in a certificate generated with OpenSSL?

There is probably a more elegant way to do it, but I add the following option to the [ v3_ca ] section of my OpenSSL configuration file:

certificatePolicies = 2.5.29.32.0

The OID values are available at http://www.alvestrand.no/objectid/2.5.29.32.0.html .


Why include DNS client cookie in DNS server cookie computation?

If I understand it correctly adding the client IP address to the servers cookie is used to protect against source spoofing attacks against a client which is behind the same NAT as the attacker.
If the server cookie is only associated with the external IP address of the NAT then the internal attacker could make a valid request to the server to get a server cookie which is valid for all clients behind the same NAT. Then the attacker could create a request with the spoofed source IP address set to the internal victims IP address. The NAT gateway will replace the source IP to the external IP when talking to the server. The response from the server will then be forwarded by the NAT gateway back to the alleged sender of the request, i.e. the victim. But since the request contained the server cookie the server assumes that it communicates with an authenticated victim and will switch off amplification protection.
By associating the client cookie with the server cookie and including both client cookie and server cookie in the request the server can validate that the request is really from the same client which got the server cookie before and not some other client behind the same NAT gateway. Only if the attacker is able to get the client cookie he will be able to mount an attack against the client. But to do this the attacker must be able to sniff the network traffic which needs more resources and permissions and is thus explicitly excluded in the attack scenario. From section 9 of the draft:

Security Considerations

DNS Cookies provide a weak form of authentication of DNS requests and responses. In particular, they provide no protection against "on- path" adversaries; that is, they provide no protection against any adversary that can observe the plain text DNS traffic, such as an on- path router, bridge, or any device on an on-path shared link (unless the DNS traffic in question on that path is encrypted).


Which AES key length to choose for OpenVPN?

AES key size and RSA key size do not relate to the same thing.

RSA, DSA, Diffie-Hellman... are algorithms involved in the initial steps of key exchange, and they come from asymmetric cryptography, which uses a lot of mathematical structure (big integers with special characteristics) to achieve its goals. That structure is what makes them run at all, but it also is their weakness, since it can be leveraged to break them. To avoid that, these algorithms must use very big integers, traditionally 1024 bits or more. Some people consider that 1024 bits are no longer sufficient because computers get faster over time.

AES is symmetric cryptography, which is conceptually simpler: the same key is used to encrypt and to decrypt. There is no mathematical structure here, only a bunch of bits. The attacker has no leverage, and his only recourse is to try all possible keys (that's called "brute force"). 128 bits are more than enough to defeat brute force.

To make an analogy, a RSA key is a wall made of sand, while an AES key is made of steel. Both can be strong enough to block an incoming rocket, but in the case of sand you will need more of the stuff.

AES accepts three key sizes (128, 192 and 256 bits); all three are fine. In fact, 128 bits are slightly better because AES-128 is slightly faster than AES-192 and AES-256.


The short answer is; probably not. Unless of course you actually pay for that service. An ISP does exactly that, it supplies you with Internet Service - if that's all you're paying for that is all you will get.

As far as I know, at least in the UK I could not contact any ISP and ask them to help me with spam prevention because not only do I not pay for that, they don't even offer it. Obviously, this can vary depending on your location but unless your ISP explicitly offers that kind of service to you (for a fee of course) then chances are they will not even be interested to hear what you have to say.

If they don't provide the service they don't provide the service and unfortunately, they're not going to change their business model for you and start selling spam prevention as a service. Your best choice is to see what spam prevention methods your mail provider can provide you.


Is it possible to modify a support .js file in a web application by injection?

Just to ensure we use the right terminology, it should be noted that when talking about web-application vulnerabilities, injection attacks usually refer to  A1-Injection as defined in the OWASP Top Ten classification.

That being said, the answer to your question is yes. Providing the web-application is prone to injection attacks, an attack scenario could be the following:

  The attacker sends a malicious input to the web server that in turn
  passes it to an interpreter (e.g. php) which includes it in a request
  and executes it. The malicious input is then executed on the web
  server, and if the JS file permissions allows it, the code executed (the payload) could
  modify the JS file with an arbitrary content. This modified JS file would then be served to every client requesting this web page.

To simplify, an injection attack can potentially gives an attacker the ability to execute arbitrary commands on the victim server, resulting in files and/or data modification.


What should content-type be of encoded page?

The Content-Encoding of the page is unrelated to the Content-Type.
Content-Encoding specifies how the content is compressed (i.e. gzip, deflate, br...) and thus how it should be decompressed. Content-Type instead specifies how the content should be interpreted, i.e. as html, image, PDF etc. And for text data like plain text or HTML it can additionally specify the character set and encoding, i.e. UTF-8, ISO-8859-1 or similar.

If no Content-Type is specified browsers try to guess what the type and character set/encoding the content might be. This can have unintended side effects because different browsers might guess differently and specifically the dedected character set might also depend on various contexts like the character set of an embedding frame.

Thus you should always specify a Content-Type and also set the Charset parameter for text types. Additionally you should set the HTTP header X-Content-Type-Options: nosniff so that the browser does not try to guess the type even though the declared is differently from the guessed type.

For more information about the problem with MIME sniffing see also MIME Sniffing: feature or vulnerability, Attacks on browser-based content sniffing, Secure Content Sniffing for Web Browsers or
How to Stop Papers from Reviewing Themselves.


Are there known Windows viruses which are capable of ARP spoofing?

ARP spoofing is tricky to do blindly. If the virus just starts ARP spoofing, there is no way to tell just how many computers might send traffic to the infected host, and DoS the infected host. So, most ARP spoofing attacks choose a victim to attack. A blind virus is not going to be able to do this intelligently. It is also difficult to blindly extract value from this act. So, no, it is not likely that one will get a virus that ARP spoofs.

But, if the "virus" is actually a RAT, then it gives control of the victim to a user who can make intelligent decisions. But I'm not sure if this falls into your definition of "virus". There are many, many RATs of many different kinds that can infect every kind of computer. So, in this definition, there are many and they are very widespread.


Practical non-government uses of Biba, Bell-LaPadula, etc. models

Generally speaking, those models tend not to be used exactly as-is.  The problem is that very quickly "everything becomes low", because everything depends (through some long chain of dependencies) on something you got over the Internet.  As a result, you got a lot of false positives or annoying dialogue boxes.

However, there are widely-used systems which are partly based upon the ideas found in those models.  You mentioned Windows.  Another example is SELinux, which is widely deployed on Fedora Linux machines.  A third example (more loosely related) is taint tracking, which is used to detect vulnerabilities and protect systems against data-driven attacks.  Taint tracking is conceptually to the Biba model: untainted data is "high", tainted data is "low", and anything that depends upon tainted ("low") data is also tagged as tainted ("low").

So while the models have largely proven to be unworkable in their originally envisioned form (for general-purpose computing), less restrictive variants have had some impact.


What is the severity of a fake certificate?

Is a fake certificate only useful in combination of a DNS hijack (or any other method that will point the fake cert's target domain to a fraudulent IP, e.g. modifying hosts file etc?)

... or man-in-the-middle by means of ARP or routing table changes by an ISP. In any case, some redirection that is undesirable for the end user must also occur.

The area of concern is that your browser trusts the issuing authority and the issuing authority sent a certificate to somebody who isn't the controller of the domain. Particularly with some governments, this can be very concerning as they can silently redirect anybody in their country by twisting an ISP's arm.

It's for this reason that I argue that DNSSEC should be used as another authentication channel for certificates to show that whatever was issued is also accepted to be published by the domain owner.


How Tor, Privoxy, Vidalia and Polipo are getting together?

Privoxy is a proxy server that (pay attention here) uses application-layer filtering. HTTP traffic passed through Privoxy will have certain privacy-oriented rules applied to them. For example, Privoxy will block ads, detect and disable click-tracking scripts, disabling pop-ups, etc.

Polipo, on the other hand, is a caching proxy server which is perfect for slow networks. Tor is such a network. Polipo can enhance the appearance of the network performance by using caching and other trickery.

Privoxy and Polipo are not competitors; they have very different purposes. In fact, you can use them together to get the privacy benefit of Privoxy and some performance enhancement by Polipo. This can be done by chaining the traffic between them.


Are these snort alerts false positives or attacks?

It is most probably a false positive like mentioned here
https://community.spiceworks.com/topic/1514894-snort-attempted-command-buffer-overflow-smtp

you should provide more details such as is the traffic originating interally or any other logs you have.


How to rate a CVSS score for a vulnerability on an identity provider

I'm not a super expert on CVSS calculation, but I'll post an answer and see if I get corrections in comments.

I think you evaluate the impact on the affected component component itself, regardless of what else is connected to / relying on it (that's what the "Scope" CVSS metric is for).

From the CVSSv3.1 spec:

  2.3.Impact Metrics

  The Impact metrics capture the effects of a successfully exploited vulnerability on the component that suffers the worst outcome that is most directly and predictably associated with the attack. Analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieve.

Let's take a look at the Impact Metric definitions according to the NVD CVSSv3 Calculator.

  Confidentiality Impact (C)

  This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

If this vulnerability allows you to gain unauthorized information from the identity provider component? Then this is certainly yes.

If not, then it really comes down to whether it's a "predictable reasonable final outcome" that Service Provider (SP) / Relying Party (RP) is going to have a confidentiality issue due to a failure of the IdP's authentication.

Kinda unclear to me also.

  Integrity Impact (I)

  This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

If this vulnerability lets you bypass the authentication mechanism, then information from the identity provider is no longer trustworthy. Almost certainly High (I:H).

  Availability Impact (A)

  This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.

Can this vulnerability be used to crash the identity provider, or otherwise cause it to be unavailable for legitimate users? Will it predictably cause availability issues in the SPs / RPs that rely on it?

In the end, I'm not sure that I have answered your question at all haha.


Did Mt. Gox lose their own or customers bitcoins?

OK, first a correction:

  If one can only give away their bitcoins by providing their private key,

No. You send bitcoins to another party by signing a transaction that transfers the bitcoins from your address (controlled by your private key) to another address (controlled by the other party's private key). Actual private keys should never be exchanged, ever.

What happened with MtGox is that their customers willfully transferred bitcoins to them in order to trade/exchange on their platform. By doing this they essentially gave MtGox full control of the bitcoins, and MtGox lost them.

So yes, MtGox lost their customers' funds.


Reaver returns different WPS PSK and AP SSID each time it finds correct PIN

This behavior is very similar to WIPSs (Wireless intrusion prevention system).

  A wireless intrusion prevention system (WIPS) is a network device that monitors the radio spectrum for the presence of unauthorized access points (intrusion detection), and can automatically take countermeasures (intrusion prevention).


Tool or Process to check for AES-NI support on processor?

On Linux systems, do:

grep flags /proc/cpuinfo

This will give, for each CPU core, the list of what that core can do. The AES-NI instructions are there when the flag "aes" appears in the list of flags. See this page for a list of possible flag values.

On macOS, do:

sysctl -n machdep.cpu | grep -i aes

If it doesn't find anything, this machine doesn't have AES-NI.

For Windows, see this question on SuperUser.


OpenSSL ECC key - Additional byte in DER encoding for one curve

Although for secp224k1 the size of the underlying field, and thus point coordinates including a public key, is (slightly) smaller than 2224, the order of the curve group, and thus the size of a private key, is slightly larger than 2224 and nominally requires 29 octets to represent -- even though the probability of d chosen uniformly at random per spec actually needing 29 octets is so small it probably won't happen during the Earth's lifetime. Quoting SEC2 from http://www.secg.org (since it's free and X9.62 isn't) minus formatting I can't reproduce without MathJax:

  2.3.1 Recommended Parameters secp224k1
  The elliptic curve domain parameters over Fp associated with a Koblitz curve secp224k1 are
  specified by the sextuple T = (p, a, b, G, n, h) where the finite field Fp is defined by:
  p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFE56D
  = 2224 − 232 − 212 − 211 − 29 − 27 − 24 − 2 − 1
  The curve E: y2 = x3 + ax + b over Fp is defined by:
  a = 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  b = 00000000 00000000 00000000 00000000 00000000 00000000 00000005
  The base point G in compressed form is:
  G = 03 A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E
  B6B7A45C
  and in uncompressed form is:
  G = 04 A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E
  B6B7A45C 7E089FED 7FBA3442 82CAFBD6 F7E319F7 C0B0BD59 E2CA4BDB
  556D61A5
  Finally the order n of G and the cofactor are:
  n = 01 00000000 00000000 00000000 0001DCE8 D2EC6184 CAF0A971
  769FB1F7
  h = 01

See https://github.com/openssl/openssl/commit/30cd4ff294252c4b6a4b69cbef6a5b4117705d22#diff-a51596fb2f3b3650972f0f650cdcf115 -- although this was initially implemented wrongly, using the field size ('degree'), and subsequently fixed to use group order (not directly in ec_asn1.c but by calling to EC_KEY_priv2{buf,oct} in ec_key.c) AFAICS only in 1.1.0 up.


What should I do if my Android was hacked?

You deal with a phone infected with malware pretty much the same way you deal with a computer infected by malware - you do a complete factory reset, wiping everything from the phone and reinstalling the OS. Don't expect that you will be able to surgically remove the malware. Most likely you will not, or at least you will not know if anything is left.

You may want to avoid using the phone before you do this, and especially avoid connecting it to anything else. You may also want to change any passwords you have entered on the infected device.


There seem to be some misunderstandings. It might help to clarify what some things mean first, even if it becomes a bit long.

Lets start with some things a usual home router (in reality a combination of several independent things) can do for you. Very simplified:

Being a modem

"Translating" data from your computer to/from something that goes over the cable that leaves your house
These types of signals are usually not the same, because of a) other applications on the same cable (phone, etc.etc.) which means your signal must conform to the kind of signals used by them, and/or b) different technical requirements (like having enough "power" to be transferable over several miles).

Being a switch (if you can plug in multiple computers - and completely independent of any outside world internet connection)

Being able to distinguish these computers (with help of MAC addresses).
Making it possible that one computer sends something to another, leaving it to the switch to pick the right destination.
MAC addresses are completely local, not suited for worldwide addressing.

Being a router

Being able to understand IP addresses (which are more than local), and deciding with them where something should be transferred
Assignments of IP addresses can be like "this one IP belongs to this one MAC here locally", "this other MAC has this whole range of IPs" (maybe because the MAC is another router with several computers), or "all unknown IPs should go to there" (eg. to the modem and then the outside world, leaving it to your provider to find the destination).

Offering NAT

Instead of transferring data from the local computers to outside using the computer's original IP, the router sends the data to the outside as if it is from the router itself. Incoming responses go to the router (the outside doesn't know the computers behind it), and the router relays it to the right destination.
Originally this was because there is a limited amount of IPs - all computers using their own (which must be unique worldwide) would be a problem. Now only routers need their worldwide IP.
Between routers and local computers, a completely separate numbering scheme is used - still IPs, but ones that are never seen outside of your local network.
Unintentional side effect: If someone "outside" wants to hack your computer, he/she must either hope that your computer contacts him first and then send a malicious response, or hack your router first to be able to send data directly to your computer. Because, as described, your computers don't even have global IPs - the only possibility to get data from the outside is if the router knows they want it. ... Of course in an ideal world your computer can't be hacked - but most can, and making them reachable directly for everyone in the world is indeed a risk.

Firewall

Something that filters/censors any data it gets.
There are many kinds of criterias when to filter (of course not all FWs support everything), eg. "allow only if it is from/to these computers", "allow only emails but not browsing", "allow nothing where the word Frog is transmitted", etc.etc.
In a non-NAT environment, a simple use case also would be to "allow only incoming things your local computers have requested before" (or in other words, only outgoing connections). As having the computer directly reachahble by the whole world is not good, this can be the same protection as NAT is. Especially useful as with IPv6 there is no shortage of IPs anymore, making NAT not needed.

So, to repeat a part: Allowing others to reach your computer even if you didn't go to their website etc. is not good, and a major security risk in todays internet. Having a LAN with NAT automatically protects from this. A firewall can protect too (most home users use their firewall only for this).

You explicitly told the technican that you don't want a router - meaning you have modem but no routing and no NAT, and you can only connect one device to the internet (even if there can be multiple plugged in - maybe you have a router-modem combination where the router is turned off per configuration).

As it is unlikely that a builtin FW will still work like this, you are reachable by the whole world - bad for security. If there is no reason to be reachable, don't do this (eg. web servers have to be, but there should be also continous effort to keep them secure).

What you can do if you want this protection: Ask them to enable the router again (or give you one if the device you have is a pure modem), or buy your own router to put it between modem and computer.

About your neighbor - if we understand "LAN" as the things inside your house, there is no way to sniff that without having access to the cables (I understand you don't have Wifi?). (This fact is independent of "router or not").
But it doesn't have to be inside of your house - as you have only one computer, all network usage will be to the outside world, and there are plenty possibilities. For example your provider. ... About your neighbor, if the provider is not completely bad he shouldn't be able to get access to your traffic data.
In any case, using HTTPS wherever possible goes a long way to avoid sniffing.

Finally, about wired internet plans - your connection to from the modem/router outside can be over cables (telephone cable, coax, ...) or not (cellular, satellite, ...). Having Wifi or not is completely independent of that - Wifi is about the part between you and the modem/router.


Do technical advice sites sometimes link to malware, and if so, how should we properly research errors?

In my experience, though it is uncommon to find malware embedded in these fix it scripts and registry keys, it does happen.

As such, I would highly recommend most users getting these types of patches and assistance from the vendor directly.

An experienced security professional could download the fix it script or registry key, open it and view it first, before applying it, to determine its safety.  But even then issues can be missed.


Can my Root, Intermediate and SAN certificates have the same serial number?

In general, each certificate should have a unique serial number (unique from that issuing CA). This is because if you ever need to revoke them (ie put them on a Certificate Revocation List (CRL)) you will need to reference them by serial number on the CRL.
In your case, the End Entity certificate is issued by the Intermediate CA and is the only cert signed by that CA with serial number 00, so as long as you're not planning on issuing any more end entity certs, you don't have a uniqueness problem there. However both the Root cert and the Intermediate cert are signed by the Root, so you can not revoke your intermediate cert without also revoking your root.
Maybe that's not a thing you care about, but using a random number is definitely best practice. As an example of best practices, the CA/Browser Forum's Baseline Requirements for public HTTPS CAs says

CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.


According to Wikipedia

  Upon installation, it creates a user account using one's phone number as the username

  ...

  A 2012 update now generates a random password on the server side.

  ...

  WhatsApp follows a ‘store and forward’ mechanism for exchanging messages between two users. When a user sends a message, it first travels to the WhatsApp server where it is stored. Then the server repeatedly requests the receiver acknowledge receipt of the message.

The key is to notice that in all of this the App doesn't actually use telephony services, so it can't use your phone number in the traditional manner. Also note that when you install the app you're effectively just creating an account where your username happens to be your phone number. Think about it like if when you signed up for stack exchange they just assigned you a random number rather than letting you pick a name.

As to why you didn't have to reverify your account via SMS, if the iOS backup also backed up the app's data and configuration then the app would have everything it needs to connect as your account.

In terms of security - since account-password is the way just about every verified service works this method would be just as secure as your app's configuration files. One could argue it's more secure than other services since the user doesn't know their username/password and thus cant give them away (if you believe in security by obscurity that is).


How to understand a single packet embedded with multiple requests?

.. is it mean one HTTP request packet have multiple HTTP requests?

There is no such thing as a "HTTP request packet". This is about a  single TCP packet containing a payload and this payload consisting of multiple HTTP requests. Usually HTTP is working by sending a request and waiting for the response but with HTTP pipelining it is also possible to send multiple requests at once (no matter if within a single TCP packet or using multiple TCP packets) and then reading all the responses.


Does adding two-factor authentication by OTP really make KeePass more secure

No. Security remains the same + extra cognitive overhead.

Presumably the plugin uses OATH HOTP where the KeePass file or master key is re-encypted after each access with the next one-time-password.

However to generate the next password on the device, the plugin would require either a secret stored on the device or the normal password for the KeePass file.

Security from a one-time-password comes from two parties knowing the same key and counter - HOTP(Key,Counter) - while an attacker doesn't know the key. If the attacker has access the device storing the KeePass installation and files, the security re-collapses to the security of the normal password on its own. If the KeePass file is still interoperable with other KeePass programs, then you gain nothing from using a one-time-password in this fashion.

One-time-passwords work well for server authentication because both client and server end-points are considered secure and the attacker needs 'something you own' as well as 'something you know'. If the attacker has your computer, then they now have 'the thing you own'.


How do new security and cryptography techniques/protocols avoid the chicken-and-egg problem?

The bootstrap process is achieved when people do use the new algorithm. To gain trust in the algorithm's strength, it must have exposure. Exposure is achieved through either formal competitions like for AES, or, more recently, for SHA-3; or it is achieved through the algorithm being widely deployed and becoming an interesting target.

Open competitions are tricky: in order to claim a good level of exposure, the competition must have attracted a lot of researchers for quite some time, and that's not easy because academic researchers rarely work for money, but for glory (or at least what passes as fame in academic circles). It needs a powerful sponsor. NIST is good for that, and did it well for AES; arguably, SHA-3 was also a success, although the end of the process has a somewhat bitter aftertaste (because NIST is currently deciding what tweaks it will push into the winner algorithm, and such tweaks undermine the whole trust building process). There were other "competitions" such as eSTREAM for stream ciphers; it did get a fair amount of exposure, but "not as much" as AES or SHA-3. For password hashing, there is an ongoing competition which is at the candidate collection phase (until January 31st, 2014).

Wide deployment occurs when some organization decides to deploy the algorithm "early", because the new algorithm offers a decisive usability advantage (e.g. a signature algorithm which has very short signatures, or requires very little computing power), or because the powers-that-be in that organization feel (wrongly) that "newer is better" and want to be early adopters of the new nifty cryptographic technology. For instance, SSL was widely deployed because it filled a niche which was not otherwise covered, even though the protocol was really not up to known "good practices" at that time (SSL 2.0 was quite bad and lead to a complete rewrite as SSL 3.0 less than two years afterwards).

Thus, as cryptographers, we MUST recommend that people refrain from using algorithms which are "too new" and "insufficiently reviewed", but we are also quite happy that some people do the "wrong thing" and do not refrain; it gives the exposure which is necessary for the bootstrap, and also ensures that cryptographers won't get out of job (a research article which demolishes a poorly-specified protocol -- WEP, I am looking at you -- is still a published research article). The best we can do, in the meantime, is to prepare: cryptographers can design algorithms based on rational constructions which thus stand a reasonable chance of surviving the deployment. For instance, when bcrypt was first described, it had not (of course) been exposed in the wild for several years, but at least the authors tried to follow some justified rationale, and the algorithm turned out to be "mostly good".


Logging connections to hardcoded IP addresses

Using native functionality in Windows, the best method would be to enable Audit Filtering Platform Connection. It can log all connections allowed by the Windows Firewall. The following is an excerpt:

  Audit Filtering Platform Connection determines whether the operating
  system generates audit events when connections are allowed or blocked
  by the Windows Filtering Platform.

  Windows Filtering Platform (WFP) enables independent software vendors
  (ISVs) to filter and modify TCP/IP packets, monitor or authorize
  connections, filter Internet Protocol security (IPsec)-protected
  traffic, and filter remote procedure calls (RPCs).

  This subcategory contains Windows Filtering Platform events about
  blocked and allowed connections, blocked and allowed port bindings,
  blocked and allowed port listening actions, and blocked to accept
  incoming connections applications.

The downside with enabling this auditing is the audit volume will be HIGH. Can't stress that enough.

From here you'll need a custom script or some other means to aggregate the DNS query logs and the Windows Filtering Platform (WFP) events to determine what IP addresses were accessed without performing a DNS lookup.

For example,

Build list of all unique destination IP addresses for a host.
Search DNS replies to that host for IP addresses from #1.

What you're aiming to achieve is difficult. Some application may use hard-coded IP addresses or other means to resolve a destination (NetBIOS, WINS, LLMNR, Bonjour, etc.). Depending on your environment, don't be surprised to find a number of false-positives during your investigation.

As an alternative, place a network monitoring device in front of the target system(s). Products such as Zeek (formerly Bro), Argus, SiLK, or RITA would all log network connections, in addition to other interesting data, and don't cost any money. In some instances they will even log DNS queries. This alternative approach will still require a custom script to aggregate the DNS query logs with network connections to find which were established without using traditional DNS.


Is it OK (from a security perspective) to add only the the server cert to client trusted store with out adding the root Certificate in SSL?

Yes.  What you are asking about is often called "certificate pinning".

When you add a signing cert or root cert to your trust store, you are saying, "I trust all certs signed by this cert".  By adding the cert to the client's trust store, you are saying, "I explicitly and directly trust this cert".  In the former, you are implicitly trusting many certs, in the latter explicitly trusting exactly one cert.

There are some things to be aware of.

Some clients might not support this model.  If it's third party software, you'll want to test before you deploy this way
you'll need a secure way to deliver the cert to your client. This mechanism has to be trusted and must prevent other, un-trusted certificates from getting onto the client. Web Browsers get their default certs from the browser manufacturer, your OS manufacturer,or from your IT department. If you're going with web browsers and it's for users outside your company, this will be much harder - they can't just connect to your non-root-chained site get a certificate warning and add the cert to their store, as they will have no way to know if they're connected to a malicious site.
you'll need a secure mechanism to rotate the certificate when it expires or is compromised.
testing your client app may be challenging. You'll want to connect your client app to a test server, which means you'll need a way to set your client app to use the test server's certificate.

You also get some advantages over using root or signing certs in your trust store

if it's your custom app and nobody else's certs are in the store, you get a guarantee that clients are only communicating with your servers (until someone replaces the client's trust store)
root/signing certs use certificate revocation lists for cert revocation, but nobody monitors those. Your approach will simply replace the cert in the client trust stores to effectively revoke a compromised cert.
there is a smaller attack surface. In the web browser standard model, an attacker could go after any trusted root, any explicitly- or implicitly-trusted intermediate cert, or the leaf cert.  With cert pinning, only the leaf cert is a target*

*I intentionally ignore attacks against the software, against weak crypto, and against client trust stores, since that's all common to both scenarios.


That depends of that packet is encrypted. If you happen to capture a multicast packet sent over an open WLAN, then you can read it without problems.

If the packet is encrypted, then you need the key in order to read the packet successfully.

The reason why you can in general use multicast, is because of the OSI layer model. It simply does not matter to the higher layers how the lower layers are implemented. As such, if a network uses mixed clients (some wired, some wireless), multicast and broadcast still need to work.


--format=md5 option I think is what you are looking for, here are some pretty decent guides on options

http://www.openwall.com/john/doc/OPTIONS.shtml

http://www.liatsisfotis.com/2012/12/crack-passwords-using-john-ripper.html


Yes. I'm assuming that you are building your query with string concatenation.

Let's take

SELECT * FROM [Database].[dbo].[#tableName#]

If you replace #tableName# by employee]; DELETE FROM [Database].[dbo].[employee you then obtain 2 queries

SELECT * FROM [Database].[dbo].[employee];
DELETE FROM [Database].[dbo].[employee];

There is only one way to fix SQL Injection : use parametrized queries.