What is the best way to prevent code injection in Apache/PHP?

... "GET http://4x.9x.23x.250:58204/jsip.php?zl=IP&IP=3x.18x.24x.19x&DK=80&DD=RZLWHADALAHBNPRL HTTP/1.0" 301 395 ...

  As far as I could understand, attacker is trying to inject and execute php code from remote site, ...

I don't see any injection attempt here. This looks more like somebody is trying to use your server as a proxy to reach http://4x.9x.23x.250:58204/.... It might be somebody scanning the internet to find open proxies. As long as your system is not configured to be an open proxy there is no need to worry about this, i.e. treat this request as the usual noise you get when having a system accessible from the internet.


Is the Ethereum blockchain truly a tamper-proof way to deploy distributed applications?

It might depend on what you mean by "tamper-proof" and what they mean.

One of the benefits of blockchains is the ability to distribute a ledger of data across the entire network. Each node in the network enforces the integrity of the data for the rest.

If you can somehow express your application in a way that can be stored and verified in the ledger (like a hash of the binary), then yes, the blockchain algorithms would simply take care of the rest. Any unrecognised application would be ejected from the network.

If you went the next step so that updates to the apps were enforced by the network, then it is possible for the apps in the network to enforce a certain level of operation so that if one node was altered, then the rest of the apps would revert the altered node.

Those are 2 different types of "tamper-proof". You might need to ask Ethereum what they mean by the phrase.


Is it possible to read and extract HTTP request headers via JavaScript while performing XSS & CSRF? If so, how?

You might want to look into Service Workers:

A service worker is a web worker that implements a programmable
network proxy that can respond to web/HTTP requests of the main
document. It is able to check the availability of a remote server and
to cache content when that server is available, and serve that content
later to the document. Service workers, like any other web workers,
work separately from the main document context. Service workers can
handle push notifications and synchronize data in the background,
cache or retrieve resource requests, intercept network requests
and receive centralized updates independently of the document that
registered them, even when that document is not loaded.

See also: FHantke's approach to a remote MiTM with Service Workers: https://betterprogramming.pub/man-in-the-middle-attacks-via-javascript-service-workers-52647ac929a2


What's the point of encrypting a session key with a master for file backups?

There are two different requirements in play here: one functional requirement, and one security requirement.

The functional requirement is that the master key should be able to be changed without the need to decrypt all of the data, and the re-encrypt it with the new key.  This is why you have session keys that are encrypted with the master key.  Specifically you have a key-encryption-key (the master key) and data-encryption-keys (what they're calling session keys.)  This means that when you want to change the password that is used to derive your master key, you only need decrypt and re-encrypt the data encryption keys, not all of the data.

The second issues, which is the security requirement, is that it is only safe to encrypt some number of blocks with a single encryption key.  With AES, which uses 128bit blocks, it's quite a lot of data, but it is still a finite amount.  With smaller 64bit block ciphers like Triple-DES, the limit is much lower, resulting in issues like the Sweet32 attack on 3DES ciphersuites disclosed last year.   This is likely why they've decided to re-key every 256 uses, because file backups mean that they're potentially encrypting a lot of data in those 256 encryptions.   When you're dealing with encrypting keys, however, they're tiny.  Only 32 bytes each for AES256, so no matter how many you encrypt with your single master key, it simply isn't an issue.


Is the GTK or MIC in the unencrypted portion of a WPA protected frame?

Answering the title question, NO.

They MIC is only sent over the 2nd and 3rd frame of the 4WHS and the GTK only in the 3rd frame.

And about comparing anything in the 4WHS to any unencrypted portion of a WPA/2 packet is just like @user1451340 said in the comments, only the origin/destination, but these are common for ANY handshake.

What you can do is get an ARP Packet (These are size fixed so you can know which are ARP) and try to decrypt it with the GTK found on the 3rd frame, and if it works, there you got it. Good luck and I hope this helps.


Requirements Placed on a User of a FIPS 140-2 Validated System

Every FIPS 140-2 device must have a publicly available non-proprietary Security Policy document which is obtainable from the FIPS 140 program web site (CMVP - http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm).  Although some Security Policies are far better written than others, there is a minimum requirement for these documents that should explain how to get a module into a FIPS approved mode of operation and what cryptographic services are available while in this mode of operation.


ENUMERATED and INTEGER serve different purposes.  ENUMERATED is for creating a list of named items while INTEGER is for carrying numbers.  The fact that the type notation seems somewhat similar does not make them identical.  For ENUMERATED, the only values permitted are those named in the list.  For INTEGER, the named list is just a set of useful labels for specific numbers, and does not limit what values are permitted for the INTEGER type.

I can only assume that CRLReason was made ENUMERATED because there is a closed set of values while Version was made an INTEGER to leave the number of future versions open ended.

Feel free to try some of these specifications at http://asn1-playground.oss.com, which is an online ASN.1 compiler and encoder/decoder that supports not only BER and DER, but also PER, XER and CER.  You will be able to see that differences between ENUMERATED and INTEGER seem more significant for other encoding rules (such as PER and XER) than they seem for BER and DER.


TL;DR An attacker cannot see anything past the domain.
Structure of a HTTP request
HTTP works by sending two things to a website: the method, and the headers. The most common methods are GET, POST, and HEAD, which retrieves a page, transfers data, or requests only response headers, respectively. TLS encrypts the entirety of HTTP traffic, including the headers and method. In HTTP, the path in the URL is sent along with the header body. Take this example, with wget loading the page foo.example.com/some/page.html. This text, as ASCII, is sent to the server:

GET /some/page.html HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: foo.example.com

The server will then respond with an HTTP status code, some headers of its own, and optionally some data (such as HTML). An example, giving a 301 redirect and some plain text as a response, may be:

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Dec 2017 04:42:54 GMT
Server: Apache
Location: https://bar.example.com/new/location.html
Content-Length: 56
Content-Type: text/plain

Thank you Mario, but our princess is in another castle!

Which would tell the client that the correct location is elsewhere.
These are the headers sent directly to the site over TCP. TLS works on a different layer, making all of this encrypted. This includes the page you are accessing with the GET method. Note that, although the Host header is also in the header body and thus encrypted, the host can still be obtained through rDNS lookup on the IP address, or by checking SNI, which transmits the domain in plaintext.
Structure of a URL

https://foo.example.com/some/page.html#some-fragment
| proto |    domain    |     path     |  fragment  |

proto - There are only two protocols in common use, HTTP and HTTPS.
domain - The domain is example.com and *.example.com, detectable with rDNS or SNI.
path - The path is completely encrypted and can only be read by the target server.
fragment - The fragment is visible only to the web browser and is not transmitted.

What an attacker can see
So what can an attacker see if you make a request over HTTPS? Let's take the previous hypothetical request from the perspective of a passive eavesdropper on the network. If I wanted to know what you are accessing, I have only limited options:

I see you making a web request encrypted with HTTPS going to 203.0.113.98.
I see that the destination port is 443, which I know is used for HTTPS.
I do an rDNS lookup and see that IP is used for example.com and example.org.
I look at the SNI record and see you are connecting to foo.example.com.

This is all I could do. I would not be able to see the path you are requesting, or even what method you are using, short of heuristic analysis based on the sizes of the data being sent and received, called traffic analysis attacks. For a large service like Wikipedia, I would have no idea what article you are viewing based on analysis of the unencrypted data alone.
An important note about referers on older browsers
Even though HTTPS encrypts the path you are accessing, if you click a hyperlink within that site which goes to an unencrypted page, the full path may be leaked in the referer header. This is not the case anymore for many newer browsers, but older or non-compliant browsers may still have this behavior, as will websites which set the HTML5 referer meta tag to always send the information. An example sent unencrypted by a client go from https://example.com/private/details.html to http://example.org/public/page.html in such a case would be:

GET /public/page.html
Referer: https://example.com/private/details.html
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.org

As such, navigating from an HTTPS page to an HTTP page may leak the full URL (excluding the fragment) of the previous page, so keep that in mind.


Do I need additional encryption on top of HTTPS for a REST API?

The communication between the Frontend and Backend is completely unencrypted, resulting in the credentials of a user logging in send over the intranet/internet completely clear text.

  ...the communication between client and server is established over HTTPS.

You are contraditcting yourself. If you are using HTTPS, your data isn't unencrypted.

  ...especially since there are known problems like SSL Stripping, MITM, or even traffic analysis.

SSL stripping is solved by HSTS. Use it. A MITM is exactly what TLS protect against, so I fail to see how that is a "known problem". Not sure what you mean by "traffic analysis", but implementing your own application level crypto is not going to solve it.

I think you are undervaluing what HTTPS gives you.

  Is only using HTTPS for an Web application dealing with sensitive data "secure" enough?

What your question basically boils down to is this: Is transport layer encryption enough, or do I need application layer encryption as well?

For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.

And anyway: You do not trust yourself to configure your own TLS. Why should you trust yourself with the much more complex task of setting up safe application layer crypto? I promise, it will be much easier to just read up on TLS and do that right.

Your collegues provided you with only one argument, because it's the right argument. Use HTTPS.


Wireless client isolation - how does it work, and can it be bypassed?

The implementation that I've seen of this is done by fiddling with the MAC forwarding table on the access point. Since the access point simply acts as a network bridge, it is fairly well suited to this kind of task. At the switching layer it is already collecting all of the heard (sometimes called learned) MACs and which interface it can be found on.

The logic looks kind of like this:

Access Point receives a packet over the wireless interface
Bridging subsystem examines packet for destination MAC
If destination MAC is in the learned switching table for wireless interface -> DROP
Otherwise forward packet via wired interface

Because of the way network bridges work I see this being fairly difficult to trick the access point into forwarding a packet to a client in spite of the isolation. Your best bet would be to attempt to talk directly to the other client, as if you were operating with an ad-hoc network.


How do I measure compliance to Information security policies?

A good information security policy should very clearly state a number of things. At least the following:

The reason why it was implemented
its goals
its scope
its boundaries (the things it does not apply to)
clear requirements towards the assets that are part of the scope
controls that meet these requirements
responsibilities

There are (at least) two kinds of policies that are self-written. The ones that set organizational rules and the ones that set technical rules. The latter are sometimes called 'standard' or 'guideline', for instance 'Guideline for configuring Windows Server 2012'. If you are the person that is giving names, try to give the same name for the policies with the same scope.
A very small policy that sets organizational rules could look like this.

Employees noticed that visitors tend to stare at their screens
To reduce screen staring this policy will be implemented
This policy applies to employees of level 1
It does not apply to employees of level 2 and 3
& 6 All employees are required to lock their screens if they have a visitor in their office. If the visitor needs to look at the screen, because of business reasons, employees have to make sure, that the visitor is only able to see what she needs to see. This can mean to close all other windows, even if this harms productivity while the visitor is there.

7 managers are required to monitor this behavior on a sample basis.

How can you measure compliance with policies that set organizational rules?
You can't really. (and also auditing)
You can ask employees if they comply with the policy. On the one hand this is risky, because your employees will often times answer as they think is socially expected and so will their managers. On the other hand if the process of asking is thorough, this can yield good results. If your employees do not necessarily have to fear backlash if they don't comply with a policy, they will be more honest. A nice side-effect: can also ask them why they don't follow the given rules. There is often a discrepancy between how processes are planned and built - and how they are "lived".
You could test employees with regards to what they know about a policy and its details. But then you will only know if they know about the policy, not if they enforce the rules that are set there.
Because of these problems some organizations do the following: when it comes to policies that set organizational rules.

implement policy
employees have to sign statements that they will comply with policies that are published companywide and that apply to them
publish policies companywide and/or to the respective groups

How can you measure compliance with policies that set technical rules?
Auditing.
The best way to do this, is auditing. There are all kinds of audits with all kinds of different scopes. If you want to measure if your controls are effective (= meet the requirements) and if they have been implemented correctly you should hire an auditor or look up auditing techniques. I would recommend hiring because 1) audits are tedious and 2) having an outside perspective can be very helpful to find flaws in processes and controls.

Get to the point! How do auditors measure compliance?
Well... there are different techniques which really depend on what you want to measure.
There is the basic: X machines of Y, so Z% have vulnerability with a CVSS score of 7 or higher. - You'd measure compliance with a policy that sets rules with regular vulnerability scans.
Compliance will most of the time come down to "yes/no/partly". The rules that have been set in a policy could look like the ones you can see here.
For instance:

"The auditor should verify that management has controls in place over the data encryption management process. Access to keys should require dual control, keys should be composed of two separate components and should be maintained on a computer that is not accessible to programmers or outside users. Furthermore, management should attest that encryption policies ensure data protection at the desired level and verify that the cost of encrypting the data does not exceed the value of the information itself. All data that is required to be maintained for an extensive amount of time should be encrypted and transported to a remote location. [...]"

These can be very easily measured with interviews of experts and technical audits. For instance: what TLS version is in use, how is back-up data encrypted, etc.
There are also more complex goals that can be set up before an audit but these are probably not what you are looking for, because they require complex processes and controls to audit. These things are normally not set up via policies.

In the end it comes down to the auditor and the technique she chooses. If you hire someone, arrange this beforehand.
If you don't choose to audit you will have to define how much risk is reduced after a policy has been implemented and: 1) employees don't know about the policy, 2) employees always comply with the policy and all the varying degrees between these two.


How to enter sensitive information securely?

To simply put, there isn't any "one true secure method".

Why, you might ask? Because computing has always been about trust, whether implicit or explicit.

Regardless if it was the 1960's or today, you trust the machine in question to act like you expect. This can prove quite an issue, because potentially, you could be dealing with a software or hardware based keylogger, to a whole virtualized OS, which would have access to all the memory contents at any give time.

There's no way a user could traverse a massive list every time they sat down at a computer. Somethings are simply impossible, such as verifying firmware on one of the many chips placed into the computing device.

The key part to understand is how much trust do I require? For some corporations and government agencies, this could be down to the firmware level, and expense isn't an issue. To a home user this could be software based keyloggers, and malware. To a researcher, it could prove to be "none" as they only expect to see a correct output from a simulation.

The sophistication of the attack vector(s) in question are important, which is good to see you mentioned a school environment.

It's common to see "monitoring tools" in school computer labs for whatever reason the IT staff, librarian, principal, and/or school board sees fit. You can search the internet for common software, but most do include a software keylogger, hooks to the Windows API to retrieve all gui window titles, and take periodic screenshots.

An on-screen keyboard is sufficient to guard against a spying librarian, as I remember back from my high school days. I even remember writing a program in Autoit to change the title of all active windows I had open to fool the monitoring software (that was from my mischievous days). The software my school used is linked below.

A software keylogger and typical "off the shelf" monitoring software isn't going to log where you click on a screen, it's too much effort. Keepass with it's entry obfuscation can even deter spying users that deploy software keyloggers.

Web Links:

http://keepass.info/

http://www.netsupportschool.com/


It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package):

head -c16 /dev/urandom | md5sum

This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if you have to "type" the password on a smartphone):

head -c16 /dev/urandom | md5sum | tr 0-9 g-p

If you want to type one less characters, try this:

head -16 /dev/urandom | md5sum

(Probability of getting all first 16 random bytes as 0x0A, i.e. the "newline" character, is 2-128, hence this line still gets 128 bits of entropy.)

Still limiting yourself to commands from coreutils, you can do this:

mktemp -u XXXXXXXXXXXXXXXXXXXXXX

This one generates a 22-character password, using /dev/urandom as internal source of randomness (I checked in the source code, and a strace call confirms). The characters are letters (uppercase and lowercase) and digits; since 6222 is greater than 2128, the 22 characters are sufficient.

Yet another one:

od -An -x /dev/urandom | head -1

this displays eight sequences of four hexadecimal digits. Arguably, this split into small sequences may help reading.

For a much longer line and a quite distinct kind of password, try this:

for i in {1..8} ; do head -$(expr $(head -c7 /dev/urandom | od -An -t dL) % $(wc -l < /usr/share/dict/british-english)) /usr/share/dict/british-english | tail -1 ; done

(this one works only on a 64-bit host; will you notice why ?). Apart from coreutils, that version also requires a dictionary file, here the one for British English.


Confusion about trusting certificate chains

From the RFC 5280:

  A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key.  If the public key user does not already hold an assured copy of the public key of the CA that signed the certificate, the CA's name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates may be needed...

The server (from your question) validates the copy of "a certificate containing the required public key" first by checking its trust store. If C3 is in the trust store, there's no need to check anything else. If not it proceeds further.

Notice the potential form in the RFC: "it might need", "may be needed". It is not required to check the whole path if it already trusts a certificate.

Also take a look at this answer describing the difference between X.509 and TLS.


What is a good reason for persisting OAuth credentials?

There are Access Tokens and Refresh Tokens.

The Access Token is typically short-lived (think 30 or 60 minutes), and there is no reason to persist it after it has expired. It has no use to anyone.

The Refresh Token is required to obtain a new Access Token, and is typically long-lived; at least as long as an active session.

If an attacker gains hold of a Refresh Token, they have all the access that the user would have if they had logged in with that token. However, they have access to session(s) for which that particular Refresh Token authorizes them. (Meaning that, if the token was granted for less than normal privilege for that user, the attacker would be at the same lowered privilege).
Also, since it's not a hashed password, they cannot derive the plaintext password from it with rainbow tables.

A Refresh Token can be retracted at any time, without requiring the user to change their password.

From a security point of view, using a Refresh Token instead of requiring the user to log in again protects against shoulder surfing. The drawback is that if the attacker has physical access to the device that contains the Refresh Token, they don't need to authenticate either.

Be careful when deleting the Refresh Tokens. An expired Refresh Token has no use to anyone, and can be safely deleted. But deleting an active Refresh Token requires users to log in again; causing them unnecessary inconvenience.

Make sure the database containing the active Refresh Tokens is properly secured. They are typically not hashed like passwords are.


For all practical purposes, there is in fact a whitelist in effect here.

The parameter isn't a file name per se, but a view name, only useful for loading an instance of an already compiled view which is a type implementing the IView interface, from the application. Giving it arbitrary file names, or any content that isn't the name of a view in the context of this controller in this application, and you'll get nothing.

So no, no vulnerability here.


How to distinguish between a scam and a genuine call?

If you're worried about the authenticity of a cold-call, don't try over-the-phone authentication in either direction. Simply ask for some basic information you can use to refer to the issue in follow-up:

Name of the company/service the account is for.
What is the nature of the issue/offer the caller wants to discuss?
Is there a reference ID (e.g.: ticket #) for the call?
Name and/or agent ID of the caller.

Important: Throughout this process, you should not ever give the caller any more of your information. The main point here is to assume that someone calling you like this is an attacker, for the entire duration of the initial call.

Question #1 should be answered by the caller before you even have to ask. Be especially wary if it's not. My wife once argued for a good couple of minutes with someone calling from the "Account Services Department", before she finally handed the phone to me. When I interrupted the caller to ask "Account Services Department for whom?" the caller suddenly hung up.

After you've gotten all you can from the caller, hang up. Then, obtain legitimate contact information for the company from a reliable source (do not use any contact info given by the caller, without verifying it first).

Once you've got known-good contact information, call the company yourself and ask about your account's status. Use information obtained from the caller as needed, to reference the incident.


Do I need to create a user in my database?

This question could be interpreted many different ways:

should my Database use a non-root user

Yes, you should create a non-root user (one for each unique app accessing the database to prevent your wordpress-db-user (do to some random wordpress exploit that comes out in the future) from having full access to your super-fancy-custom-web-apps-db and getting a full list of all of your users emails that you have been collecting.

should I create a user's table in my databse

Authentication or no ... this is kinda a no-brainer.  If you want to be able to link johndoe@qmail.com to his preferred alias super happy fun guy ... or one of your users decides that qmail sucks and they want to change there accounts email to johndoe@qahoo.com ... a users table with an internal UUID per user might be very useful.

do I need to store user-password-hashes for login

Yes and no ... putting full faith in some other websites authentication might save you from having to worry about having your local db hacked and having to report that a few thousand of your user's password hashes are out in the wild.  But at the same time, if a vulnerability is found in this third party's authentication it could very well leave you in a worse situation since you have no control over the third party patching it ... and nothing to fall back on if this third party decides to charge for this auth service or just discontinue it all together.

This is more of a business decision than a security decision ... there are lots of pros and cons of going each way.


I know of two pieces of research in the research literature that study the incidence of vulnerabilities on different platforms:

An Empirical Analysis of Input Validation Mechanisms in
Web Applications and Languages.  Theodoor Scholte, Davide Balzarotti, William Robertson, Engin Kirda.  SAC 2012.

This paper analyzes over 7000 CVEs that reported XSS and SQL injection vulnerabilities in 79 web applications.  Then, it uses this data to estimate the prevalence of different kinds of input validation vulnerabilities in different web programming languages.

The paper's analysis finds some differences between languages. For instance, in the data set, 50% of web applications were built in PHP, but 80% of SQL injection vulnerabilities were in PHP applications, so the paper concludes that web applications written in PHP may be especially at risk for SQL injection.  In contrast, web applications written in Java appear to be less prone to XSS and SQL injection vulnerabilities.  See the paper for more discussion.

Exploring the Relationship Between Web Application Development Tools and Security.  Matthew Finifter and David Wagner.  WebApps 2011.

This paper analyzes the relationship between the choice of programming language and web development framework vs security, by looking at code from 9 teams who built the same web application (same spec, same functionality) in different languages.

The paper does not find any evidence that choice of programming language affects the security of the resulting application.  The experiment does find evidence that the degree of support for security (particularly automatic support for escaping, sanitization, session management, etc.) benefits security.  It concludes that, because of the small sample size, additional experiments would be helpful to gain a deeper understanding of the effect of programmer tools on web security.


What attacks does a W^X policy prevent against?

W^X and "Once-writable, never executable" are both sub-cases of DEP. DEP is about making read accesses, and execution accesses, distinct (a writable page is also a readable page). W^X is about using DEP to enforce a specific policy, which is that a given page can never be writable and executable at the same time.

Compliance to the W^X policy can be required from the programmer because writing "data" and then executing it reliably entails flushing some caches, which is an explicit and expensive operation. Going through the kernel (with a mprotect() call) is not a hard way to do that. On the other hand, forcing the programmer to do such things explicitly means that it will not happen in other situations, namely when an attacker tries to exploit a buffer overflow. This is a generalization of the "stack is not executable" feature. (The buffer overflow is still there, though; W^X just makes life harder for the attacker.)

The "once-writable, never executable" policy looks suspicious to me: it is incompatible with JIT compilers. Anyway, it would be a sub-case of W^X: like W^X, in which the transition W->X is forbidden.


It's "secret" enough to be used as the key to a cipher, but it might not be long enough. The concept of key stretching was invented to bridge that gap. Basically you run the small secret through a cryptographic function to create a big secret.

An algorithm specifically designed for this function is PBKDF2 ("password-based key derivation function version 2"). It does very much precisely what you're looking for. You can use this same algorithm with slightly varied inputs to create multiple independent keys.


When do you use OpenID vs. OpenID Connect

I don't think either of the other previous responses answer the question, which is asking the difference between OpenID Connect and OpenID 2.0.  OpenID 2.0 is not OAuth 2.0.

OpenID 2.0 and OpenID Connect are very different standards with completely different parameters and response body formats.  Both are built on top of OAuth 2.0 by putting additional values into otherwise valid OAuth 2.0 requests and responses, in order to provide identity information needed for authentication (whereas OAuth 2.0 only provides authorization, not authentication).  OpenID Connect improved naming and structure of OpenID 2.0 fields and parameters in order to be easier to use.  I can easily read the OpenID Connect specification and understand what all the values are used for and what to set them to, but trying to read the OpenID 2.0 specification is a bit more difficult and convoluted.

At this point the choice is easy, OpenID 2.0 is deprecated.  You should use OpenID Connect.


How is resynchronization performed for security keys / MFA devices?

For time based tokens there are basically two methods.

First of all, as the time In a token cannot be manipulated (either it is a isolated frob with bad clock or it is hosted on a system where you cannot influence the clock).

So what needs to be done is on the authentication server, you keep a estimated time offset (or more complex compensation model) and adjust it on each login.

Basically you compare the input from the current authentication with a few codes before and after the current code. If it matches you know a offset to apply next time.

This correction method can be as complicated as you want, since you don’t want to allow an attacker to influence your estimates or you don’t want to make the window too big as it allows more guessing. (For example keep a history of the latest 3 authentications and offsets and do a linear regression to find not only the offset but also the slope of difference)

If you decide that the time drift is too big (or you have no initial data for prediction) you ask for multiple entries. This will reduce the risk of accepting a repeating code (in a too wide timespan).

For the initial registration you probably want to allow a wider timespan before you reject a token (however be careful if the token has a broken clock and you accept the registration you might risk that a future login fails, which is more annoying than rejecting a device registration)

The exactly same mechanism applies to counter based systems as well (with the additional task to account for missed timer updates and luckily never negative offsets)


Is it possible the person sitting across from me at Starbucks was trying to hack my laptop?

No, you are just being paranoid.

You were probably already connected to him over WiFi. There are many attacks he could have run this way without additional devices. Also if he would have wanted to hack you, he would not have thrown his strange hacking device in your face. He would have hidden it below the table.

Side note: I feel like most of the people saying they have been hacked are only paranoid. While most of the people who actually have been hacked do not notice it at all.

Also see VolleyJosh answer about the device.


What isn't documented, is not documented. All we can do is infer.

From the documentation, we see that the password must be re-entered in a number of conditions (drive unplugged, computer shut down, computer put to sleep...) which boil down to: the drive was not powered at some time. This hints at a security feature done on the drive itself, not in software on the host computer. Page 27, we also see that a locked drive can still be used on a machine where the WD software is not installed, provided that you still use the software for a one-time unlock operation (this application is shown by the hard drive to the computer as a virtual CD-ROM emulated by the USB firmware on the drive). This reinforces the idea that everything occurs on the drive.

The screenshot page 26 shows a warning to the effect that WD themselves won't be able to recover the data when a password is lost, so it is probable that:

The locking uses encryption.
The encryption uses a key which is derived more or less directly from the user password.

Since the user password can be changed (page 28) without implying a complete re-encryption of the disk (it would take some non-negligible time, e.g. one hour), one can surmise that the drive data is encrypted with a drive-specific key K, which never changes, and that key is stored somewhere on the disk (possibly in some EEPROM) encrypted with a password-derived key. When the disk is unlocked, K is decrypted with the password, and kept in some RAM on the disk (disks have RAM, several megabytes, if only for caching). This is lost when the power is cut. When the user changes his password, K is decrypted with the old password and re-encrypted with the new. When the password is removed, it is actually replaced with a convention password (i.e. the data is always encrypted with K).

This is about the amount of what can be deduced from the information. Then we can make some guesses:

The encryption with K does not include checked integrity (i.e. no MAC). I assume this because a MAC requires some extra space (just a few bytes) which would destroy the nice powers-of-two sizes of individual sectors. Adding a MAC would likely increase development costs or decrease performance or both; since they don't boast about it, chances are that there is no MAC.
The derivation from the password to the key which encrypts K is probably weak, because:

Strong derivation would use a random salt, which then requires a source of randomness, and there is no reason otherwise to have a dedicated chip for randomness on the drive. Economics being what they are, chances are that there is no random salt.
The hashing process cannot include many iterations because they would have to be computed by the CPU embedded in the drive, which is not nearly as efficient for number crunching as a basic PC (again, economics).
Despite repeated pedagogical efforts, nobody in the industry seems to be able to do password hashing properly. I shall soon have to resort to threats; they just don't want to learn.

Encryption itself is probably based on AES, because there now are disks with flaunted AES-based encryption, so disk manufacturers have the dedicated chips and know-how. Using another encryption algorithm would just be more expensive for them, so chances are that they abstain (there, economics induce the vendors into doing the right thing).

But nothing guarantees that AES was used properly. Good hard disk encryption needs some specific encryption modes (the arguments against extra storage for a MAC and against the presence of a hardware RNG also apply here: encryption is probably not CBC with a random IV). If the manufacturer just used ECB (a really bad idea in this case), you would not know it.

Conclusion: the locking feature may be good, but there is a high probability that at least parts of the system are weak (probably the password derivation feature, and the encryption mode). You cannot build a reasonable security strategy on unknowns, so a cautious should prefer a software-based solution where the involved algorithms are known and are applied properly (e.g. TrueCrypt).

Also, note that the software used to unlock the drive does not appear to have a Linux version, so this may reduce interoperability.


Is it possible to force a browser to use http in an ssl enabled (https) website?

A page which is secured with SSL (or TLS for that matter) cannot be accessed via HTTP, as that would mean that the page is not secured anymore.

If I rephrase the question: Is it possible to access a particular page of a HTTPS secured website via HTTP, then I would say that is possible, but very INsecure. Moreover, the cookie with the session ID will probably have to be sent along with every page request, as you need to track the session across several pages. That would imply that you need to serve almost every page over HTTP, which thus renders your site insecure.

In case you need the session cookie on only one page, you could tell the client to carry out a HTTP request to that one page, which will then sent along all cookies that don't have the 'secure' flag set. However, this means that all these cookies are vulnerable to a MITM attack, and can be read by anyone listening in on your communication.

My advice: do not ever consciously serve a page of a HTTPS site over HTTP.

So, the question you need to ask yourself is why can't my session ID be tagged secure only. Is it laziness, or is there another reason why you cant tag this cookie as being secure?

By the way, to force a browser to always use HTTPS for a website (and not rely on 302 redirects to visit the HTTPS version), HTTP Strict Transport Security can be used. Please refer to OWASP for more information.


Why is my phone connection secure without a password when WiFi is not even with a password?

WLAN/WiFi can be secure when properly configured (this certainly requires a password or key).
Cellphone connections are not really secure. They are encrypted based on a key from your SIM card. This key is also known to your mobile network operator. You do not need a password, but your communication can be intercepted and eavesdropped on by your mobile network operator and law enforcement. The A5/1 encryption used for GSM is actually completely broken.
The reason why this is not done for WiFi is because you do not want an extra SIM card and you do not want your ISP to specify your password/key for WPA2.
You always need a key, password or certificate to authenticate and key/password to encrypt your communication. This information can be stored in various places, like your SIM card or your brain.
Additional information due to comments:
There are several reasons why using SIM cards for authentication to all WiFis in general would not work.

The WiFi access point would need to support EAP-TLS, EAP-AKA/SIM or similar which allows authentication with a SIM. Your device  (e.g. smartphone) needs to support this authentication as well as the access point.

The WiFi access point would need to contact the mobile carrier and check whether the connection should be allowed or not. This has two problems a) ISPs are not necessary the mobile carrier, b) how do you limit who has access to a WiFi. Not everyone with a SIM card should be able to access a WiFi unless authorized to do so. This means either WiFi operators hand out SIM cards for their WiFi and you end up with lots of SIM cards or they need to tell their ISP who tells all mobile carrier which SIM cards are allowed. It would need to be done manually, because you cannot foresee who might want to access your WiFi in the future. This would mean major costs in infrastructure and staff, not to mention time for connection setup.
The other way to manage it, is to setup a RADIUS-server (see comment of billc.cn). This also requires manual registration of allowed SIM cards and a SIM card reader. You would be able to manage access locally (which is good for security), but it is not the universal access you have asked for in the comments.

You would loose control over the security of your WiFi if the authentication is done by your mobile carrier or ISP. They can control who can access your WiFi and are even able to see lots of meta-data. They would know which person accesses which WiFi and also when.
Even if I have barely scratched on the surface of problems, you see why this is not easily done. You would need new hardware for your WiFi access point, likely your device that you want to connect and the ISPs and mobile carriers would need to adjust their infrastructure too. This makes it entirely infeasible.

Today it would be possible to use a SIM and manage access locally for a WiFi, but this means the SIM is just a substitute for authentication by password and the setup isn't simplified.
Your idea would work for access points operated by your mobile carrier, but as we already have mobile internet through LTE and similar technology (which is not the same as WiFi!), it will not take a central role . Especially since the mobile carrier can charge money for mobile internet usage, which is obviously in their interest. If you have a subscription to special services, some mobile carriers and ISPs offer access to hotspots, that can be accessed through EAP-SIM (thanks billc.cn).


Detection of abnormal file access patterns

It looks like you want to consider Data Loss Prevention tools (https://en.wikipedia.org/wiki/Data_loss_prevention_software).

However before you go straight to the technology solution, you have to understand what "normal" file access looks like.  If you do not know what that looks like it becomes impossible to know what abnormal looks like.  This is similar to teaching IDS/IPS what the network looks like.


EDIT: Thank you @VenVen for pointing out the \Windows\Temp dir!
The system-wide temp directory on Windows is %SystemRoot%\Temp (C:\Windows\Temp, typically). You can also use the %ALLUSERSPROFILE% (which is almost always C:\ProgramData on modern Windows versions). The ACLs on both directories are very similar to the *nix Sticky directory permission bit as set on /tmp: all members of the "Users" group (so, anybody except anonymous users and guests) are allowed to create files and directories within the directory itself (or any subdirectories you created), but only the owner of a file or directory can access it once it's created (by default; the owner can of course modify the ACLs to grant access to others).
A few differences:

\Windows\Temp does not allow read privileges (for non-admins) within itself, meaning you have to know the path to the file or directory you're opening without listing directory contents. This might be inconvenient but it also makes it harder for a non-admin to see your files.
ProgramData is a hidden directory (merely an advisory flag, equivalent to a *nix dotfile), but does allow listing by normal users and a ton of stuff gets put there by, which may make your additions not stand out.

For that matter, the ACLs on the root of the system drive (C:\) are similar, though more restricted; you must create a subdirectory rather than putting files directly under the root, and only Authenticated Users have this permission (meaning it might not work if impersonating a user without their credentials). It is more likely to be obvious to a user, of course.
You can also check the %TMP% (or %TEMP%) environment variables for a user-specific temp directory. This might not be set, or not set usefully, for non-interactive service accounts or other situations, though.


You are certainly on the right track but it is possible that you're making it just a bit more complicated than you need to.  You have correctly identified that a symmetric encryption system creates the significant issue of the decryption key being present on the system.

If you choose to generate public/private keys for each piece of data, you may be making your life unnecessarily difficult in addition to "handling" the private keys in a non-optimal location.  If you are married to the data being encrypted with the user's public key, the following can be modified to store two copies of the encrypted symmetric key.  In this case it would be best to allow the user to generate a keeper and provide you with the public key rather than generating the keypair for the user.  (In other words, you really don't want to handle the private key)

In a trusted location, generate a public/private keypair for the server/application
Copy the public key (only) into the application path between the user and the database
Whenever sensitive data arrives, generate a random secret key and use this key to encrypt the sensitive data using a symmetric algorithm (such as AES)
Encrypt the random secret key with the application public key

There are a number of things that are ideal about this approach:

Backend systems and users with a business need and the proper rights can use the private key in a separate system to retrieve the sensitive data
Since only the private key can be used to decrypt the random secret keys there is no useful attack surface aside from raw brute force for an attacker who compromises the application
The effectiveness of a brute force attack is dramatically reduced since a successful attack against any of the random secret keys provides access only to that single piece of data; all of the other keys are different.  This makes a brute force attack very unattractive against the symmetric keys.
Currently a brute force against a, say, 4096 bit public/private keypair is considered intractable

So, again, you've got the right idea, but you may want to simplify your approach just a bit!


AngularJS Sanitize function vs. server-side output encoding

tl;dr:
Encoding should be done at the time the data is being used in context - when the code is composing HTML, javascript, etc from untrusted data - that's true whether you are composing on the server or client.  At that point you know what parts are data, and what the encoding context is.  You should leverage binding (ng-bind) in Angular for context specific encoding. The AngularJS Sanitize function is useful when you need to "sanitize" a hunk of untrusted HTML.

Details:
Its good to be careful when the term "sanitize" is being used, because different libraries use it differently - it can mean validation, canonicalization, simple encoding, parsing and encoding.

The AngularJS Sanitize function  "sanitizes" inputs by parsing the HTML into tokens. All safe tokens (from a whitelist) are then serialized back to properly encoded values.  In this way it behaves similarly to
the OWASP HTML Sanitizer Project and the older OWASP Antisamy project.

See
https://odetocode.com/blogs/scott/archive/2014/09/10/a-journey-with-trusted-html-in-angularjs.aspx for more information on using the library.

This is a fine way to encode untrusted input if you don't have the luxury of composing the HTML, javascript, or URL from its parts.  However:

The parsing and removal of tags is more prone to being bypassed - I don't know of any current issues
It modifies the HTML to remove unrecognized tags, which can sometimes be fragile
It has to make assumptions about whether the underlying content is encoded
The tag support will be limited to the white list - however, you can decorate the $sanitize service to change the list

So where you can:

Encode at the time the data is being used in the context - for example by using binding.
Leverage the Sanitize function if you didn't compose it
Try to leverage CSP (Content Security Policy) as a defense in depth


Am I actually seeing a Man-in-the-Middle when pushing to GitHub?

Yes, what you are seeing is very likely a man-in-the-middle attack. Without more information on your exact situation, all that we can tell from what you've said is that this specific hotspot is intercepting your SSH connections and presenting you with a different fingerprint. I suggest you try connecting to other SSH servers that you have already trusted fingerprints for (but not completing the connection, for obvious reasons) and seeing if the same behavior occurs.

  I'm taking for granted that I shouldn't attempt to bypass the normal ssh protections. If they're really inconvenient I guess I should just use a VPN or my own hotspot?

Yes, either use an end-to-end encrypted VPN (OpenVPN and IPsec are both good protocols for this), or your own Wi-Fi hotspot, encrypted using WPA2-CCMP with a strong password. You don't need to buy an expensive commercial VPN for this. You could configure your router to act as a VPN server and connect to it from the public Wi-Fi, ensuring that you are always using your home ISP's network.

  Should I treat that wifi network as suspect in other ways? Should I trust that my (https) web is secure?

Consider it to be compromised. You can generally trust websites using HTTPS because their certificates are signed using a trusted Certificate Authority, but an attacker on the network will be able to tell what website you are visiting and would be able to tamper with any unencrypted or weakly encrypted connections. They may also be able to exploit unauthenticated automatic updates as well.

  Is this a problem that I should ask/expect the business owner to fix?

It might be worthwhile alerting them, but remember that they most likely don't even know what SSH is, much less what to do about a potential MITM attacker. It's not like the business owner can do anything about it anyway, even if they are tech-savvy. Even if they are not using open Wi-Fi and have set a strong password, anyone who has that password can treat the Wi-Fi as if it were completely open and unencrypted. This will change when WPA3 with its opportunistic encryption becomes standard, but until then, there's not much that can be done. It's not like you can expect them to track down the source.


Secure authorization for subscription-based games or services

Scenario 1: the player can sniff the network.

This can be kind of prevented with HTTPS.
Only, if the player has full control of the client he might patch the client in order to provide and maybe modify the plain text information directly at the application (i.e. game). But this is not covered by your assumptions in scenario 1.

  Scenario 2: ... and has access to the source code of the game (not of the server).

Make sure that the source code the client has is not sufficient to play the game, i.e. implement relevant parts of the games logic out of reach of the client: at the server. How this can be done depends a lot on how the game works.

Apart from that you can try to obfuscate the code to make reverse engineering harder, digitally sign any messages from the server so that an attacker cannot fake these (although he might just change the code to disable the signature check) ... But at the end you can only make it harder and not impossible. Knowledgeable players might for example try to write their own server which implements a similar game logic you have in order to be no longer dependent on your servers.

This means is must be easier and more attractive to pay you instead of trying to hack the game. It can help for this if the game is cheap enough to begin with. Or if there are attractive out-of-game items which make it worth to pay.

As for making hacking harder it might be useful to have several versions of the game with different kind of protections in it so that "generic" hacks will only cover few of the game versions which makes it again more cheap just to buy instead of to hack the game. Or make parts of the communication specific for each game installation, i.e. depending on the user id user for authentication. Another way against the spread of generic hacks is to release new versions regularly which interact differently with the server and which would require the development of a new hack, thus frustrating users which rely on the hacks instead of paying.


OAuth2 client registration: should redirect_uri be unique across clients?

There's really no good way to even securely guarantee that a client is what it says it is, so there's really no point in trying to make each redirect URI unique to a single client. The only reason why you register URIs to begin with is to prevent the open redirect scenario mentioned in the documentation, which would make it trivial to say, configure an evil client that you redirect to after authentication, allowing it to masquerade as a benign client. It does not solve problems like DNS poisoning or host-file modifications.

Since there's no way to guarantee that a client is the same requester as the last time it made a request, because of the stateless nature of HTTP servers, what this means in the long run is that you'd have to issue a nonce each time the client wanted to connected by some secure side-channel, and authorize the request that way. For private clients, that may as well be impossible, because someone could figure out how to do so by reverse engineering the app that does this. For public clients, this would be feasible, but would add extra complexity and a small delay for each request.

There's no scenario that makes a unique client constraint more secure than not having such a rule, because any way that could be used to bypass one could also be used to bypass the other, it just adds a layer of obscurity. It wouldn't even trivially slow down a determined attacker in the case of a private client, and public clients are protected through other means anyways (including a client secret, a type of password that only that client should know).


Trying to create cert for RSA and Not ECDH

You got this: TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM, but you wanted: TLS1.2, RSA, and AES_256_CBC with HMAC-SHA1
There are two different but related things here: the algorithm in your certificate, and the configuration of your TLS server.
So you made yourself an RSA signing certificate, and you configured your TLS to offer cipher suites with ECDHE key exchange and RSA signature. You are looking for a cipher suite that does RSA key exchange, which is probably not going to work with the certificate you created.
I won't do all the work for you, but I'll give some pointers: first, to get a certificate that can work with RSA key exchangeyou'll need a certificate with keyUsage = keyEncipherment. Check the cert you have; I would bet it's keyUsage = digitalSignature, in which case you'll need to edit your openssl ca config file to list (see this article)
keyUsage   = critical, keyEncipherment

and then you'll need to edit your openssl tls settings to add the RSA key agreement ciphers (see the openssl man page). Good luck!


Found DSA and RSA private keys hard-coded in a file during penetration testing. How to use them for SSH authentication?

If there are configuration files for ssh server, they are probably server host keys and you are not able to log in with then anywhere. Only to perform Man in The Middle attack, if you would be able to spoof DNS/DHCP.


URL shortener who does nothing according to the owner

This does not sound like anything malicious or even special. It is not that hard to have personal URL shorteners which do just what the name suggest: provide a short URL. These are much easier to share with others than a long URL. There is no need to have extra functionality on top of this when all one wants to do is to provide a short URL.
Also, if somebody wants to share a malicious link they can do just this. It is not clear from a link what is behind it, i.e. not clear if it is malicious or innocent. A URL shortener does not add any layer of obfuscation here since it is not clear from beginning.
This is different with public URL shorteners though: a established and kind of trusted public URL shortener can be used to hide links to malicious resources behind a trusted site. But this is not the case here - the private URL shortener has no more trust than the long URL it points too.


Is ssh and public key scheme like ed25519 as safe as the hackability of your computer?

Public key cryptography in conjunction with SSH provides  a way better identity checking  than password authentication. An entity must possess both the private key and the correct passphrase to authenticate itself to another entity. You don't have to store you private key on the server. For example, when you create a pub/priv key pair with for example PuTTgen you keep the private key private and upload only the public key to ~/.ssh/authorized_keys. So if someone gets in the possession of you private key, then yes, nothing can stop him/her to access your server. However if you set a passphrase on your private key then the private key is further encrypted using a symmetric encryption key derived from  that passphrase. Oh and when someone can hack your computer then you have much bigger problems than worrying about him/her gainging access to your .ssh directory. But in general the answer to your question  My last defense is the fact that I have encrypted my private key usinga passphrase. is yes.


Using LDAP for application authentication

There are always risks. The real question is which approach gives risks that are more acceptable to your situation.

The use of LDAP for this is a tried and trusted solution that is well used and well supported. So that is a definite positive. Your bespoke auth is potentially poorly tested and, well, bespoke! How do you prove the risks associated with it? That might be unknowable without spending money on getting it professionally tested.

I would say though that there is LDAP and then there is LDAP! If they really mean that you would be using Active Directory along with the Microsoft standard tools for authentication and authorisation, that makes a whole load more sense than if they are simply saying "let's just use LDAPS".

Vanilla LDAPS may be no better than your current solution. But it might still have advantages if the current solution has minimal support and maintenance.

Bottom line is that off-the-shelf solutions, especially when using well tried industry standards are almost always better than bespoke ones for standard tasks. And are likely to be better supported and tested. But adding a specialist toolset is likely to be even better. Use open standards wherever possible as it makes integration and maintenance a lot easier. So using OAuth for example.

Incidentally, LDAPs isn't difficult to set up. Active Directory can be difficult if you don't already have a Windows infrastructure. If you are already using AD in the same environment as your application and users, it is a bit of a no-brainer.

Assess the risks, impacts and benefits of each without the emotion of protected territories. This should be a documented risk assessment, probably with a benefits matrix.


Is a SHA-256 signature required on a CSR in order to generate a certificate with SHA-256 signature?

There is no technical reason that would prevent a CA from issuing a certificate with a SHA-256 signature, even if the CSR was signed by the requestor using some weaker signature algorithm.

The purpose of the signature in the CSR by the requestor is to prevent someone from requesting a bogus certificate containing someone else's public key.  It is the responsibility of the CA to verify the signature in the CSR (signed by the requestor using the private key corresponding to the public key contained in the CSR), using the public key contained in the CSR.  Assuming that the signature is verified, the CA then goes ahead and produces a certificate containing the relevant information from the CSR (e.g. the common name, public key, etc), and then signs the certificate using their own private key, using whatever signature algorithm that they choose (usually SHA-256 nowadays).  Of course, the CA could reject the request if they feel that the signature algorithm used by the requestor to sign the CSR was not strong enough, but that would be at their discretion.  But as you can see, there is nothing that would prevent the CA from issuing a certificate and signing it with a SHA-256 signature, so long as they were satisfied with the signature by the requestor in the CSR.


Getting real machine information from a virtual machine

Ideally, the virtual guest is not able to see anything from the host. But the world is not ideal. Here we go back to the discussion of Joanna Rutkowska. She developed a technique to determine  to test if you are living in a virtual environment. It was called the "red pill".
Joanna just provided a proof-of-concept, which you can see in https://stackoverflow.com/questions/46267618/red-pill-detect-virtualization
It, however, does not mean that you can just read (or even write!) all sorts of host data.
Some virtualization techniques provide explicitly some information for their virtual machines. If you are running Windows as a Hyper-v  client, you can see in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters that you are a guest. If you use Vagrant, you will see a directory vagrant somewhere. This directory may also be available to your malware.
And there is always the possibility that a form of malicious software made a new discovery how to access the host from a guest. We may think that is not likely, but we also thought that of processor-microcode.


The dangers of WAP-billing include:

Highlevel of difficulty to stop or recoup unintended payments once initiated.
Susceptibility to clickjacking attacks through poorly or maliciously designed mobile web pages and applications.

WAP-billing will automatically add a line item to your mobile bill once you have confirmed the transaction (click). If you pay your bill automatically - it can certainly lead to automatic debits through your mobile provider. Disputing these charges with your mobile provider can be quite difficult because your mobile provider provides the initial payment on your behalf and then passes the charge along to you via your bill.

The information transmitted during each transaction will vary based on the payment gateway used and in some instances does include the mobile number. However, There seems to be geographic restrictions for the inclusion of this information based on a review of WAP-billing payment gateway service offerings. Since the payment is coming directly from your mobile provider there is no reason for any additional information (name, address, etc) beyond what is gathered when you land on the mobile site to begin with to be included in the transaction details.


What are the risks of not patching a server or hypervisor for Meltdown?

Basically, if you run code from untrusted sources on a machine that has data you don't want that code to have access to, you need to patch.  Desktop computers should be patched because they've got an unfortunate habit of encountering untrusted code; shared-hosting servers, particularly virtual private server hosts, must be patched, because Meltdown lets one user access every other user's data.

Note that the Meltdown attack cannot be used to break out of a virtual machine.  You can break out of a container, sandbox, or a paravirtualized system, but performing the Meltdown attack in a fully-virtualized system just gets you access to that VM's kernel memory, not the host's kernel memory.


What is a login flow method to prevent account jacking when your website has Email/Password sign in AND Google Sign in?

This is an interesting problem. I would expect that in most cases the user does not remember that they had created a "real" (locally managed) account or that they want to switch to single-sign-on using their Google account.

I don't really see this as a potential attack vector since the attacker would need to have access to the Google account already which likely means that they have access to the users email too.

That's why I would suggest to provide the user with the information, that there is already a "real" account with this email and offer to switch this account to a single-sign-on using Google. If the user agrees a proper verification that the user has access to the email should be done anyways, similar on how this is done with a password reset with locally managed accounts.  If the user instead does not want to switch the existing account they should be presented with the normal login option, i.e. logging into an account which is still locally managed with Google SSO should not be possible in this case.


Suspicious wifi networks from distant places and hotels

No, it's just an evidence there are other Wifi network around you. These other Wifi networks most probably belong to other people or companies. You would be able to connect to them only if they give you the associated password, without that you can only see that they are here without being able to actually connect to them.


Is it safe to run a potentially malicious ISO in a VM using VirtualBox?

You cannot be entirely sure it is safe to do so by the simple fact that when you download a potentially infected ISO, it may be enough for the malware to trigger and do whatever damage it's programmed to do on the host system.
There are backdoors that may be successfully deployed only by previewing an infected file in thumbnail mode on Windows Explorer.

Now assuming the malware is only in the OS contained in the ISO, I would say that unless it contains specific payloads which would target virtualization software hence escaping VM constraints, you should be fine if you do not enable networking, do not share drives, do not allocate excessive resources and do not give access to peripherals to the VM.


Running a local server inside a virtual machine disconnected from the Internet - is this secure?

The answer to your previous question was wrong. Running a web server accessible only at 127.0.0.1:80 is secure in that context, unless you are forwarding packets from the VPN interface to loopback.

To answer your current question: Yes, the web server would be unreachable outside of your VM, but it's not needed.

Personally, I would do my browsing via the VPN inside of a VM to potentially limit any client side exploits (browser, etc)


Isn't it less secure to use something you are for authentication?

Whether something is "more" or "less" secure depends on a lot of things including the perspective of the person designing the mechanism.

In this example from the perspective of your boss, using fingerprint scans could be more secure for two reasons.  One the percentage of thieves who will cut peoples appendages off is likely lower than the percentage who would steal something from your pocket.  Two, with a fingerprint system if there is a risk of insider collaboration with thieves a fingerprint scanner means that it can be proven (assuming they haven't had that finger removed) which employee was present at the time of the theft.

None of that means that this is better from your perspective of course in fact as you say, losing an appendage is way worse than being pick-pocketed or beaten up for a password.

Also in all this I'm assuming that there's no way to bypass the fingerprint sensor. If I was you, you could point out to your boss that most fingerprint sensors are bypassable by people lifting prints from things like a glass in a bar and once you've lost control of the print, these systems can be worse than useless (e.g. if a criminal has all 10 prints, they can always get access past the system and there's nothing you can do to change your prints)


Why host third party libs instead of relying on CDN, Nuget, GitHub?

What security does self-hosting provide if I already trust the package author & contents?

Including content from a third party system outside of your control does not only mean that you need to trust the authors of the content to not willingly add malicious content but that you also need to trust them to keep their systems available and secure. In other words: including content from a third party host makes your vulnerable against DOS attacks to this hosts (i.e. harm availability) and also compromise of the third party system which can impact your own security.


content disposition headers vs cloud and inspection

This is honestly bizarre and a number of searches find me no references aside from this article to say that content disposition headers are in any way involved with performance.

The content disposition header effectively tells the user agent (browser) how to handle or display the file if it is requested directly. The primary usage of it in HTTP responses is to specify that a file is to be downloaded rather than displayed inline.

The valid syntax for the response headers are as follows:

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="some.file"

The first is the default, meaning the content is displayed in the user agent as normal.

The second indicates that the content must be processed as an attachment, which in the context of a browser means a file to be downloaded and not displayed inline. The default name of the file is the final part of the URI's path. For example, in the URL https://foo.bar/downloads/fuzz.xyz, the file name would default to fuzz.xyz.

The third option is the same as before, except the default filename is explicitly specified.

Additionally, the content disposition header can be used as part of a multipart HTTP request, most commonly in order to enable file uploads:

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

As far as I know, there are no performance reasons to use this, or use any non-standards compliant variant of it. I couldn't find any reference to anyone doing so either.

My guess is that some cloud platforms utilise the Content-Disposition header in some non-standard ways (e.g. using it to perform programmatic file uploads as part of a REST API) which is incompatible with DLP solutions that naively rely upon the file extension in the indicated filename, leading it to assume that the data being transferred was of filetype X, when it was of a different (or no) filetype, resulting in incorrect parsing of the data.

On a personal note, I wouldn't trust any information you find in marketing materials written by DLP vendors. I've tested a number of products and not a single one was able to correctly identify policy-violating data exfiltration even when being obscenely loud about it (e.g. putting fake customer data directly onto Pastebin). They make a lot of claims and very rarely come close to backing them up.


Does preview link in facebook post reveal user?

does it mean all previews are sent from FB server? Or the link is embedded from the source?

When you share a page on social media, the platform (in this case Facebook) pulls in certain information from the embedded webpage, including the title, author information, page summary, and often an image. More information can be specified in the html header in meta tags. See this link for more information on meta tags: https://moz.com/blog/meta-data-templates-123

  If the preview is from the link source, then will it reveal user that viewing a page on FB to the source link?

If you log in to a website using your facebook credentials, then that website is pulling information from your Facebook profile to store in their database about you, so you would be identifiable. Otherwise when you post a link, if a website user has a Facebook developer account, they can collect metrics about your usage, which can be viewed in aggregate via the Facebook Insight API. Insights works in a similar fashion to Google Analytics, in that it will show a site owner that you viewed the site and some information about you, but not your name. However, given enough information, you can still be identified by metadata. See this blog for more information about Facebook Insights https://blog.kissmetrics.com/guide-to-facebook-insights/ and also look up Facebook's privacy policy for more information on how they use your information.


How can I know that the printer linked to email

can somebody hacking the printers or scanners in my network so that he can take all scanned papers to his email?

The modern multi-functional devices which can print, scan and email documents are often not designed with security in mind. This means they can be easily hacked which was shown several times. This includes unauthorized access to the configuration or unauthorized replacement of the firmware just be sending a special print job.

  I make sure that the printer does not send copies of the scanned paper to another email?

A firewall around the networked printer might ensure that the typical protocols for sending email are not reachable by the printer or that only a specific mail server is reachable which accepts only selected target mail addresses. This makes information leakage not impossible but harder.


Does PHP unserialize work with an object inside a string

The usual way to exploit unserialize is to invoke code execution (un-serializing an object triggers the __wakeup method defined in the class using the data supplied). Arrays don't have methods so they cannot be used to exploit this. Note that the class is something already defined serverside.

This does not address a more generic vulnerability in PHP's unserialize function, but the nature of the serialization format and the way PHP manages data in variables makes such a vulnerability unlikely and I am not aware of one.


Preventing installation of VPN software on home computers?

I assume you want to prevent your employees from using their personal computers to access your work network via VPN.

You can't prevent them from installing VPN software on their home computers, but you can disallow VPN connections from systems using Posture Checking.

Posture Checking involves the VPN server querying the VPN client for information prior to allowing authentication to be attempted.  If the endpoint (client computer) doesn't meet the criteria for an allowed connection, then authentication and VPN connection are not allowed.

Posture Checking is one name, you may also see Posture Assessment, Endpoint Compliance, Endpoint Policy, etc. etc.

This can include (Cisco example):

  In the adaptive security appliance (ASA), you can create a prelogin
  policy that evaluates endpoint attributes such as operating system, IP
  address, registry entries, local certificates, and filenames. Based on
  the result of the prelogin policy’s evaluation, you can control which
  hosts are allowed to create a remote access connection to the security
  appliance.

and (Check Point example):

  The Endpoint Policy Management Software Blade allows you to enforce
  endpoint compliance on multiple checks before users log into the
  network.

  You can check that the:

  appropriate endpoint security software blades are installed
  correct OS service pack are installed on the endpoint
  only approved applications are able to run on the endpoint
  appropriate anti-malware product and version is running on the endpoint.

  Plus, set users to Observe, Warn,
  or Restrict access to the network if they are not compliant with the
  policy. Also, allows for automatic or user-based remediation.

Most commercial VPN systems will provide an equivalent functionality, sometimes bundled, sometimes for an additional cost.


Exploit Development - Find system address in a given libc

try leaking 2 libc addresses and matching their difference with a libc database on the internet. This will give you the libc version used. After that you can find the offset of system in this libc with pwntools by:
libc=ELF("/path/to/libc")
libc_system=libc.symbols["system"]


What is the difference between secure element and smart card?

According to globalplatform.org, there are three SE technologies:

Universal Integrated Circuit Card (UICC)
embedded SE
microSD.

From the same website, a secure element is a physical object, not data.

  A secure element (SE) is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.


Does escaping quotes protect me from SQL injection?

Your query is first-order-injection maybe-just-maybe-safe, depending on how CodeIgniter improved from the last time I used it.

Let's be clear on this: no amount of sanitization will prevent you from SQL injection. The true "best fix" for PHP is parametrization, which allows you to take the variables out of the query. Failing that, however, proper sanitization can help. Last time I checked (three years ago), CodeIgniter used mysql_real_escape_string which, while a valid deterrent for most script kiddies, will not stop a seasoned hacker.

The best thing to do is to read up on how CodeIgniter actually does the sanitization/parametrization. If it is just addslashes, avoid it like the plague. There are plenty of other ways to perform SQL injections, by the way - for instance, you can juke character encoding to pass quotes through on most addslashes/mysql_escape_string setups. There are plenty of tutorials on the matter.


Is all traffic through a router configured to use openvpn protocol sent through a single port?

Yes, it's exactly as you are thinking.

A VPN connection works just like a proxy: every single connection is encapsulated in another one, connecting your router to the VPN server.

For an external observer, you will have only one very long-lived outgoing connection.


Best way to encrypt user data stored in xml?

Some articles say compression need to be done prior to encryption.

Compression should be done before encryption because encrypted data will not be compressible. So, if you encrypt first then there is no point in trying to compress the encrypted data further.

This happens because the encryption algorithm causes the encrypted data to look like just random data, and random data can not be compressed, generally speaking.

You can certainly encrypt part of a file first if you like, that just will make the file a bit less compressible.


Secret Santa implementation that does not require a participant to trust the server

You always need a secure way to distribute public keys. I believe the paper assumes you are able to do this.

However having that mechanism does not mean you can trust any single entity. You might trust me to give you my public key but you do not trust me not to rig the secret santa. Hence why this is still useful - you trust each individual to pass you their public keys but this is the only trust you have to have.


Do we have to be concerned about FaceApp?

As far as I know there is no actual proof that FaceApp is used for malicious purposes, the same that there is no public available proof that companies like Huawei (China) or Kaspersky (Russia) will knowingly harm the (American, European, ...) security. The main argument here is that there might be increased risk since the government in these countries might force the companies to do so. There is likely some truth in this, i.e. this risk is not zero.

On the other hand, there is proof that Facebook has misused user provided phone numbers. And there is proof that the NSA has made American vendors put backdoors in their products. And there are many more scandals were American (and other) companies either knowingly invaded the privacy of their users by misusing given data or that they accidentally did so by not properly protecting the data.

Which means in the end it is the question who you believe and trust more. If you are American then you might trust American companies more than Russian or Chinese companies, because you might see the role of the NSA to protect Americans while the role of Russia is to protect Russians. If you are West-European you might trust also the USA more than Russia but you might not trust it as much as Americans might do because of bad experiences in the past.


using Fiddler and visiting a site with HSTS enabled

honor HSTS in incognito if set previously in non-incognito
(ie, immediately tunnel to HTTPS, do not request HTTP url)

Chrome : YES
Firefox : YES
IE 11 : doesn't seem to honor HSTS

honor HSTS in incognito if previously visited site in incognito only
(ie, immediately tunnel to HTTPS, do not request HTTP url)

Chrome : NO
Firefox : NO
IE 11 : doesn't seem to honor HSTS

looks like IE is meant to support it in IE 12 - http://www.cso.com.au/article/542244/microsoft_confirms_http_strict_transport_security_ie_12/


Can the real IP address leak using curl via Tor?

--socks5 will use the SOCKS5 protocol for the HTTP connections but the name lookup will still be done using the normal DNS which means that your public IP address can be seen by the external name server you use. To do name lookup through the proxy too you need to use --socks5-hostname option.

From the documentation of curl

  --socks5
     Use the specified SOCKS5 proxy - but resolve the host name locally.

  --socks5-hostname
                Use the specified SOCKS5 proxy (and let the proxy resolve the host name)


Symmetric vs asymmetric encryption for backup files uploaded to cloud storage

Generate a reasonable long (around 200 bytes) symmetric key, use it to encrypt your backups, and encrypt the symmetric key with a long, secure and protected asymmetric key.

Symmetric key is faster to encrypt, that's why SSL use symmetric keys for encrypting the traffic. It uses asymmetric keys to exchange the symmetric session key. You should to the same.

Using the same key for every backup creates a situation that leaking the key once means every backup can be compromised. Having a different asymmetrical key for each backup means keeping track of every key, for as long as the backup is kept.

And you use the public asymmetric key to encrypt the symmetric one, so the private key is kept protected.

My answer to another question have some more insights.


Shared hosting mail server, Thunderbird and encryption

Assuming the server supports SSL/TLS (i.e. it has a valid certificate), it is possible to protect the email communications between the server and the user with SSL/TLS. This is especially important for the password - without this the password will be sent in the clear. But that won't protect the email communication between your server and other servers (assuming you send emails to other people that don't use the same server you use) or between the other servers and their users. For more details see Can I expect my e-mail to be routed securely?.

For this you need some form of email encryption. For email encryption to work both the sender and the receivers of the email must use compatible email encryption software and must share public keys. I believe Enigmail is OpenPGP compatible and should be compatible with any other OpenPGP compatible software.

As you note another concern is the security of the emails at rest - i.e. on the server. This is a greater risk in that an attacker who breaches the server will have access to all emails that are on the server including historical emails. An attacker who can read the communications between a user and the server can only read current emails. For the same reason it is most critical to protect the password than to protect the emails in transit - an attacker with the password can read all of your emails, including your future emails. Details on how to protect an Apache server can be found here.

For a great analysis and recommendations on how to secure emails, please see the NIST Guidelines on Electronic Mail
Security.


Actually, I found the problem. This is about the fact that the address of this gadget contains 0a which corresponds to a \n


Browser setups to stay safe from malware and unwanted stuff

First of all, good job on choosing Firefox and the right plugins, it's really the browser to go privacywise.
To extend upon the points that nobody mentioned yet, an important part of you hardening your browser would be the configuration of your Firefox browser! You can do that by typing about:config into the address bar and accepting the risks. Then you search for the specific string I specify in this answer. I will draw a line where the security completely destroys functionality (judging from my experience, since I myself use this setup).
First off, you're better off disabling WebGL: Motivation
webgl.disabled = true
Disabling WebRTC will prevent from getting your IP leaked behind VPNs (yes, NoScript SHOULD protect you but you can never be too safe):
    media.peerconnection.turn.disable = true
    media.peerconnection.use_document_iceservers = false
    media.peerconnection.video.enabled = false
    media.peerconnection.identity.timeout = 1

You're better off disabling third-party cookies:
network.cookie.cookieBehavior = 1 (Only accept from the originating site (block third-party cookies))
Never store extra information about a session: contents of forms, scrollbar positions, cookies, and POST data:
browser.sessionstore.privacy_level = 2
Activate integrated privacy measures:
privacy.firstparty.isolate = true
privacy.resistFingerprinting = true
privacy.trackingprotection.fingerprinting.enabled = true
privacy.trackingprotection.cryptomining.enabled = true (disables cryptomining on piratebay)
browser.send_pings = false
browser.sessionstore.max_tabs_undo = 0 (Firefox doesn't remember your recent closed tabs anymore)
browser.urlbar.speculativeConnect.enabled = false (disable preloading of autocomplete URLs)
media.navigator.enabled = false

This enables the integrated privacy guard (uses mostly Disconnect.me filters, also breaks Captchas, but you can disable it for certain sites, since it will be like 1% of your total surfing):
privacy.trackingprotection.enabled = true
Disable the DOM Clipboard Event:
dom.event.clipboardevents.enabled = false
Protect yourself against punycode phishing attacks:
network.IDN_show_punycode = true
Disable WebAssembly:
javascript.options.wasm = false
In the normal browser settings you can also disable Pocket, erase history, cache, cookies upon exiting Firefox. That should be more than enough.

DANGER ZONE

disables playback of DRM-controlled HTML5 content, which, if enabled, automatically downloads the Widevine Content Decryption Module provided by Google Inc. This will break Netflix et al.!

media.eme.enabled = false
media.gmp-widevinecdm.enabled = false

Send Referer only when the full hostnames match:

network.http.referer.XOriginPolicy = 2

Only send scheme, host, and port in Referer:

network.http.referer.XOriginTrimmingPolicy = 2
If you're near-paranoid you can even disable Referer:
network.http.sendRefererHeader = 0
If you need even more privacy check this out.
You can also blacklist hosts if you haven't already so other apps don't have such a huge attack surface.
There is also a plugin called LibreJS which blocks proprietary, non-trivial and obfuscated JavaScript code.
Also setting the locale to en-US in your browser is a good approach to privacy.


PCI compliance and external resources http/https

(IANAQSA)

The PCI DSS only requires encryption to protect cardholder data:

  Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC,
  SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Incidental page content which does not involve cardholder data does not require that level of protection.  Of course, if your cart checkout (which must be secured as that's where card data gets entered) includes an unsecured http:// image, most browsers will complain, so you'll generally want to secure even the images and other content there.

If you're using a third party js library as a payment application, then PCI compliance is an issue - probably just making sure that it's PA-DSS compliant.  However, if you're using a third party js to make your page look pretty, and it's not handling card data or impacting card data communication streams in any way, it won't impact compliance.

Updated to respond to @cchamberlain comment:

I believe that third-party libraries like Angular would fall under DSS (version 3.1 quoted here) section 6.2:

  6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security
  patches. Install critical security patches within one month of
  release.

Contrast this to "bespoke or custom software developed by a third party" in section 6.3:

  6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

  In accordance with PCI DSS (for example, secure authentication and
  logging)
  Based on industry standards and/or best practices.
  Incorporating information security throughout the software-development
  life cycle

  Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

So, if it's a software product for general distribution, it's assumed not to be malicious and you need to keep it up-to-date and react to security advisories.  But if someone develops custom code for you, you have to treat it with equivalent levels of scrutiny to your own code.

I think this boils down to "trust that the owners of the library do not have ill intent" for something like Angular.  You're still responsible if they do something inappropriate, of course.


Can 3rd party AVs have accessed to my Windows PC and Android phone even after uninstalling and removing them?

If you run software on your PC it can do anything with the permissions you grant it. If you install or uninstall an AV this is usually done with system permissions - and like any other software running with system permissions it can do a lot of harm and also embed itself deep into the system if it really wants to.

If you don't trust the AV vendor you should not trust its product, the software which installs the product and the software which uninstalls it either. It could in theory do anything with your system (including spying on you etc), which of course does not mean that it will actually do it in all cases. Given that you say that the AV is from a reputable vendor (even though you don't trust him) I don't believe that it will actually do the harm it could do in theory. But you have to decide for yourself if you still have this kind of trust or not.

To make sure that you got fully rid of the product you should reset the system into a known good state - which usually means to install a backup of the system or to reinstall the system. The same is true for PC and phone. Note that in theory such product could nest deeply into your system so that a simple restore from backup will not work. It could also infect your router and from this reinfect your system. But again, this is unlikely if this is really a well-known and usually trusted vendor.

As for the sudden slowness you see: there is no generic explanation and solution for the behavior you describe. While there might be an explanation and solution for your specific case there is not enough known about your case and apart from that this is not a PC support site. If you feel that the problem is caused by the AV product please contact the vendor or look for solutions in his support forums.


Is there a password manager that combines a "master password" solution with a keystore solution?

Original question

With only one master password, for both the final hash and the key store.

Your scheme adds no additional security on top of what standard password managers already offer.

So lets say that the password file from your password manager is leaked. Generally, these are encrypted using a key that is derived from the master password. So an attacker will need to crack the master password to get your site specific passwords.

If your master password and the key stretching algorithm are both good, that is a tall order. But for the sake of argument, lets say that the attacker succeeds. She then knows (a) the master password, and (b) all your site specific passwords. Nothing is stopping her from just calculating the hash you proposed.

An attack on your scheme would work exactly like an attack on say LastPass, with the addition of the calculation one simple hash at the end.

Updated question

With different master passwords for the final hash and the keystore.

You are using two passwords here. The relevant benchmark to compare against is using a normal password manager with one password that is as long as the two passwords combined.

You can argue if this is a security benefit or not. To gain access to all your passwords, an attacker needs to brute force first the keystore password and then the password for the final hash. To do the latter, the attacker would need one correct password that is in the keystore to compare the results against.

If the attacker have no such password, then your system is better.

If the attacker have such a password, a normal password manager is better. Brute forcing two passwords of length n/2 is sooooo much easier than brute forcing one password of length n.

So my recommendation would still be to use a normal password manager with a strong password. If you use a strong password, an attacker will be chanseless anyway.


Prevalence of offshoring in the Information Security Industry?

I am interning at a security company in Switzerland as a penetration tester. Funny thing, I had this exact discussion with my boss (who is in the field for 20 years now). Basically, you can't compete with the coding monkeys in Russia and India, they pump out code as much as you breath. That being said, it is believed that outsourcing security related jobs will not take place any time soon. For the sole reason that jobs in security are based on trust. And trust, you can't outsource.


SSL is a very cool protocol.  Refined,  very secure and its no accident that its so widely used.

I liked reading The First Few Milliseconds of an HTTPS connection,  and I recommend it to others.   The best part is that you can follow along with wireshark and a browser.

On a side note I can't believe OpenSSL library is now 1.0.0!  I thought that would never happen.  The latest version introduced negotiation for SPDY (Which is exciting even if its only currently used by chrome when connecting to gmail XD).  Check out chrome://net-internals/#spdy in chrome.


Well, "block all incoming connections" should block all incoming connections so you should not be able to find any open port. Note that even port 80 ought not be open either: a typical desktop system has no business running a Web server itself.

The fact that there are open ports is indicative that the "block all incoming connections" setting does not work as expected. Port 3128 is a traditional port of an HTTP proxy.

What you report does not add up. Either the Mac runs some servers, does not block incoming connections, and could be under active external hostile control. Or maybe you made a typing error and you are not scanning the machine you believe you are scanning.