Terminology - entry point, data source, sink

Source and sink are used in a data flow analysis. The source is where data comes from, the sink is where it ends. With regards to application security, source and sink are frequently used for taint analysis.

Data is "tainted" if it comes from an insecure source such as a file, the network, or the user. Any data that touches data also becomes tainted. If tainted data is ever passed to a sensitive sink, then static analysis will flag an issue. For example, if user input from a web form is printed, unescaped, into a log file, then a static analysis tool will report a log forging vulnerability.

I think that entry point is a more general term that refers to the place where a program or event handler begins execution. For example, the main() function of a C program or the doGet() function of an HttpServlet. This is the starting point for data flow analysis.


One GPG key with multiple user identities for my career?

I'd first check the organization for their policies. They may not even allow GPG.

I'd use multiple GPG keys, one per organization. An organization may require you to hand over your GPG keys to get to the data encrypted with it. If you change jobs or identities within an organization then you might want to use sub-keys.

And, as usual, always keep your private and company life separate - certainly when it comes to key material.


While there are still Drive-by-Downloads attacks which exploit vulnerabilities in the browser itself most of the web-based attacks today are different. This is because Drive-by-Downloads got harder since the major insecure technologies (ActiveX, Java, Flash) got mostly banned and the browsers themselves got more robust against attacks too.

The major attacks today are probably done by tricking the user, i.e. phishing.
There is for example credential phishing done (usually linked from mails or other messages) with look-alike sites or sites which promise import information after login. There are sites for (usually illegal) streaming or download of videos which claim to require some plugin or software update in order to access the content. And there are sites which create windows or popups which look like system error messages in order to trick users into downloading some fake antivirus or call some fake Microsoft hotline or similar.

There are also seemingly innocent browser plugins or extensions which later change the behavior into malicious ones, either because this was intended from start or because the ownership of the extension was transferred to some shady party.  Since extensions are usually updated automatically this attack is based on using the initial trust a user had in the extension for silently adding malicious behavior.

  Is it due to ignorant browser users?

While it would be simple to just blame the users for their ignorance it would not be fair. One cannot expect the average user to have lots of experience with detecting attacks. Most users are unable to properly cope with all the different web sites with different user interfaces and different behavior, sporadic error messages from web sites and from the operating system. They are used to get nagged by the various software they have to install updates before they can continue. All they want is to get things done. And in most cases they can do this by ignoring error messages or choosing the recommended option in a dialog they don't really understand.  The attackers can therefore rightly expect that enough users will do almost anything just to continue, especially if this involves just to click some button or to quickly install some software - since this is what they are trained to do anyway.

Educating users and keeping them alert can only go so far. While this might shift their behavior to be more suspicious this also results in being more suspicious to perfectly benign login prompts, dialogs or update requests, since it is often impossible for the average user (and sometimes for experts too) to properly distinguish good from bad. This therefore usually leads to accept even unexpected behavior in order to proceed since in most cases it is actually innocent.


Interesting idea, but there are a number of reasons why this does not add as much security as you hope.

First, software based keyloggers typically have luxury of being able to not only receive what you type, but also see what you see. In particular, if a bank introduced such a system then a short while later malware would appear that logged what you typed and what the modification instructions were. This is an on-going arms race situation with banks and malware developers right now, which is why we have "please enter select the 2nd, 3rd and 7th character of your password".

Second, you'd also have to significantly increase the allowable number/frequency of incorrect password entries, making brute forcing easier.

Third, users typing in their password with this scheme would be much easier to shoulder-surf, as they would be typing their password much more slowly.

(The question already captures the fact that a keylogger would already have the majority of the password - any guesses what this user's unmodified password was? "PassQword1" ?)

I think you already capture the main downside - usability:

It wouldn't work with many password saving devices, encouraging you to use a simple password you could easily remember (and hence could easily guess).
It would frustrate and hence drive away users (unless it was ubiquitous - but early adopters would have to overcome this barrier).

Given the limited security benefit and significant usability impact, this scheme would probably not be widely adopted (which, of course, would increase the security benefits to anyone who did adopt it - there would be unlikely to be any malware designed to read the instructions; nor tools to reverse the modifications).


John the ripper not displaying cracked password

You're not seeing them because they're invisible. :)

aad3b435b51404eeaad3b435b51404ee (LM) and 31d6cfe0d16ae931b73c59d7e0c089c0 (NTLM) correspond to an empty password.

This blog post explains in a little more detail, with command line examples to show how an empty password is hashed.


why gmail's phone verification code not encrypted

Google Authenticator is based on the Time-based One-time Password Algorithm (TOTP).

http://en.m.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

The reason that it would be difficult to brute-force is because the tokens change every 30 seconds. So after every 30 seconds of trying to brute-force, the target moves, and suddenly the token can by any 6 digit number again. This also means that it might change to a value you have already tried, so its possible to exhaust the entire key space without finding a valid one.

However, this in no way means that its impossible or even infeasible if no protection against brute-force is present. For example, if you were somehow able to send 1,000,000 authentication attempts in 30 secs. Even trying 1000 random numbers every 30 seconds, you might slowly get there (re: @domen's comment). However, even a simple 1 second delay on re-authentication attempts per user would render this impractical. As such, some kind of brute-force control that prevents this many authentication tries within 30 seconds is imperative.

At the very least I think Google's own login process introduces a CAPTCHA after unsuccessful attempts which would slow the process down too much and render the attack infeasible.


Preventing tracking in browsers by setting HOME directory

On Unix systems, the user home directory is associated with the user account and any application can "sense" it by using getpwent(). It so happens that there is a long-standing tradition, in Unix applications who want to learn the user's home directory (e.g. to read or create configuration files), to first look at the HOME environment variable and use its contents as home directory, if that variable is defined, falling back to getpwent() only if there is no such environment variable.

From your experiments, it seems that Firefox and Chromium honour that tradition.

However, plugins within the browsers may behave differently. If you want to avoid transporting state from one browsing session to the next, you may want to use the private browsing features of Firefox (it is called Incognito mode in the Chrome world). These features may be more thorough than simply moving the home directory around.

Be advised that "private browsing" or anything similar prevents tracking only in a loose sense -- cookie-based tracking is still feasible during a session, and cookie-less tracking is highly feasible too (see this demonstration).


How to reset the BIOS without access to the motherboard?

Most locks ( take a picture of it and show it here or on https://reddit.com/r/lockpicking/ ) can be picked, even those annoying tubular cylinders I sometimes see on PC cases. You would only need a short and medium hook, and a tension tool (Sparrows sells one for tubular locks). Pick it by depressing pins, and pass-over all pins 3-4 times. Also google the lock, and determine if it can be bypassed with reaching tools (bent metal rods, paracord).

Do you know for a fact that you can clear the password by removing the 3V battery?  Often it is in EEPROM on modern machines, so you must then - if that's the case - access the harddrive and install/overwrite binaries.


Does perfect forward secrecy work with group chats or chat history?

I think you mean Perfect forward secrecy, which WhatsApp does support in its end-to-end encryption. PFS is difficult for chat apps, because of the uncertainty in the connection, and is the reason many chat apps just ignore it.

In normal PFS (like TLS or SSH) an ongoing connection is established and the keys are recalculated every so many bytes or minutes.  Chat apps cannot acknowledge a message (or any data) was received. In fact, the other end of the channel may never have sent any data your way, or was just offline the whole time. In any case, you as the sender should be able to secure the messages that you sent, regardless of the other end.

To overcome this entire problem protocols such as OTR en Axolotl use prekeys. These prekeys are pre-calculated Diffie-Hellman (or EC like Curve25519) keys. It is common to calculate a few hundred keys in advance. All of the public keys from these pre-calculated keypairs are send to the relay (chat) server, and advertised together with your public identity key (the public identity key is really your 'name' towards others). Now that the public prekeys are on the relay server, anyone who want to send you a message can just pick one of your prekeys and calculate the shared secret.

The message is then encrypted and authenticated using the shared secret and send to the receiver together with the prekey id. Once the receiver pulls the message from server, it can decrypt the message with the corresponding private prekey. A new prekeypair is generated and send to the server to take its place. This system goes on forever.

Both sender and receiver have to keep track of all their prekeys still in use. This entire algorithm is known as the Double Ratchet.

Apps using Axolotl:

WhatsApp
Google Allo
Facebook Messenger
Signal
Viber (claimed)

Update

The protocol is self healing because every message is encrypted with another key. This key is no longer known when the message is decrypted, and the message itself is stored in the local app database. Here comes the trick: the messages are not chained in order, so at best one prekey (one message) is compromised. This has no effect on the other messages. Every message is encrypted with another key (Perfect secrecy). The messages itself do not depend on each other and thus an attack on the last message does not give the attacker control over future communication (Future secrecy). Note: The protocol has some disadvantages as well, like messages orders, or lost messages.

Update 2: Group chat

From the protocol point of view, there is no such thing as a 'group chat'. It is just the same message send multiple times to people, like emails can be send to multiple recipients as well. Each of these messages is encrypted with the receiver's prekey. For example, if the group contains a total of 4 people, including you, then the same message is send 3 times (technically only send once, containing 3 messages) to each of the group members. Therefore it is required that each message is signed and encrypted with the shared secret between you and the receiver. Note: The latest version of the TextSecure protocol can optimize this process somewhat by encrypting the message once, and sign it multiple times. There is a proposal to introduce temporary group keys for larger groups. To my knowledge this has not made its way into WhatsApp yet.

If a new user joins the chat, there is no history for that user since chat messages are kept on the local device (obviously). See this as an advantage, every user of the group is responsible for keeping the messages private. A synchronisation solution will; 1) increase the attack surface, 2) increase complexity of the cryptosystem and 3) move ownership of messages around.


Is OAuth more secure compared to API Keys

OAuth services like Google or FB, or self made OAuth services based e.g. on Keycloak provide very often following features:

Possibility for the users to reset their passwords, where as it is hard or impossible to reissue an API key.
Password reset can be done quickly, where as re-issuing f an API key may take days or weeks, depending you capacity of your customer support team.
Passwords are stored in a hashed form. If password database stolen, it will not reveal passwords and will not help attacker. Where as when the database with API keys is stolen, the attacker can use all API keys.
If the database with API keys is stolen and user accounts abused, it will be very hard to know where the problem is. You will suppose users didn't care about keeping their passwords safe. Users will suppose you have security problems on your side.
The OAuth service can provide 2FA, where as with API key there is single authentication factor only.
In case your application logs requests, also API keys can be logged. Via logs and their backups more people can know the API keys on your side. You need extra efforts to make sure that API key is not written to the log. Where as in case of OAuth your application only obtains a token containing user ID. Thus it is safe to write the whole request to the log.

But...
All these advantages will be really advantages, if you use some quality OAuth service. If you use the strange approach that you described, with passwords hardcoded in config files, there will be no big difference between two approaches.


Does write permission over a windows service always imply privilege escalation?

I understand that this works only because Localsystem has no password
  set.

Not correct. The misconfiguration here is the missing write protection for the service object. It has nothing to do with the password.

  So, does this mean that I can own any system just by having write
  access to one service

Yes. This is a classical privilege escalation vector on Windows. Services must be write protected for non-admin users.


Yes, provided the devices are reachable on the network they can be scanned.

The accuracy of the results (e.g. fingerprinting) is dependant on the platform, software version, running services and configuration.

Example:

$ nmap -A -T4 10.1.1.1

Nmap scan report for 10.1.1.1
Host is up (0.020s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE VERSION
23/tcp open  telnet  Cisco router
Service Info: OS: IOS; Device: router

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.21 seconds


How can Telegram find my phone number on iOS 11 after uninstall?

From my understanding iOS 11 doesn't delete the keychain keys for an app when you delete the app, I'm talking about the keychain on the device so cloud settings won't affect this. No other apps can access another app's keychain so you don't need to worry about it from a security point of view but it's entirely possible the app is using the keychain store to persist the phone number information.


Can the USB standard be altered to prevent the "firmware attack"?

I think this WIRED story is way out of proportion. While it's true that a USB device can act as a keyboard, or mouse, or a hub with both, it would only act with the privileges of the current user, and the attack wouldn't be stealthy: the device would have to open a command window, type commands, etc. with no way to read commands output.

You absolutely don't need to assume that a computer is potentially compromised just because a USB device was attached to it once.

The proposed solution "only allow a specific brand" is ridiculous too (how can you reliably measure that when the USB stick is lying?). A much simpler, more robust solution would be to block additional keyboards and point device, unless the user confirm that a wants to have two keyboards or two point devices.

Being able to reprogram any device firmware without a user manipulation (good old jumper...) is still a serious security issue, obviously.


How to trace someone's(hackers) IP who made a lot of request on my website?

To find more information about who owns an IP address you can:

use the traceroute (unix) / tracert (windows) command line tool to find out which routers are between them and you.
check a GeoIP database to get a very approximate geographical location of that IP address block.
use the ripe database to check to whom the IP address block is registred, which will usually lead you to their ISP.

The exact identity is only known to the ISP which will usually only reveal it when they get a court order or similar official request from law enforcement, which requires that you report it and that they find the case relevant enough to act. Unless you actually lost data or have other tangible damages, they are unlikely to act, though.

Also, when the attacker knows what they are doing, they will use various anonymization tools to hide their identity. There are various methods to make deanonymization of internet users very difficult (which are explained in greater detail in lots of other questions on this site, so I won't go into further detail). Following the IP will likely lead you to just some hapless internet user who got his machine infected with a botnet trojan.

But acting after an attack is really not what you should be worrying about. What you should be worrying about is making sure that such attacks won't work on your systems.

Scans like that happen all the time. When you put a webserver online it usually only takes minutes until people start hammering it with all kinds of exploits. If you aren't confident in your security, you shouldn't be doing this.


Do search engines give searcher's IP address to sites that come up in search?

As far as Google is concerned, they only share non-personally identifiable information with their partners (publishers, advertisers or connected sites).

From Google's Privacy Policy:

  We may share aggregated, non-personally identifiable information
  publicly and with our partners – like publishers, advertisers or
  connected sites. For example, we may share information publicly to
  show trends about the general use of our services.


Is it possible to use pass, the command line PW manager, without leaking details? Does it matter?

Or if an attacker can access this information, should you just assume that they've already pwned you enough to know it?

I think you already got the idea here. If you can't trust your own machine, it doesn't matter how the password manager is implemented, you're already screwed.
You can add a second layer of authentication in various ways. On local machine, you can use full disk encryption to protect against someone swiping your information off stolen machine. If you're syncing your pass password files, make sure you set the sync permissions is private. If you don't trust your syncing service, then you can add another layer of encryption that encrypts metadata like ecryptfs or sync a disk image.


For example an application loading a keystore using a non-FIPS provider, is it something forbidden or am I confused on this?

I think the definition of FIPS might help: Federal Information Processing Standard. The key here is Standard, much like a W3C technical report, ISO standard etc. You are not under any obligation to conform to these standards. Just look at web browsers. You are more than welcome to do your own thing. It isn't necessarily wrong not to conform to these standards.

But, there is always a reason for these standards. For one, conforming to them means you ought to be able to interoperate with other conforming software. For example, take C99, the ISO C standard. Any C99 code I write ought to work on any C99-compliant compiler.

In the case of cryptography and information security, I would really advise following these standards. For starters, they define how an algorithm or key store should behave, meaning not only interoperability but usually a reasonable level of security testing too. In other words, you know your environment (that you've just implemented) ought to not contain any weaknesses, library, OS and environment issues non-withstanding.

As an end user, you know your FIPS-compliant key store should give you some assurance of security, as opposed to whatever storage format Joe Bloggs dreamed up. You should find your software has some level of interoperability (for example, different standard, but many programs can read PKCS#11 keys and OpenPGP keys).

So it isn't forbidden per se, just really highly recommended. If you're choosing software, I would favour something that follows FIPS, PKCS or OpenPGP.

Another point to mention here is that FIPS, RFCs etc often define a usable part of what's out there (by way of a standard). Rijndael != AES, for example. The Rijndael cipher supports many more key lengths and block sizes than AES does, but simplifying that to a certain subset means it is simpler to implement, and that is exactly what AES (FIPS 197) does. What would happen if you said "implement Rijndael" is that many developers would not implement certain sizes due to time constraints, pure laziness or whatever. Software using the exact same core algorithm would then otherwise be incompatible.

So as a final answer, no it isn't forbidden, but it is highly recommended. Mostly, it is about interoperability, but there will be some level of assurance ("we're not recommending a broken cipher" (in current FIPS as opposed to retired ones)) too.


Preventing access to file for process running as root

There are two solutions:

Use a tool like SELinux. It's designed specifically for this particular task, but it takes some real understanding to use effectively. You'll need more than just a few pointers, you need to go read and understand the documentation.
Use a virtual machine. The "root" program runs in its own VM on your server and can't see anything outside its own little world.


Why is the Diffie-Hellmann exchange not enough to authenticate the communication partners in IKE_SA_INIT?

The plain ephemeral (new key every connection) Diffie-Hellman is unauthenticated. You perform the DH operation using newly created keys on both sides and establish a shared secret value you can use to encrypt the communication. But you do not know who you're talking to. The other side can be anyone. You have no way to know, except if you trust the source IP address in the packets (you shouldn't).

TLS, SSH and IKE perform authentication after DH to establish that you are talking to the server/client you meant to talk to. This is called "authenticated Diffie-Hellman".

Usually the client ensures the server is not an impostor by requiring the server to produce a new asymmetric digital signature (and then verifying the signature), thus proving the server possesses the private key matching the public key the client already has (or which the client receives in a certificate and checks the certificate is signed by someone the client already trusts, etc.).

The server may require the same from the client, or some other form of authentication (or no client authentication at all as is common for TLS but not common for SSH and IKE).

Static DH (long term keys) can be used for authentication. For example, the client may know the public key share of the server, and the server may know the public key share of the client, and they can send messages to each other by performing DH using the private part of their own key and the public part of the other side's key, establish the same shared secret every time and use it for encryption. The problem with this scheme is that all messages are encrypted with the same key. When the the private part of either side's DH key leaks, the adversary can decrypt all previously recorded communication. To avoid this problem, we use ephemeral DH, with new keys every time and destroy the private part of the key in memory immediately after it has been used.

It is possible to combine ephemeral DH (new key every connection) and static DH (long term key), to use a long term  DH key only for authentication while encrypting using newly established keys thus providing forward secrecy as in authenticated DH. If so, the handshake will be two DH operations instead of one DH operation and one digital signature operation. But AFAIK, this variant does not exist in the spec for IKE (or TLS or SSH). You can read about this in Noise protocol framework, if you're interested.


Is XSS via MIME sniffing a Stored or Reflected XSS?

XSS attacks using MIME sniffing could be both stored and reflected. Anything where the browser is tricked into believing that a file with one MIME type should actyally be interpreted as something else could be called a MIME sniffing attack. If the piece of evil data that tricks the browser comes from the URL, we would call it reflected. If it is stored on the server, we would call it stored.

In practice though, I would expect most (almost all) MIME sniffing attacks to be stored. The traditional way of doing it is that you exploit a file upload functionality that e.g. only accepts images by uploading a file containing JavaScript code in the hope that browser will ignore the image MIME type and go with a script one instead. This line of attack clearly relies on the payload being stored on the server, so it would be stored XSS.


How to prevent reflected XSS with the Java Struts Framework?

As far as I understand, you have a reflected XSS on a JSP page (the question does not fully specify which technology but JSP is a pretty good bet if you use Struts 1)

Your solution is therefore most probably to surround the potentially dangerous data with the standard

<c:out value="${dangerousData}" />

tag, which escapes XML content (and therefore eliminates your nasty XSS)

Also, the standard

${fn:escapeXml}

function provides equivalent security.

You have to use the right one depending on how you actually use the data. If you simply display the data, use c:out.

====== Update after OP's comment =====

This solution works. Let's take an example : you have a JSP with the following line, which is XSS-prone :

Hello, dear ${username}

the ${username} variable is replaced by the content of the username parameter in a request (typical reflected XSS).

So the request www.yoursite.com/somepage?username=

would indeed prove the effectiveness of the XSS, with an alert box popping as a proof of concept.

If you replace your code with the following (as described in the solution) :

Hello, dear <c:out value="${username}" />

, the  would be displayed on the page and would not be executed, therefore making your users safe.

This is the best-practice when dealing with XSS given your technology choices.


Should Android apps for communication encryption and security require permissions like identity, device ID, contacts, etc.?

Android Permissions are a tricky subject - there are a range of reasons why an App might require some fishy sounding permission to private data:

Intent to steal you data and use it for advertsising or selling it
Lazy coding / incompetent coding ( I'm not sure what exactly we need, so let's just get this general permission to all files )
Bad Android Design - somtimes a strange permission like camera is needed to activate the flashlight, or track phone calls which sounds like someone is listening to your private conversations, but is actually needed to pause a music player when you receive a call (This varies with many android versions)
Actual use-case for some functionality in the app. Maybe the app features some functionality which actually needs this permission even if you don't use this functionality / don't know about it. A messenger could let you share contact details in chat and only require access for this.

What to do?

Best Case: You should only use apps where you trust the Publisher. And you could use a System like CyanogenMod which has integrated control - so you can decide to block any app from accessing your contacts, or decide to show a confirmation dialog each time it wants to access certain private data.

The preview for Android M also sounds like a fine grained permission control might be a standard-feature in upcoming releases...


Hash functions are deterministic: same input yields the same output. Any implementation of a given hash function, regardless of the language it is implemented in, must act the same.

However, note that hash functions take sequences of bits as input. When we "hash a string", we actually convert a sequence of characters into a sequence of bits, and then hash it. There begins the trouble. Consider the string "café": among all the possible conversions to bits, all of the following are common:

63 61 66 e9                             ISO-8859-1 ("latin-1")
63 61 66 ca a9                          UTF-8
63 61 66 65 cc 81                       UTF-8 (NFD)
ef bb bf 63 61 66 ca a9                 UTF-8 (with BOM)
ef bb bf 63 61 66 65 cc 81              UTF-8 (NFD with BOM)
63 00 61 00 66 00 e9 00                 UTF-16 little-endian
00 63 00 61 00 66 00 e9                 UTF-16 big-endian
ff fe 63 00 61 00 66 00 e9 00           UTF-16 little-endian (with BOM)
fe ff 00 63 00 61 00 66 00 e9           UTF-16 big-endian (with BOM)
63 00 61 00 66 00 65 00 01 03           UTF-16 little-endian (NFD)
00 63 00 61 00 66 00 65 03 01           UTF-16 big-endian (NFD)
ff fe 63 00 61 00 66 00 65 00 01 03     UTF-16 little-endian (NFD with BOM)
fe ff 00 63 00 61 00 66 00 65 03 01     UTF-16 big-endian (NFD with BOM)

and all will yield very different hash values when processed with a given hash function. You have to be very precise about what you do when dealing with cryptographic functions; every bit counts.


Danger of making calls after unknown random number called through

It depends on the PSP's (Phone Service Provider's) end on how their systems are configured.  Basically the disconnect happens between the phone on the other end and your phone, only after the system on your PSP's end is somehow informed of a hangup on the other end, on your end, or is able to detect it, does it start disconnecting the line.
The amount of time from the start of line disconnection to the actual disconnection depends on how busy the system is to perform the disconnection, and where the hangup originated from.
When the other person hangs up and you still hold on, you probably will hear two noises (after the receiver's phone hangs up).  The first is the disconnection on the other ends PSP's and the next is on your ends PSP's.  This can more easily be heard on older copper lines.
As per the wierd sound you heard, it is not common that small phone exchange systems can be hacked [1].  The hacked number may be that of a fax machine.


How to share EV Code Signing Certificate with USB token with other developers?

To sign, you need the private key and the cert. It sounds like the private key is on the USB, but I can't be sure.

Best practices is to keep the private key, well, to keep it very private. It is generally only stored on a single machine and an automated workflow is used to copy binaries to that machine for signing. That machine should be as vanilla as possible to reduce the chance that it is vulnerable to an attack.

The reason for such care is that malware authors really like to get their malware signed with a valid, trusted code signing key. There's a famous case where, despite very strong security, Adobe's private key was used to sign malware. Now Adobe's code signing key is much more attractive to an attacker than yours due to the fact that many people have already told their computer to trust Adobe's key, but basic security practices such as those described above are still appropriate. Remember that it is your company's reputation at stake if you end up signing malware with your key.


HTML payloads work on burp but not on browser

When using Burp, you are injecting the code directly to the server without the browser-side javascript or tools.

When you enter the payload on the browser, it is processed by the browser-side javascript and tools.

So, what you are seeing is the potential that the browser is sanitising the input before sending to the server. That's why tools like Burp are so useful for testing.


Download Windows 7 security updates and patch offline

The easy answer is yes, it is possible. In fact, we have several servers that for various reasons are only patched in this manner. This does produce a bit of an annoyance on the admins, however once you get into the swing of things it is not so difficult to do on a small scale.

Your situation sounds wonderfully easy, though. I would recommend installing Service Pack 1, then connecting to the network to pull down any additional updates. Since SP1 rolled-up a large number of patches this should

Speed things up significantly
Take care of any of the older vulnerabilities that may be frequently looked for

You can find the official instructions for installing the update here. That page contains the link for the actual download page as well as instructions on how to determine which file to use for your system.


DNS spoofing protection in Chrome and Firefox

Messenger.com is on the HSTS preload list. This means that it requires a https connection, for all browsers that use the HSTS preload list.
In addition, any browser which supports HSTS, but does not use the preload list will fail to load messenger.com over http if they have visited the site previously.
The standards mandate that untrusted certificates or redirection to plain http should be treated as hard failures, not something the user can bypass.
HSTS is meant to kill the kind of attack you are attempting, and thus working exactly as intended.
If you present a self signed certificate, it will generally fail, unless this cert is trusted by the local certificate storage.
Here's a list of browsers supportings HSTS.


Why doesn't Bitlocker mix the password with stored key?

It does sound like a flawed argument though I've not checked the details personally.

But this doesn't surprise me as it seems to me, from the perspective of seeing Bitlocker deployed to a large enterprise, Bitlocker is pretty flawed anyway.

Certainly TrueCrypt supports using both.

Of course, the downside of using USB devices for security is their rate of failure. As they fail pretty regularly, I certainly would not want to rely on one as the only mechanism for logging in to something.


What type of PCI Compliance do I need if I don't hold any card data

This is a bit of a weird request.  Only the Primary Account Number (PAN), Cardholder Name, Expiration Date and Service code are Cardholder Data.

Directly from PCI-DSS under the header PCI DSS Applicability Information

  The primary account number is the defining factor in the applicability of PCI DSS requirements.  PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted.  If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

Thus, if you are not storing, processing or transmitting the Primary Account Number, then you are automatically PCI DSS compliant as no requirements apply to you.


Browser add-ons are browser-specific, so any answer to your question can only be very general.

Some browsers allow for plugins as any piece of native code, which can, of course, do anything that native code can do. For these, the add-on could provide all the functionality you can wish for. Other browsers primarily enforce Javascript-based add-on logic, so whatever the add-on does, it must do within the constraints of that programming language. Javascript is not good at computing-intensive tasks, and cryptography is such a task. The add-on would be bad, for instance, at decrypting a video file or anything similarly bulky.

Note that when the browser allows for add-ons with native code, the native code will depend on the OS and CPU architecture. This is known to be a source of severe headaches for developers. Javascript-based add-ons are much more portable, but pay for it through much reduced performance and also greater isolation from the local machine.

The biggest problem with a browser add-on is that not everybody has it. If people must install an add-on to use your Web site, then this no longer is a Web site; the whole point of a Web site is that everybody can use it without any prior installation. An add-on is useful only when it provides optional client-side functionality (so your site code cannot rely on its presence), or when everybody already has it (in which case it no longer is an add-on, but a "native feature").

The two "add-ons" which got close to being sufficiently prevalent to be considered as "always there" are Flash and Java, but both are still restrictive (an iPad, for instance, has neither). It would be quite improbable for your add-on to achieve an even similar level of success. This means that whatever reasons which would make doing your browser-side cryptography in a Java applet a bad idea, also apply to the scenario of using a crypto add-on (and Java, at least, has the muscle and existing code base which allows for powerful cryptography).


What is the security concerns of AzureAD?

Azure AD is SaaS so Microsoft is responsible for scanning and securing the infrastructure.  It’s important to understand the division of responsibility between you and Microsoft. On-premises, you own the whole stack but as you move to the cloud some responsibilities transfer to Microsoft. The following responsibility matrix shows the areas of the stack in a SaaS, PaaS, and IaaS deployment that you are responsible for and Microsoft is responsible for.

Source

I deal with regulated customers on a daily basis and find it useful for them to review our Customer responsibilities matrix.  This helps them understand what they are still responsible for securing in the cloud and what Microsoft is taking as a cloud provider.  You can find them here:

https://servicetrust.microsoft.com/ViewPage/BlueprintOverview

Can I use BloodHound on AzureAD or is there a hack around it to work with it?

BloodHound is a tool for analyzing the trust relationships in Active Directory (ADDS) environments.  While Azure AD and ADDS have similarities, they are not the same products.

Does Azure has a tool-as-a-service already that we can use?

We have Azure Security Center, Advanced Threat Analytics and Azure Monitor and many more services that are all designed to help monitor and protect your cloud environment.

Can you recommend some list to check at least manually?

We have documented best practices


Is Common Criteria (CC) a suitable standard to certify web applications

No.  In practice, the Common Criteria is not a great tool for assuring or evaluating the security of a web application.  There are a number of reasons:

There's plenty of knowledge about how to evaluate the security of a web application.  There are companies who will do that for you (e.g., Whitehat Security, Cigital, and many other companies).  We don't need no stinkin' standards.
Common Criteria a clumsy, heavyweight tool.  Based upon experience in other industries, it would not be a good match for the rapid innovation and agility in web applications.
Common Criteria evaluations are expensive and they often aren't as effective as one might like, so they're probably not an efficient way to evaluate the security of your web application.
My sense is that Common Criteria evaluations often lean too heavily towards a bureaucratic exercises in ticking off checkboxes.  Also, Common Criteria evaluators suffer from a conflict of interest (they are paid by the folks they are evaluating, which tends to lead to a least-common denominator syndrome where evaluators tend to be a bit lax).  As a result, I've seen highly insecure products certified under the Common Criteria.
Common Criteria evaluations are time-consuming, so it's not unusual for a product to be almost obsolete by the time it is certified.
As far as I know, there is no "protection profile" for web applications.  In principle, Common Criteria is happy to let you certify anything, if there's a "protection profile" that specifies what the security requirements and threats may be.  Since there is no "protection profile" for web applications, you couldn't certify a web application to the Common Criteria even if you wanted to.

To summarize, Common Criteria primarily solves a compliance problem, not a security problem.


Why strace isn't showing system call being made in shellcode?

I'm editing this answer to clean up the confusion about -e open. -e only does filtering and will not add extra info to the strace log. The only case when strace is not logging open syscalls is when a forked subprocess is invoking them and the -f parameter is not set, which is not relevant in your case.


Generally, the most conservative answer comes in the form of something easily understood, and approachable by the general populous.

Ignoring the hyperbole of that kind of response, there are two things you must really take into account.

What logs should I retain
How long should I retain said logs

Log Retention

The answer to 2 is simple and well defined by the standard. Logs must be retained for one year and the last three months must be easily accessible. So let's translate that statement into my own recommendation

Implement a centralized logging system, e.g. a single purpose system acting as a syslog receiver
If storage is available on central system, then retain all logs from PCI scoped systems for 1 year
Otherwise retain all logs from PCI scoped systems on central system for 3 months, rotate all  logs older than 3 months to long term storage (such as tape/VTL/papyrus). Expunge logs on long term storage that are older than 1 year.

Events to Log

The answer to the first point is a little less well defined. The standard wants you to keep events and details for all PCI scoped systems. So assuming you have determined every system that is in scope, the only question is what what events you want to log. This is much harder to answer, because it would largely depend on your environment and what applications are running. The easy answer is to ask your QSA. To be conservative I would recommend adding *.*  @logserver to your syslog config files, or perform the Windows equivalent. Make sure that any non-syslog applications on those machines also find a way to get their logs out. This would include web server, fat clients, etc. At minimum make sure any authentications, successful and unsuccessful, are logged. If possible full audit logs of data access on applications would be nice. For web apps, this would be standard in your httpd logs, but fat clients may not be as granular.

In the end, since your QSA decides whether or not you are compliant, they are your best bet for answering these questions.


How do large companies and wealthy individuals secure their information?

Do not use the same password on multiple sites.  That's number one.  Second, don't use simple passwords for any site where you care about your account.

To do this, you need a paper list or a password manager (e.g. KeePass, LastPass, etc).  A manager is almost always the way to go.


What is the security flaw in this example of "magic parameters"?

Actually there is another more important one, due to the lack of a time constant implementation of equals, a timing attack can be used to work out magic.

See http://codahale.com/a-lesson-in-timing-attacks/

public static boolean isEqual(byte[] a, byte[] b) {
    if (a.length != b.length) {
        return false;
    }

    int result = 0;
    for (int i = 0; i < a.length; i++) {
      result |= a[i] ^ b[i]
    }
    return result == 0;
}


Help! Someone fake texted or made a photo with my number calling and texting them

so by the sounds of it you have not been hacked based on their being no log of these text messages in your phone bills. Although (not sure if its an issue on my end or yours as new users) I cannot see any images being referenced but yes! anyone with a decent knowledge of a photo editing tool can create nearly anything they want as an image.

If you're simply referring to alleged missed calls and text conversations then they don't even need to be skilled. There are Apps for most mobiles that allow you to fake a missed call, specifically marketed on the store. And a quick google found this site which makes conversation chains easy for iPhone at least and it won't be the only one out there.

I know some of these can be quite scary, usually from a security point of view they would be sent to you not your husband with the intention of trying to get money out of you, so the motives for this one are probably outside of a security scope. I agree with your Husband, if he isn't concerned you have no reason to be, since any likely motive would be to do with your relationship and it clearly hasn't worked.


How secure is a virtual machine and free VPN?

I feel like the set up is pretty unpenetrable but I'm also starting to question that

Never assume you're invulnerable. It's probably good to be paranoid, but you should define the threat first. What are you worried about getting?

  On it I have bitdefender free av and Malwarebytes free that I scan occasionally

This tells me you're worried about malware, right?

Let's look at what you're doing:

  I start my cyberghost VPN free version then start a virtual machine through virtualbox of a trial win 8.1

This is wrong. You should be starting the VM, taking a snapshot of the VM, then starting the VPN from inside the VM before browsing to the site. Then, when you're done with the "sketchy site," turning off the VM and restoring the snapshot to a previous time.

This effectively wipes the virtual machine back to the state before you went to the site. "Like it never even happened."

  Typically after going to the sketchy site I reset the modem and router after closing the VM then closing the VPN. Is this over kill

This is pointless in terms of securing your machines after "visiting a sketchy site." It's more important that your VPN provider does not keep any logs of personally identifiable information. See also: Which VPN Services Keep You Anonymous in 2017?.

A VPN hides your current address. It does not provide security against viruses. Your router is simply a connection upstream. If your VPN collects info on you, resetting your router is pointless. It's also not relevant.

  Is it possible to infect my network by going to something sketchy even with this protection

Yes. Zero day flaws in the operating system make everyone vulnerable. Spear phising and other targeted attacks make you vulnerable. Your humanity is probably your weakest link, but if you're not the active target of a state or bad actor, you probably don't have to worry about this. If you are keeping your hypervisor, operating system and VM operating system up-to-date, you should be pretty well protected.

I also seem to notice that you don't have security installed on your VM? THis topic is a bit of a holy war right now since AV increases the attack surface and relies on hooks in the OS, many people think that 3rd party AV is a bad idea. Still others highly recommend it (Lawrence Abrams from bleepingcomputer.com did an interview with Leo Laporte on TWiT stating he thinks people still need it).

You should (at least) be running Windows Defender on the VM.

You fail to mention what browser you're using... right now Chrome appears to be the most secure, but you should have uBlock origin, https everywhere, and privacy badger running in it... in the VM.

Still one other thing you can do if you're really paranoid ... Tor Browser on top of the VPN with all those add-ons.

But quite honestly, you could very much simplify your life by getting an old laptop, and running Tails from a USB stick from your local Starbucks. Of course, the sketchy site must really be appetizing to make you want to leave the house. But then again ... security is diametrically opposed to convenience.

You could always just ... not visit the sketchy site too.


First, let's define both what a non-stateful and a stateful firewall or filter is:

Non-stateful firewall: This was the original firewall method. You give the firewall rules as to which IP ports are open or not.
If an incoming packet (usually from the internet) doesn't specify a port allowed by the rules, it is dropped/stopped by the firewall.

Stateful firewall: All ports are blocked by the firewall (by default, and this only applies to traffic from the outside/internet). When a computer behind/inside the firewall wants to establish a connection through the firewall, the firewall watches the first packet go out (on whatever port your computer selects) to a remote (web) computer. The firewall remembers the IP address where the packet was sent to and what port was used by the sending/internal computer, and will (for a limited time) allow packets from that external IP address that use that port) to pass through the firewall to reach the internal network. Stateful in this case means the filtering state (rules) of the firewall depend on what traffic has been initiated by computers on the internal (nominally safe) side of the firewall. By default, any packets from the outside are stopped by the firewall unless they are part of a current ongoing conversation initiated by the internal computer.

Both of the above only require looking at ingoing and outgoing packet headers, which include the sending and addressed IPs (from and to addresses) as well as the IP port.

Later on, firewalls also started doing "deep packet inspection" where they looked at the contents of the packets as well.

If I understand your question, you are asking about the ability of a firewall to know what application is trying to connect through the firewall.

A lot of applications use certain default ports. For example, HTTP (web pages) use port 80, while HTTPS (secure/encrypted web pages) use port 443. So just looking at the port used tells the firewall what application is probably being used. As the internet moves more and more to encrypted communication (HTTPS everywhere and the use of VPN or other encrypted communication links), firewalls are less and less able to look into the contents of IP traffice, so seeing IP port will over time become the only way the firewall can tell what application is communicating. There are ways to allow a sophisticated firewall to look into encrypted packets, but normally they will only be employed by large organizations (and some snoopy ISPs) but not by home users.


The app is using JS(express) and no PHP, so my first question is if the input is not handled carefully is it still vulnerable to PHP wrappers?

PHP wrappers concerns php based application and has nothing to do with ways express js handles data.

I've written a small function to sanitize user input. Please tell me if it vulnerable in an environment where the path parameter is being prepended using the below function prepare for getting an absolute path that is then used as input to res.sendFile().

The code will not prevent you from getting hacked if the logic behind it is incorrect. The LFI not only means inclusion of local system files but also file uploaded by attacker to spawn shell as an attempt for escalation of privileges. In such case ../ shall not be the only thing to look for.
In the app's request flow's last step, consider this as suggested addition:

res.sendFile((if possible)check if the intended page will be prepared and it is surely not from system files or the page to be prepared belongs from specific directory of the server & then prepare(page))


Saving passwords and remember me functions

I am aware that you have to hash your passwords, infact here's my code (tell me if it's secure enough)

Yes, it's secure. I wouldn't pass the salt though, password_hash manages salts automatically.

  I set in the $_SESSION the username and password (which I understand is stored on the server side)

Yes, it's stored server-side. Still, you shouldn't store sensitive information in the session if it can be avoided - which in this case it can be (you don't need the password in the session at all).

This is a security issue as it may lead to the leakage of the plaintext password, as session data may be read out on shared hosts, via file inclusions, and so on.

  if they ticked the remember me button I save the username and password (unhashed) in the cookies

Again, this is not good. You really don't want to store the password unhashed anywhere, especially the cookie.

Anyone with temporary access to the victims browser would now have access to the plaintext password, it may be accessed via XSS (at least if your cookie isn't httpOnly, which it should be), and so on.

What you want to use instead is some random identifier that you generate and store in the database (ideally hashed).

  The session part I'm pretty sure is secure, and even more secure than some videos I've watched, some say that you can just store the user's ID in the session which means if they change their password they're still logged in. But the cookies part, it's tripping me up with cookie stealing scares saving it unhashed in their cookies.

You seem to know that you don't follow best-practices. So why build your own here? Your approach doesn't seem to offer any advantages, but does have some rather serious downsides.


Understanding the Secure Multi-party circuit for Stable Matching

This naming is only for illustration purposes to differentiate preference lists from two groups. In the Verilog code, they actually start from index 0:
https://github.com/sadeghriazi/MPCircuits/blob/705fda8ac6e45a2d67bbdd0c81007507742bd4ae/stable_matching_comb/stable_matching_comb.v#L64
You need the priority encoder to identify the 'next free person from group A'. Imagine you have a vector of 0s and 1s and you want to learn the 'index' of the first 0. That's what priority encoder does for you.
The security of the preference lists is guaranteed by the underlying secure computation protocol, here the BMR protocol. To use BMR, you need a Boolean circuit that implements the functionality for you. Any input to the circuit is not revealed to other parties during the protocol execution.


LM hashes over a network are disabled by default on post Windows XP systems.

You will have to use a group policy/local security policy to enable that behaviour again. Changing the defaults was done obviously to prevent weak hashes being sent over the network for authentication. Microsoft figured that by the time a corporation had Windows 7, the environment wouldn't have a Pre-XP machine, so there was no need for compatibility.

LM Hashes will also not be generated when:

User has a password that is too long for the LanMan hashing scheme
LM hash generation was disabled completely by group/local policy


selft signed certificate for AES128-GCM-SHA256 cipher

AES128-GCM-SHA256 and AES128-SHA256 both use RSA certificates for authentication and key exchange. They only differ in the symmetric cipher and MAC used - which are independent of the certificate. This means that you can use the same
RSA certificate with both ciphers, i.e. there are no changes needed in certificate creation specific to  AES128-GCM-SHA256 compared to AES128-SHA256.

Note also, that the algorithm you have specified to protect the private key (i.e. genrsa -aes128) has nothing to do with the cipher used in the TLS connection. Similar the signature algorithm you have specified for the certificate (x509 req -sha256) has nothing to do with the cipher used. The meaning of AES128 and SHA256 in AES128-SHA256  is instead that AES128 is used as the symmetric algorithm to encrypt the traffic (not the private key) while SHA256 is used as MAC for integrity checks on the traffic (and not as signature algorithm on the certificate).


How does an attacker get access to hashed passwords?

There are any number of ways:

SQL injection
Leaked backups
Disgruntled employees leaking them
Any kind of breach of the server that allows code execution.

As you can see there are many, many ways this could happened - as phihag mention in comments, more than half of the OWASP top 10 could lead to leaked hashes - so they can not be easily tabulated in a post.

This does not mean that it is inevitable that hackers gets the hashes, but you should still use a good hashing algorithm to protect yourself and your users just in case. Since a backup may be lost or your server hacked without you ever noticing, having properly hashed passwords should be the only thing that allows you to sleep at night. This strategy is known as "defence in depth", or just simply "plan for the worst".


What to use as 'state' in OAuth2 Authorization Code Grant workflow

Disclaimer : Couldn't find any reference on the subject so I will use a questionable tool called "logic". If someone find any good reference, please add them.

CSRF is dangereous

There is no doubt about it and OAuth2 is no exception. In fact, there are multiple ways that you can exploit CSRF attack while using OAuth2. The reason is that there are multiple message that are sent that could be use to trigger a CSRF attack. The section OAuth2 Spec Section 10.12 gives a good overview of what you could do with CSRF

But, let's look at what happen in details when a user want to login using OAuth2. In our example, we will have the following actors :

The user (you and your browser)
The attacker (usually a malicious website)
The client (web application you are using)
The provider (oauth2 server that authenticate the user)

Then, let's look at what happen from the user point of view when he tries to authenticate with the provider.

The user click a link on the client website and get redirected to the provider authentication form
The user authenticate with the provider and get redirected to the client website where he gets authenticated too, automatically

Where can we attack?

From the user point of view, it's just 2 simple steps but there is multiple places where you can attack it. One of the root problem here, is that often the OAuth2 provider will redirect you automatically, if you are already logged in. A good example, is stackoverflow. See this answer for details :

OAuth2 Cross Site Request Forgery, and state parameter

So the different attacks are :

An attacker can replace the authorization code with his own to make you login into his account instead of yours. Might look like a crazy idea but if you decide to enter some confidential information in his account, he now has access to it. Ex.: bank information
An attacker can generate a valid provider link on his machine and then he serves it to you, if the provider is redirecting automatically then you will be logged in to the service the attacker want to attack.
The attacker make you generate a valid provider link from the client website (only works if the link is generated via a post/get on a static url), then if the provider is redirecting automatically you will be logged in to the service of the attacker want to attack.

How to protect against them?

Simple, you just need to pass your CSRF anti-forgery token in the state parameter of OAuth2 to protect against #1 and #2. Then, to protect against #3, you need to make sure that the link cannot be generated without the user interaction, meaning protect that link with CSRF protection. But back to #1 and #2...

By including, a CSRF token as the state, you will defeat those attacks as it will be impossible for the attacker to serve you links that you didn't generate yourself. A simple implementation of a CSRF token is a random number that is stored in the session and then included in every form sent by that by a user. If the form contain the token, the client consider it as valid. If it doesn't contain it, then the client assumes that the request is invalid.

Usually, that CSRF token is only accessible to the user/browser and the client, but in the case of OAuth2, more parties get access to it. To understand what to do, we need to know which are these additional parties.

The Answer : Just send the token

So, in that case, the token will be known to

The client (the one who created it)
The user
The provider

It's a simple round trip over HTTPS. An attacker cannot insert himself in that conversation so you don't need to worry about that.

Do you need to protect the token against the provider?

No. If the OAuth2 provider is malicious you have already lost. He doesn't need your CSRF token to take over all your accounts if he wants. When you chose to use OAuth2, you basically made him god of all your user accounts.

Conclusion

Don't worry too much how you send the CSRF token; just make sure you send it. Also, the fact that it's sent as a url parameter would be another point to worry for a permanent password but since those tokens are temporary is shouldn't be much of a problem.


Should I report the IP address that an attack is coming from? Is so, who to?

If you are suspecting they are using a compromised machine, you can notify the administrator of the network. You can find contact information by doing a whois lookup:

$ whois 151.301.193.69

...
OrgAbuseHandle: ABUSE4771-ARIN
OrgAbuseName:   Abuse Account
OrgAbusePhone:  +1-555-496-9353
OrgAbuseEmail:  abuse@example.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE4771-ARIN


How do password managers implement secure browser integration?

How do these password managers correctly identify the password input field on a web page?

Password fields contain input type="password" in the HTML for the input field. This tells the browser and any associated extensions that input to the field should be treated as sensitive. This is what tells the browser to warn you if you are sending it over an unencrypted connection, and also what causes the input to be replaced with dots. In fact, if you edit the source of the page to remove this, you will notice that the characters you type in are not hidden anymore. A browser extension will be able to access this information as well (it is usually exposed in the extension API), and it uses this to determine which fields are password fields.

  Does the browser have any security mechanism to prevent other addons to access the password information, before and after it is filled in?

No. Any other extension with equivalent permissions will have the exact same access. They can see exactly what the password manager is writing to the input field, and will be able to see the password that is being sent. However, it will not be able to read the password database by itself, since one extension cannot read the local database of another extension.

  But then wouldn't other programs on the user's local system also be able to recover the password?

Yes, usually. While a master password may be used to encrypt these passwords, a local process running under the same user could easily hijack the browser to read the master key next time it is input. This is because a password manager's purpose is simply to let you use unique passwords for each website so you do not risk reusing the same passwords everywhere. They may add useful features like automatic password generation or encryption with a master key so someone who steals your computer cannot log into your sites, but that is not their primary purpose.

A browser password manager is designed to protect from a few threats, specifically:

A malicious or compromised website which can see the password you provide. If you use the same password for that site as for many other sites, that website will be able to impersonate you. A password manager allows you to seamlessly generate and use secure and unique passwords for every website you register on. A browser-based password manager simply makes integration with your web browsing experience easier.
An attacker who gains offline access to your password manager database, such as a laptop thief. If the password manager uses a master encryption key, which most do, then the thief will not be able to find out what passwords you are using. If the attacker is a local process running on the same machine, all bets are off. Password managers do not and cannot protect from such a threat. Proper system hardening and prompt security updates will.


can anybody explain error based sql injection attacks

Error based sql injection takes advantage of poor error handling in an application.

When the application is returning you the mysql error, you find a way (usually it's with group by) to have the interesting data returned by mysql in the error.

In your example I can't see what information you are trying to obtain but look at this site, there are good examples there.

As you can see in the examples, each request is made to trigger an error. This error will contain the value wanted by the attacker. For example, the mysql version will be retrieved with the error "Duplicate entry 'MySQL version here' for key 1".


How does mobile free internet bypass works? (UBT / FBT)

This seems to exploit a vulnerability in how that particular ISP handles quotas.

A lot of ISPs implement quotas at an application level and not at a packet level, so they can discriminate based on the protocol (and its properties like which URLs you're browsing in case of HTTP). It seems that they've got a loophole where they block HTTP(S?) traffic when you're out of data, but forgot to block SSH (which operates on a different port).

As a result you're able to tunnel your traffic through the SSH server and enjoy your free data. The same exploit could apply to DNS or ICMP (there is software out there that can tunnel traffic through innocent-looking DNS or ICMP packets) if you find out that they don't filter either of those protocols.


This is safe in general, though you should be concerned about any services on those machines that are exposed via stateless protocols such as UDP, as the source address can be spoofed. As such, if an attacker knows the IP, they could still send UDP traffic through the firewall by faking the source IP. If you've got no UDP-based protocols exposed then the firewall should be blocking this anyway.

If you're only sending this list once, sending it in the clear isn't the end of the world. It's only a list of IPs, and doesn't contain any credentials, so you should be fine. That said, GPG is a great option for securing email, and really isn't as hard as people think it is. Just install an email client extension and it should do the hard work for you.


tl;dr
Are there security issues with your approach?
Difficult to say, as it is not clear from the question which token you are sending in the mail. You should read my long answer to understand my concerns. But, in short: if you send the guid, then yes, there is an issue (see the 'implementation' part of my answer. If, on the other hand, you send the refresh token: then there probably is no security issue.

Preface
As pointed out by @CBHacking:

the intended use of OAuth2 refresh tokens is for persistent access; an app gets a refresh token, and as long as it has a valid refresh token and the session is not invalidated on the server, the app is authenticated. The access token is short-lived but, if you're using refresh tokens at all, you expect the client to remain authenticated for a long time

Anyway, it does not really matter. If you want to use the refresh token only once, then you are free to do so.
An example of the implementation you want to achieve
I'm not sure if you already know it, but Slack has actually the sign-in experience that you are describing. You can test it yourself by creating an account and install their mobile app, or just see how it works here. Their link looks like this:
https://slack.com/z-app-0000000000-0000000000-AAAAAAAAAA (I've replaced numbers with 0's and letters with A's). I assume that their link is built-up as follows (note: I don't know if this is true, it's an assumption):

First part: user id
Second part: time
Third part: unique token

Clicking this link will redirect you to somewhere like this:
slack://login/XXXXXXXXX/xoxo-0000000000-24characterlongtoken
So, another token is created which is then used to open the application.
Implementation
Your guid implementation seems a bit overengineered for the following reasons:

Why make use of an app-generated guid, if you could just as well directly send a 'magic link' to the mailaddress of the user from the server? Your security lies with the security of the user's access to the mailbox, not with the guid (which is not secure anyway). I agree that you need some kind of token, more about that later.
You mention that this guid is then encoded in the refreshtoken as a claim. I assume you mean adding it to the protectedticket of the user (the refreshtoken itself does not contain claims, in contrast to the access token).
And then, I am a bit lost in your implementation. You mention that you send the refresh token to the user, but really a refresh token is only a reference to a protected ticket in your database. So you then use this refresh token to retrieve the guid. And then what? You see, the guid is of no use in this set-up. The only token that matters in this set-up is the refresh token.

Just send a token
Sidenote, I make use of the following notations:

access token: the access token as described by oauth
refresh token: the refresh token as described by oauth
unique token: any token that is unique. If you want to use the refresh token for this, it's your choice. I give other options at the end of this answer.

So, you actually provided your own answer. We get rid of the guid and do it as follows:

The user requests a magic link on the application.
On the server, you check if the emailaddress is known, if so, create a unique token for this user and send it in a mail (link to an endpoint that can verify the unique token). You probably also should send some kind of user identifier.
When the user clicks the link, you verify the unique token (for that user) and issue a new access token and refresh token.

Now, as mentioned before, a refresh token really is considered a long-lived token. In some implementations, this token even never expires. To prevent access, you should revoke it instead. Therefore, it does not really make sense that you would use a refresh token as a unique token in the email.
Even better would be to create a unique token that is uniquely tied to the user. This depends on your implementation, but in .NET you could for example use GenerateUserTokenAsync. When using this, you don't even need to store the token in database, when the login request comes in, you can just call VerifyUserTokenAsync and you are sure that the user is the person you sent the mail to.
If you want to create a custom unique token instead, you should of course link it somehow to your user in the database. You could generate such a cryptographically secure unique token yourself. Depending on your programming language, the implementation differs. Google for it, and you will get answers.


How to find full geo location of computer from IP address?

Check out https://www.iplocation.net/

Plug in the IP and you are good to go.

Do note there is a difference with public and private IP. 192.168.1.1 will not find you anything


Does WebCrypto also mandate the crypto algorithms be implemented in Javascript?

A Javascript Crypto API spec that all browsers must (hopefully) support. Am i correct?

Hopefully all browsers should support it, though currently it's still work in progress.

The specification does not mandate that the API be implemented in JavaScript. Developers are free to choose their underlying implementation, it could be JS, or a built in part of the browser, a plugin, a hardware module, etc. This post introduces some of the currently available implementations and the technologies used to develop them.


ALERT - ASCII-NUL chars not allowed within request variables

This could be evidence of an attempted Poison NULL Byte Attack. PHP and Perl do not use NULL-terminated strings, but most underlying systems (anything C based) do.

This can lead to a certain class of attack where the attacker constructs a string that the programmer intended to be impossible. For example, if you were using a C library to include local file content into a web page, in your PHP you might do something like;

grabLocalFile($_GET['file_name'] . ".php");

By manually appending the ".php" it can appear that some security is offered - in that only file names ending with .php can be included. However if an attacker is able to send a request such as;

example.com/index.php?file_name=/etc/passwd\0

The null byte \0 will be treated as part of the string by php, which ends up calling;

grabLocalFile("/etc/passwd\0.php");

When this string reaches the underlying system, the NULL byte will be treated as a string terminator, and the .php will be ignored. Now the attacker has included /etc/passwd into the web page he is viewing, despite the developer's attempt to enforce inclusion only of files ending in ".php"

To mitigate these kinds of attacks you can strip out the NULL byte altogether by doing something like this

str_replace(chr(0), '', $string);

Regardless, suhosin looks like it is properly configured to defend against this class of attack.


Nmap scan giving different result to my iptables configuration

I wanted to see how my firewall appears to the rest of the internet so I did an nmap scan...

Which means that you did not really scan solely your VPS, but that you have checked out the combination of your VPS and your testing system and lots of routers and maybe even firewalls in between. And of course the VPS is only a virtual system on some real hardware which again has a network stack.

This means that what you see might not fully reflect your VPS. It might show up ports as open which are not open on your VPS but gets intercepted somewhere in between. It might show up ports as closed which are actually open at your VPS because some other device/software is filtering the access.


Use externally generated CA cert to sign CSR's in OpenSSL

Yes, you can. You just need to have the private key in the proper format to be used by openssl.

Not knowing in which format you exported, it's impossible to provide commands, but -supposing it can't sign directly with it- openssl x509 may be able to convert the file.


AngularJS - Can a response from an $http.post to PHP be modified?

Yes, the client could modify the PHP to change the value of success to true. However, it depends on your application logic to determine if that has any security consequences on your application. If the application just uses the success value to load a new UI, but can't pull down any data (because the user doesn't have an authentication cookie, or some other authorization token), then it wouldn't really be a concern.

However, if future requests (say, change password), use the userFirstName as the mechanism of authentication (that is, the back end PHP sees the first name and based only on that) then the application could not only be spoofed by changing success=true but also by setting userFirstName any attacker could become any other person if they know their first name.

Instead, you would return an authentication cookie of some kind. This would most likely be a random session ID that is sent with every future request. The backend PHP would then validate the session ID, and from it, know who the user is that is making the request.

This post has some ideas as to how to use authentication in angularjs applications.


There were discussions of placing attack trees 1, 2 in existing SGML derivatives 3 that describe system architecture or govern security modules, but nothing like unanimity appears to have been reached.

The issues include

The complexity in which attacks relate to individual architectural components and
That the nodes described in Schreier's tree proposal don't directly correlate with elements of authorization and authentication markups.

Some academic approaches of interest treat attacks as anti-goals in a goal tree 4.

Most important to the development of attack model formalization is that attack relationships do not frequently form trees.  Although attack relationships can always be represented by graphs (nodes connected by edges), attack categorization often requires multiple parental relationships to comprehensively represent the conceptual realities of security.

The removal of the single parent restriction of a tree allows the attributes of nodes and edges to contain what vendors are now calling metadata, which is a misnomer.  The metadata of these modelling formats does not always describe overarching qualities of the attack tree.

CySeMeL may not catch on as an acronym, but The Royal Institute of Technology has approached the relationships without the single parent restriction, calling the modelling language as a graph tool 5.  Such could lead to a more lasting and adaptable standard.

The automated generation of attack trees is being investigated by IEEE authors 6, and the ACM has interest in this same direction.  Either may later lead to standardization.

Another direction is to piggyback UML with a security model diagram 7.

It appears that the upstream academic work is still as varied as the product array available to architects, system administrators, security teams, and managers.  Inter-operable products may be further down the road, but if other standards that appeal to narrow audiences are any indication, import export menu items and converters may be the first emergence of at least partially inter-operable semantics.

[1] Early reference to attack trees in Dr. Dobbs Journal at https://www.schneier.com/academic/archives/1999/12/attack_trees.html.

[2] Later development from Bruse Schneier on Attack Trees http://tnlandforms.us/cs494-cns01/attacktrees.pdf

[3] Generating attacks in SysML activity diagrams by detecting attack; by Samir OuchaniEmail authorGabriele Lenzini; DOI: 10.1007/s12652-015-0269-8

[4] Design of a Modelling Language for Information System Security Risk Management, by Nicolas Mayer, Patrick Heymans (Member IEEE), and Raimundas Matulevičius.

[5] A Manual for the Cyber Security Modeling Language; by Hannes Holm, Mathias Ekstedt, Teodor Sommestad, Matus Korman; Department of Industrial Information and Control Systems, Royal Institute of Technology, 100 44 Stockholm, Sweden; http://www.kth.se/polopoly_fs/1.433836!/Menu/general/column-content/attachment/cysemol_manual_short.pdf.

[6] Automated Generation of Attack Trees; Roberto Vigo, Flemming Nielson, and Hanne Riis Nielson; Department of Applied Mathematics and Computer Science; Technical University of Denmark; 2014;  http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6957121

[7] SecureUML: A UML-Based Modeling Language for Model-Driven Security?; Torsten Lodderstedt, David Basin, and Jürgen Doser; Institute for Computer Science, University of Freiburg, Germany; {tolo,basin,doser}@informatik.uni-freiburg.de


Is the limited elliptic curve support in rhel/centos/redhat openssl robust enough?

I'll start. TL;DR: It's probably OK.

P-256 and P-384 seem to be the most widely implemented and/or preferred "curves", probably because they are the two selected for http://en.wikipedia.org/wiki/NSA_Suite_B and the right size for strengths currently considered comfortably safe.
To be pedantic they are really parameter sets consisting of a curve over a field plus a generator of a large subgroup, but everyone just says curve for convenience; the algorithms such as ECDSA and ECDH are the same for all curves and keys, just as the algorithm RSA is the same for all keys.

P-521 is the largest curve currently standardized for SSL/TLS, which satisfies size maniacs.

ECC smaller than 160 bits is probably breakable fairly soon, and important standards prohibit less than 224 or 256 to be comfortable; see http://www.keylength.com . Binary fields have proven less popular. Thus the curves RedHat chose are likely enough for decent interoperability.

Some, notably Dan Bernstein, argue that ALL the standardized NIST/SECG curves are hard to implement without sidechannels and could even be backdoored, see http://safecurves.cr.yp.to and https://crypto.stackexchange.com/questions/12898/is-there-a-feasible-method-by-which-nist-ecc-curves-over-prime-fields-could-be-rigged , but the proposed alternatives aren't yet standardized and will apparently require changes in implementation (of an equation form that retains the sidechannel resistance) to be developed and deployed widely enough before they become useful, so don't look for that tomorrow.

But if you want, I think there should be nothing wrong with using your own completist build, as long as the upstream OpenSSL version new enough to contain needed security fixes isn't so new it's incompatible with what your other RedHat/CentOS packages expect.


tl;dr: container solutions do not and never will do guarantee to provide complete isolation, use virtualization instead if you require this.

Bottom up and top down approaches

Docker (and the same applies to similar container solutions) does not guarantee complete isolation and should not be confused with virtualization. Isolation of containers is achieved through adding some barriers in-between them, but they still use shared resources as the kernel. Virtualization on the other hand has much smaller shared resources, which are easier to understand and well-tested by now, often enriched by hardware features to restrict access. Docker itself describes this in their Docker security article as

  One primary risk with running Docker containers is that the default set of capabilities and mounts given to a container may provide incomplete isolation, either independently, or when used in combination with kernel vulnerabilities.

Consider virtualization as a top-down approach

For virtualization, you start with pretty much complete isolation and provide some well-guarded, well-described interfaces; this means you can be rather sure breaking out of a virtual machine is hard. The kernel is not shared, if you have some kernel exploit allowing you to escape from user restrictions, the hypervisor is till in-between you and other virtual machines.

This does not imply perfect isolation. Again and again, hypervisor issues are found, but most of them are very complicated attacks with limited scope that are hard to perform (but there are also very critical, "easy to exploit" ones.

Containers on the other hand are bottom-up

With containers, you start from running applications on the same kernel, but add up barriers (kernel namespaces, cgroups, ...) to better isolate them. While this provides some advantages as lower overhead, it is much more difficult to "be sure" not having forgotten anything, the Linux Kernel is a very large and complex piece of software. And the kernel itself is still shared, if there is an exploit in the kernel, chances are high you can escape to the host (and/or other containers).

Users inside and outside containers

Especially pre-Docker 1.9 which should get user namespaces pretty much means "container root also has host root privileges" as soon as another missing barrier in the Docker machine (or kernel exploit) is found. There have been such issues before, you should expect more to come and Docker recommends that you

  take care of running your processes inside the containers as non-privileged users (i.e., non-root).

If you're interested in more details, estep posted a good article on http://integratedcode.us explaining user namespaces.

Restricting root access (for example, by enforcing a non-privileged user when creating the image or at least using the new user namespaces) is a necessary and basic security measure for providing isolation, and might give satisfying  isolation in-between containers. Using restricted users and user namespaces, escaping to the host gets much harder, but still you shouldn't be sure there is just another way not considered yet to break out of a container (and if this includes exploiting an unpatched security issue in the kernel), and shouldn't be used to run untrusted code.


Publicly Available API + Sensitive ID/Key Transmission Over HTTP

It should be possible for you to get the key down to the client without risk that an attacker with access to the network connection can intercept it.  That could be down with something like SSL using specific server and client certificates to authenticate each end of the connection.

However an attacker with access to the client code (e.g. most mobile platforms) will always be able (in theory) to get access to any secret you hold on the client be that the client certificate in use or the key itself, and really you should plan your security model with that thought in mind.

Once something is placed on a system that you have no control over you have to assume that an attacker who has control over that system has access to it.


There is always the possibility of a zero day memory corruption exploit or other exploit.. with any kind of javascript API. I don't really see webrtc as being a huge security threat though. There are easier and more popular targets like flash. I think your list is probably complete, I have seen the VPN "exploit" a while ago, I think that's the only one which was known to be consistently possible, so that seems like a very good track record (so far). I probably would make this a comment, but I am not able to comment.


How can I know if my PC is getting infected?

The short, pithy answer is that you don't. There is some extremely stealthy malware out there. Look at stuxnet, flame, and some of the banking trojans as examples. If a sophisticated enemy is out to get you chances are you won't know you've been hacked.

That being said it's extremely unlikely that you are ever going to be targeted by anything that sophisticated. Chances are you are like the majority of people trying to defend themselves against an average level of threat, in which case you do what we all do:

patch your system. Most of your typical hacks target well-known vulnerabilities that have been patched for weeks, or even years. They target OS vulnerabilities but also adobe flash, java, adobe reader, etc. Make sure that you patch all your software as soon as patches come out
Install a good AV and run scans frequently (looks like you've got this covered)
narrow your system's attack surface. The more software you have installed the wider your attack surface is, so uninstall all software you don't use, especially the crappy bloatware that most out of the box systems have installed
harden your system. Ensure that you have no guest accounts, and that all accounts have strong passwords. Turn off any service or process that isn't needed

As for knowing if you've been hacked it's usually pretty obvious unless you have been infected by stealth malware: you'll get pop-up ads, redirects to sites you didn't intend to visit, threatening messages telling you to pay money or have your life destroyed, your fiends will tell you that they are receiving spam from your email address, somebody in Timbuktu will buy a laptop using your credit card details, and you'll find out that somebody's used your personal information to apply for 40 different loans completely destroying your credit rating, or someone will siphon your life savings into a cayman islands bank account.

Good luck, and happy browsing.


Patient Hashes for Compression and Security

None that I know of. And I believe this is because.. I don't think the solution (implied by the question) is a good solution/proposal.

Not only because hashing function may have collisions (even if it has a very low probability, the impact would be major, so why should we add such a risk ?) but also because you have another problem prior to hashing: unless you solve something that has not yet been fully solved (i.e. semantic interoperability), in a med profile you can -for instance- find/formulate the very same medical concept in several different ways (i.e. different text sequences may mean the same thing/medical concept) so in those cases you would get different hashes referring to the same concept (!) . How would you manage that ? Will you be able to map all those different hashes to the same medical concept ? (type of allergy or whatever). How would you say that two hashes really mean two different things.. and which things should they be ?. I believe you won't be able to predict all the possible different ways in our language we could express the same concept and the resulting hashing values will be severely flowed in semantic terms.

Even if you choose to use the best terminologies and controlled vocabularies or coded information to be used in the med profile, they will still need continued maintenance and revision over time (because of versioning etc. e.g. aliases, new concept in, deprecated concepts out etc.) all things that will impact severly on the effectiveness and reliability of your "decision support system" based on concepts hided by hashes values. So I don't think it is a good idea to hide a medical concept  behind hashes and taking decisions based only on the hashes values.

Besides, if I authorize my Doctor to access my medical record, I want him to see it very clearly what my allergy is in terms he can understand. Can you imagine your Doctor watching hashing values supposed to be mapped vs. some medical coded information having absolutely no way to really verify the real concept that may be behind ? Not a good idea. You want compression ? Use compression algorythms. You want security ? User encryption with two ways functions and authentication infrastructure etc. (keep in mind that hashing is a "one-way" function). Just keep using hashing for those things we use them today (to index, retrieve items more efficiently, for digital signatures etc.) NOT to hide/store medical concepts. I would not innovate this way. But may be I am wrong. Is there a better answer to this?


Global variables and information security

Boycott Globals!
I'm stealing from Steffen Ullrich's comment, but the main issue with global variables is that they make it difficult to keep code well organized and maintainable.  His link is a fine one, but you won't have any trouble finding countless articles about the problems with global variables online.
When you use global variables, it becomes easy to lose track of where in your program the variable gets modified, especially if you don't have a simple linear flow.  As a result global variables can work perfectly fine in small scripts, but can cause massive headaches as an application begins to scale.
The main reason why I would avoid globals is because they make automated unit/integration testing a nightmare.  Small applications can survive without tests, but trying to manage a larger application without good tests is just a nightmare (trust me, I tried in my young-and-foolish days).
This might leave you with the impression that globals are fine in very small applications, but since applications usually only grow over time, and things that start off temporary become permanent, it's really just a bad idea to use them at all.  Why start on the wrong foot, when it is so easy to use properly scoped variables?
Security
Using global variables doesn't have any direct implications for security, but they do make it easier to end up with security issues, because it disconnects the source of data from it's usage. I have even seen actual vulnerabilities introduced in such a way:
Imagine you have a variable which is used in an SQL query. Initially you set it from a safe value and so inject it directly into the query. However, it is a global (or becomes a global!) and later on use-cases change and it gets set from user input. The developer who sets it from user input doesn't realize that it is injected directly into a query (perhaps because it happens in a completely different file and only in a specific flow) and so doesn't bother with strict input checking, nor do they update the query it is used in for more secure usage. All of a sudden a very hard-to-find vulnerability has been introduced, because global variables hid the connection between the source and usage of a variable!
Global Variables == death
I don't know of any breaches that happened specifically because of global variables, but it's easy to argue that the use of global variables has literally killed people, so I think it's reasonable to just never use them.


Caching ARP to avoid L2 detection on switched network?

There is no way to avoid sending an ARP request for each target IP address you intend to communicate with on your local link. This is because IP communication over an ARP-type link (like Ethernet or 802.11a/b/g/n) requires an ARP request and response to determine the hardware address (MAC) associated with the IP address you intend to contact.

As mentioned in the comments, Nmap has an option called --disable-arp-ping. However, this does not disable sending ARP requests; it simply offloads that responsibility to the scanner's OS, requiring network-layer (IP) responses to consider the target host "up". This actually results in more traffic being sent. It is really only useful in cases where ARP responses are being spoofed.

There are host discovery options using NSE scripts that do not require sending ARP requests to every possible target address, but they are likely to miss at least some hosts:

broadcast-ping will send an ICMP Echo Request to the interface's broadcast address. Some systems will respond to these, but not all.
targets-sniffer will sniff network traffic for a configurable time period and add any observed addresses to the target queue. This requires the targets to be sending traffic to the scanner, usually broadcast traffic.
broadcast-dns-service-discovery and lltd-discovery are two of many scripts that send broadcast or multicast traffic to elicit responses from particular services on a network.
The targets-ipv6-multicast-* scripts can be used to discover IPv6 addresses on your local network. In addition to directly scanning these IPv6 addresses, you can sometimes use other discovery scripts to gather the host's IPv4 addresses from various listening services.
Other scripts like ntp-monlist or dns-zone-transfer can gather lists of targets from certain services, but require you to know which hosts are running these services.


Link test differs from link location in plaintext view is not visible in Thunderbird

There is not going to be a way to force the link text to be the same as the target URL of the link. Else we couldn't have links.
Since the very beginning, the advice has been to hover over the link to check where it goes. That advice has not gone away, as error-prone as that might be.
To make things easier, you can always turn off HTML-view in your email clients. But that will make HTML-based email very ugly.
Each email client might have tools to make this easier, but that will be up to each email client.


Why is the digest algorithm specified in two places in CMS / PKCS7?

As 5.1 says (redacted and emphasis added):

  digestAlgorithms ... is intended to list the
        message digest algorithms employed by all of the signers, in any
        order, to facilitate one-pass signature verification.
        Implementations MAY fail to validate signatures that use a digest
        algorithm that is not included in this set.  ...

In other words, a receiver/verifier can start from the beginning of the message and:

read digestAlgorithms and set up contexts for those algorithms
read encapContentInfo and run the data, which can be quite large depending on the digest(s) e.g. 2^64 for SHA-1, through the digest algorithm, or algorithms in parallel, and at the same time also store and/or process and/or relay the data as desired; or if "detached" obtain the data from somewhere else and similarly run it through the digest(s) and maybe other use.
read certificates and crls if present and keep them handy if desired and not too large and not duplicating data already available locally; can discard them if desired, conditional on being able to re-fetch them if and when needed using things like LDAP or AIA (including OCSP)
read signerInfos and for each one (of interest) select the correct already-computed digest and use it, plus the signedAttrs if used, to verify the signature, without going back to the data

Although not so clearly stated, this is also the reason many (not all!) structures in CMS are specified as BER, which can at the sender's choice use indefinite-length encoding, instead of DER, which cannot.


What should I do if I type my password in the address bar, or type password in google search?

If you accidentally disclose your password -- either through typing it into the address bar, or in any other way -- it's best to change it.

There's no need for any complicated checklist.  Simply change that password, everywhere that you used that particular password.  This will protect you.

Is it absolutely necessary to change your password if you typed it into the address bar?  Perhaps not -- in practice, the risk is probably modest.  Then again, why take a chance?  If you type it into the address bar, it may be disclosed in cleartext over the network. For instance, if you are currently connected using open Wifi, anyone within range of the network who is eavesdropping could capture your password.  Also, your password could potentially be captured in various logs.  So, at that point, rather than taking a gamble, the safest thing to do is to immediately change your password.  If you do that, you'll probably be fine.