Do websockets represent a security problem to my local machine?

In a word, YES, websockets DO represent a security problem to your local machine.

First off, some clarification there is a difference between binding to 127.0.0.1 and 0.0.0.0 ... as one will only allow your computer to connect and the other will allow any computers on your network to connect.  BOTH of these are dangerous, however, binding to 127.0.0.1 is slightly more secure.

Most (all?) current web browsers have limitations on what is known as cross site scripting.  This means if a page hosted by foo.com attempts to make an ajax request to bar.com it will fail unless it is explicitly allowed via CORS.  This said ... websockets are NOT limited by CORS and thus foo.com could theoretically open a websocket connection to 127.0.0.1 ... and take control of your docker service.

I will note that this is not a common attack vector as it requires the target to actively be using a web browser on a device running docker with this option enabled (rare) ... but its still an attack surface.

Further Reading:

How Cross-Site WebSocket Hijacking could lead to full Session
Compromise
OWASP Top 10 Details About WebSocket Vulnerabilities and Mitigations


Is it safe to publish the hash of my passwords?

MD5 and SHA256 were both designed to be as fast as possible. Their purpose was to compute a hash for relatively big data volumes, e.g. for files. That's why they are very fast, which makes brute-forcing easier.
A single GPU can generate ~10^10 SHA256 hashes per second. It is ~10^15 per day. Computing of MD5 is much faster, on some GPUs ~5 times faster. So let's ignore MD5 part of your algorithm and consider SHA256 only.
Suppose you have a password that consists of 10 alphanumeric characters, i.e. from a 62-character set. The number of different passwords is 62^10 ~= 10^18. It means, to brute-force such password an attacker would need 10^18 / 10^15 = 1000 days with single GPU, or 100 days with 10 GPUs, or 10 days with 100 GPUs. Thus, an attacker that can afford 10 GPUs, will break such password in 100 days.
If you use 16-character passwords, i.e. 6 character longer, then required computing power need to be 62^6 = 5*10^10 higher.
Thus, the security depends essentially on how long your passwords are.
Another important factor is the costs of brute-forcing and possible benefits for an attacker. For instance, if brute-forcing your passwords will cost an attacker 900 000 USD, and knowing your password gives the attacker benefit of 1 000 000 USD, then in total this will give 100 000 USD benefit, and brute-forcing makes sense. But if password gives only access to a bank account with let say 10 000 USD, then an attacker will lose 890 000 USD. In such case brute-forcing makes no sense for the attacker. Only you can decide if somebody will be interested in paying much money for computing power needed to brute-force your passwords.
And it makes sense to use hashing algorithms that are designed to be slow, e.g. Argon2 or Lyra2. They have tunable parameters. Use values such that a single hash takes 0.1 - 1s. Thus you can essentially slow brute-forcing down and reduce the risks even more.


Generating SSH keys and sending the private key

I wouldn't. Private keys are meant to be private, the intention is that you protect the private key intensely and provide the public key to whichever other party needs it (which can be used to decrypt the information encrypted with your private key). This is the beauty of PKI.

If you're concerned about generating a keypair on Windows, use PuTTY. It's got a fantastic tool for this and works great, and pretty easily too.


What is an XML round trip vulnerability?

Sigh. I figured it out by reading the HackerOne post that was right there in the Ruby link in my original post.
It's exactly what I thought - you can cleverly form XML that will be parsed and come out differently than expected, sometimes in dangerous ways.
I highly recommend reading the HackerOne post for a very clear explanation, but anyone else who cares to simplify feel welcome to post an additional answer here and I'll accept it.


It can't be done with that tools. I have the same "problem" as you using exactly the same tools.

Anyway, from a security point of view is not a problem. In my opinion to scan only certain part of code could lead you to not detect certain errors. I'll try to explain it later. Another story is to show incrementally new issues detected on SonarQube. That can be done and I think is what you really need.

Suppose you already have incremental vulnerability scanning running. Maybe you have a vulnerability in a class that is not detected because the class is not used yet. Then another commit use that class and the security vulnerability could take place but if you scan incrementally only commit by commit you'll never discover that vulnerability because your scanner is going to scan only that part of code without getting into "already scanned old code".

I think is better to scan always all code but only showing new issues detected on SonarQube.


Can the numbers on RSA SecurID tokens be predicted?

What SecurID tokens do is not completely public knowledge; RSA (the company) is quite wont on releasing details. What can be inferred is the following:

Each device embeds a seed. Each seed is specific to a device.
The seed of a device can be deterministically computed from a master seed and the device serial number. The serial number is printed on the device. This computation uses cryptographic one-way functions so you cannot guess the master seed from a device seed.
From the device seed and an internal clock, the number is computed, yet again with a cryptographic one-way function.
The derivation algorithms have been leaked, if only because the verification servers must also run the same algorithm, so these algorithms exist as concrete software in various places; leaking and reverse-engineering are mostly unavoidable in these conditions.

Under these assumptions, then:

If you know the device seed, then you can compute future numbers at will.
If you know the master seed and the device serial number, you can compute the device seed.
Knowing seeds from other devices should gain you nothing into guessing the seed for a given device, unless the cryptographic one-way function which turns the master seed into device seeds has been botched up somehow.
Knowing past numbers from a token should gain you nothing into guessing the future numbers from the same device, unless the cryptographic one-way function which turns the device seed into numbers has been botched up somehow.
Extracting the device seed from the physical device itself is theoretically feasible but expensive, because the device is tamper-resistant: it is armored and full of sensors, and will commit electronic suicide if it detects any breach. If we take the example of smartcards, extraction of the device seed is likely to cost several thousands of dollars, and be destructive to the device (so you cannot do it discreetly).

On March 2011, some systems have been compromised in RSA, and it seems probable that the attackers manage to steal one or a few master seeds (it is plausible that the devices are built in "families" so there are several master seeds). RSA has stated that 40 millions SecurID tokens must be replaced. If you know the serial number of a token (it may be printed on the outside of the token), you can use the Cain & Abel tool that @dls points to; presumably, that tool implements the leaked algorithm and master seed(s), and can thus produce the future token outputs (I have not tried it). This would work only with servers which still accept the tokens from the 40-million batch which is to be replaced. I do not know how far RSA and its customers have gone in this process, so it may be that this attack will not work anymore. It really depends on the reactivity of the people who manage server you attack.

(If these system administrators have not replaced the compromised devices after nine months, then chances are that they are quite lax on security issues, and the server may have quite a few other remotely exploitable security holes.)


What good, standard digital signature / timestamp verification clients are widely or easily deployed?

Clients? That rather misses the point. It's really about file formats and protocols.

x509 is a cornerstone of encryption implementations. Although its just a starting point for implementing software on, it should probably be your starting point for looking for software.

About 10 years ago, I needed to implement a PKI for my then employers. The route I took was to set up a root Certification Authority using openSSL. At that time x509 verification was available for email required plugins for MSOutlook Express and Eudora (but not for the Bat!). IIRC, these are now built-in as standard. Wincrypt (file encryption) was available as a free download and Stunnel had just been ported to MSWindows.

Certainly 10 years is a long time in encryption circles - but the nice thing about x509 is it accomodates different algorithms / key sizes. It also builds on the same basis as LDAP.

More recently there are have been many more tools implemented using SSL type encryption - e.g. Gnu Anubis (OK, it doesn't actually add the sigs - but provides hooks for calling openssl), smart cards


How dangerous is it to use third-party security audit tools?

Security testing implies risks.

Most security tools have warnings and disclaimers because they pose risks to systems they target. A security specialist would understand how using a particular tool or intrusive test can negatively impact the target systems but undesirable outcomes and accidents can happen. For example, a classic ‘OR ‘1’=’1 SQL injection in a DELETE query could very easily delete all the contents of the table.

Another example is NMAP scanner containing auditing script that are marked safe or intrusive. Some scripts are intrusive because they use significant resources on the remote system, are likely to crash the system or service, or are likely to be perceived as an attack by the remote administrators.

Auditing is a rather passive activity focused on observing rather than interacting with the target. Backtrack and other toolboxes focus more on active interaction that is typical of penetration tests.


Small, Vulnerable apps for exploit training

Try going through the extensive list on OWASP Vulnerable Web Applications Directory Project.

Some of them I know and have played with:

Google Gruyere
Damn Vunerable App

But some of ASP.NET specific ones include SPI Dynamics (live), Watchfire (live), Acunetix 2 and 3 (live), HackmeBank, and OWASP SiteGenerator.
Hope this helps!


How can I use parabolic antenna to strengthen access point signal for evil-twin penetration testing?

Using high-power Ubiquiti wnics or cheaper ALFA variants is simplest. Both offer an effect of ~1W, although Ubiquiti is more trustworthy on specs. Using yagi antennas (google radiation patterns) is best, parabolics have a dot focus. A note on this: use a red laser pointer to aim the parabilic, keep the laser perpendicular to the centre of the dish. RXQ etc on your laptop displays with an annoying delay, so laser really is best if you don’t have a signal-meter (for 2.4/5.8GHz... it’s flooded anyway).

I use a yagi that is quite small, about 15cm long. You can use one with more directors but the focus becomes smaller... 2-3 are adequate. A parabolic dish’s dot focus may be visible to your target router but not target client. They are best for PtP links, not eviltwin against several targets. Note that patch antennas are very good, if placed in an elevated position and pointing down ~25°, so depending on your locale these may be an option... They can be had cheaply, and I recommend you buy one produced by Ubiquiti if possible.

Ubiquiti has MMCX ports, whereas ALFA has RP-SMA. You can use short pigtails to connect MMCX/RP-SMA to the typical N-connector on most quality antennas. The ALFA USB wnics I have used run stupidly hot, I have lost one to just heat. The ones with Ralink chipset seemed to perform best, but Realtek is OK. Add some cheap heatsinks or they won’t perform decently after a few hours.

DD-WRT is highly flexible, with the right router can also output ~1W, and is easily configured as a repeater... Have a look at a few high power Ubiquiti APs on eBay. The default WebGUI on Ubiquiti is complemented with a linux environment accessible via SSH/serial, though DD-WRT (using OpenWRT package repos) has more software available.

Get an FTDI/USB-TTL for 3.3V if you accidentally fail firmware changes, it will help tremendously to have a console when you restore it.


Can You Brute Force Dropbox Folder URLs?

Can you brute force Dropbox URL? Well, yes, you can also brute force AES256 encrypted file. I think what you are really asking is, would you be successful?

It's quite unlikely. Currently, Dropbox share URL is 11 characters that consists of lowercase alphabets and numbers (36 possible characters). This gives a key space of 36**11 ≈ 1.31621704 × 10^17 possible keys or ln(36**11) / ln(2) ≈ 56.869175 bits.

Now this boils down to a math problem: suppose that there are m occupied keys in a key space of 36**11, if an attacker sends n guesses, what is the probability that at least one of the guesses matches an occupied key.

How many files are in Dropbox that have share URL? I don't think Dropbox published this data, so I'm going to make a guess. Let's say there's 1 billion files with share URL.

If the attacker makes a single guess, he has a 1000000000/36**11 = 7.59753119 × 10**-9 = chance of guessing one key in one guess.

Suppose that the entire Dropbox security response team is on holiday and the attacker managed to make 1 million guesses before Dropbox noticed something's up and shut the attacker down. Then the chance that at least one of the million guesses matches an existing document is 1-(1-1000000000/36**11)**1000000 = 0.00756874289.

Which is about 0.75% chance that the attacker will be able to retrieve a single random file after one million guesses.

In practice though, Dropbox probably have measures to detect and block automated random key requests.


How can I monitor traffic of devices on my WiFi?

One thing to realise is that you can't completely block what you kids do on the Internet and probably the best thing to do is to try and educate them on avoiding sites you think they shouldn't visit and also how to recognise dangerous situations (e.g. strangers looking to message them or meet up in real life).

That said there are products which can help to manage and provide basic restrictions on Internet access.  They're not perfect but they can inhibit mild curiousity, and could help kids avoid "bait and switch" where a friend sends them a link which appears to go to a safe site but instead does not.

One thing you could look at is Family Shield from OpenDNS, which helps to filter access to adult sites, but there will be other similar products.


Safest place for small business to store passwords

If you have a small number of people and want to save some money, I would say a number of KeePass databases shared somehow (network share, google drive, etc), and backed up in several ways. The only 'hurdle' is that when someone leaves the company you would need to cycle all the passwords of the DBs the person had access to, as they could walk away with a copy of the DB.

Also free, you also have PassBolt, which you can install on premise and is open source. The extra trouble with this, is that the server where you are running PassBolt has to be hardened to the core. If you can afford it, I would recommend getting the paid version as it offers 2FA (cycling password still applies).

Also on the entry level (money wise) the more advanced offerings of companies like LastPass or 1Pass that allow sharing credentials between teams. Personally, I don't really trust them, and the thing about cycling password still applies again.

If you have a big pile of money, there are are some onpremise platforms such as CyberArk Enterprise Password Vault that also report who and when someone requested a password. I haven't seen any of these platforms being opensource, and you can see which passwords in particular need to be cycled rather than everything.


Decrypting .P7M File with Key (.pem) using OpenSSL

Your decryption command is correct.

It seems there's something wrong with your key file. Does it really start with -----BEGIN RSA PRIVATE KEY----- and end with -----END RSA PRIVATE KEY----- (mind the exact number of dashes)? Or is it perhaps DER encoded which requires you to add -keyform DER your decryption command line?

BTW: You can check the integrity of the key itself with openssl rsa -in Key.pem


Is it reasonable to use KeePassXC with YubiKey?

Well designed password managers do not rely on authentication for their security; instead they rely on encryption. So unlocking a password manager data base doesn't even involve single factor authentication, much less multi-factor authentication.

How a password manager can use a Yubikey

What this means is that the kind of thing that is normally used to strengthen an authentication process (and YubiKeys are very good at that) play an inherently different role when it comes to something that's security is largely based on local or end-to-end encryption. There are roughly three approaches, but the details of each matter.

1. Security theater

In some cases, the apparent second factor is pure security theater. It is possible to do something that looks like 2FA to the user but is trivially evadable by any attacker worth worrying about. We (at 1Password, where I work) have resisted intense customer pressure for that over years.

Let's just ignore this option. It does nobody any good and it has a substantial harm potential if users end up using weaker master passwords or not protecting their master password as well as they otherwise might. That is, if people weaken what is already the weak point in their password manager security, because they feel protected by theatrical 2FA, they very much weaken their effective security.

2. On some authentication component

Although many password managers can be used off-line, without requiring authentication to some remote service, there is typically a required authentication component when setting up a new device to get (at least) data synchronization to work. 2FA can be added to that authentication component, even though it is a minor part of the user's security.

This, by the way, is what we do with 1Password. If you enable 2FA, then it is required when setting up a new device. The hope is that by limiting it to this, we are not leading users to believe that they can get away with weaker master passwords or that the 2FA magically protects them from an attacker who gets at their locally encrypted data.

3. As a supplier of a static key

Decrypting data requires a key, and deriving that key requires user held secrets (typically their master password and perhaps other things). The difficulty here is the the key derivation function (KDF) must be deterministic (as it must derive the same key each time).

But the beauty of something like a Yubikey is that it can prove knowledge of a secret without revealing it. They are designed to work in a challenge-response manner, where each challenge is randomized, making the responses unique each time; yet each correct response proves knowledge of a secret. This is what makes these things really good in authentication contexts. But this is useless during key derivation.

So having the Yubikey spit out a static secret is operating the device in a mode that gives up on its most important security features. It's doable (as Keepass is apparently using it and some of our users have jerry rigged something similar), but it really isn't offering the security guarantees that a Yubikey normally does.

Although this isn't purely security theater (there is some real gain), there is still distinct possibility that users will over value the security gain and thus weaken the parts of their security (master password) that should be stronger.

Is it reasonable?

So back to the original question. It is reasonable to use a Yubikey as described in (3)? Using it is not unreasonable as long as you understand what it does and doesn't protect you against (and that these are distinct from what a Yubikey typically protects you against.)

We, at 1Password, however, believe that it is unwise for a password manager to encourage (3), as the security benefits don't seem to be worth the security threats that arise from people's misunderstanding of the security properties. However, I very much understand the customer pressure for this kind of thing. I also understand that reasonable people may come to different conclusions.


Is it safe to store the token expiration time in local storage?

First of all, storing the JWT client-side is not only acceptable, it is mandatory; your client can't make authenticated requests if it doesn't have its session token. You can store it different places, each with their own security tradeoffs (a cookie is traditional, and can be hidden from script with the httponly flag, but also needs to use the secure flag and puts you at risk of CSRF and similar if you don't use the samesite flag or your browser doesn't support it yet; persistent or session local storage won't be sent automatically the way cookies are and can protect against CSRF, but an XSS payload could steal them). It can be stored ephemerally (session storage or session cookies, although realistically, people often don't actually close their browsers these days) or persistently (its lifetime should be short enough, and included in the signed data of the token and therefore immutable, that this is probably safe but pointless). It's gotta be stored, though.

With that said, even if the token is stored in an httponly cookie (where script can't see it), there's no harm in storing the token's expiration time in local storage. I'm not sure what you plan to do with this data (warn the user when their session is running out? Submit a refresh token request?) but there's no security impact to doing so.

EDIT: A bit more background

JWTs include their expiration time / validity lifetime within themselves, in a portion that is cryptographically signed. Only the server can generate a valid signature, and if any of the signed data (including the expiry) is tampered with, the signature becomes invalid. A JWT with an invalid signature cannot be used (the server will reject it). The server will also reject a JWT that has expired, of course, so the server neither cares what the client thinks the expiration is, nor should ever ask anything except the JWT itself (including its timestamp and signature) whether it is currently valid.


Banking app logon - multiple fingerprints on a device vs 2 passwords known by 1 person

The problem with multiple fingerprints: The bank application can't store the actual fingerprint nor a mathematical representation of it (like a number or a hash). The only thing that the application receives is something like "true" or "false", meaning "true" if the Touch ID was successful and "false" if it wasn't successful. And for security reasons that is really all Apple provides when using Touch ID. An application can't ask for a specific fingerprint on the device.

The implication of this is that other persons who are authenticated with Touch ID on your iPhone could also use the bank application since the iPhone would provide a successful Touch ID authentication to the application.

So if I were you I wouldn't change to Touch ID for the bank application.


Looks like you're passing whatever is supposed to be in the preceded set of data to MySQL without proper encoding or the use of prepared statements. As a result, MySQL is interpreting the boundary as SQL code, and throwing an error that it's not valid SQL.

At the very least, you need to encode any data which is included in SQL queries. Better yet, force the data to a specific type - if you're expecting an integer, ensure that only integers are allowed through, rejecting anything that isn't an integer before it hits the database. Even better, do that, and use prepared statements.

Prepared statements enforce the separation between executable SQL and data you're using within the SQL, so even if unexpected data makes it through, the database won't treat it as part of the SQL statement, but instead attempt to use it as data. They are available for most commonly used web languages with most common databases. They aren't perfect (see Are prepared statements 100% safe against SQL injection?) but they are a lot better than including raw data.


Origins of the "man-in-the-middle" analysis

After a couple minutes in Google, I find that Leslie Lamport appears to be the first to talk about MitM analysis in terms of communication security.

The work was published in 1981, but there is evidence of his thoughts on the matter as early as 1979.

First published work describing the ideas: here.


The reason for this is mostly that "the web" is not a singular thing, with a singular designer.

It's a complex structure, who's purpose shifted over decades. We want more from the web today than we wanted back in the 80's, just like we want more from our phones today than we did back in the 80's.

Furthermore, the architectural idea that a server instructs a client to do something, and that client may or may not understand what the server wants, is another reason why the web is so complicated. It's the reason why Internet Explorer is so crappy, and why all web developers rejoiced when Microsoft announced they would finally retire it.

As far as historical data goes, hindsight is always clearer. There are many technologies that we thought were pretty neat (ActiveX, Flash, Java Applets, etc.), but turned out to be horrible in hindsight. Of course, you may look at those things from today's point of view and notice all the problems, but these were designed in a different era, where people had different expectations.

To summarize

The Web is complex because

It grew over decades and is one of the most legacy-loaded things there is.
It was never designed at one point by one individual or company.
It had to support many different clients, some of which may be grossly outdated.
It's not possible to "start over". We can only work with what we have.
Different companies tried different things, often duplicating work instead of working on open standards.


S3's access control is not really suitable for functionality.   If every instance of the app uses the same credentials to access S3 then the JSON records could be compromised by an attacker who has decompiled the app.

if you want to make a change to a user record stored in S3,  the change will not propagate immediately.  So if you if your application has a user_state=disabled,  then this change may not be reflected immediately in s3.

Consider using memcachd to cache the json records.  Access the records using a temporary,  random token.


What does WPA2 traffic look like to a packet sniffer that is not connected to the network?

It doesn't ultimately matter whether the attacker is connected to the WPA2-PSK network or not: if an attacker can capture the 4-way handshake and knows the pre-shared key, it's possible to decrypt all traffic.

Theory

That said, if you just look at individual 802.11 datagrams without analysing their flow any further, they are link layer (L2) datagrams containing link layer information: four MAC addresses.

Those addresses represents the transmitter (TA), receiver (RA), source (SA) and destination (DA) addresses, but their meaning and placement in the header depends on the values of the To DS and the From DS bits in the header, as described in the document IEEE 802.11-05/0710r0:

  Note that Address 1 always holds the receiver address of the intended
  receiver (or, in the case of multicast frames, receivers), and that
  Address 2 always holds the address of the station that is transmitting
  the frame.

WPA2 a.k.a. IEEE 802.11i-2004 doesn't encrypt these L2 headers, but all the information in the frame body, i.e. everything from network layer (L3) up to application layer (L7).

To address your concerns:

IP addresses are network layer (L3) information → encrypted.
TCP/UDP ports are transport layer (L4) information → encrypted.

On the other hand, there's still some information disclosed:

MAC addresses may reveal the manufacturer of the devices, which could be used for finding possibly vulnerable access points or e.g. IoT devices.
IPv4 & IPv6 multicast can be detected: although the IP headers including the multicast addresses are encrypted, the destination MAC addresses are standard and known (01-00-5E-, 33-33-).
The BSSID associates the datagram to a certain pair of AP & SSID, as an AP as a transmitter and as a receiver is distinguished solely based on the BSSID, and the SSID is typically broadcasted in the IEEE 802.11 Beacon frame. Therefore, the amount of data every device is transmitting can be associated to the network they are using, as well as the timing. E.g. if someone had an IoT washing machine we could identify, we could guess their laundry day.
Although the SSID might not be broadcasted with the beacon frames, devices connecting to the network will reveal the SSID in probe request frames. Also, computers trying to connect to saved networks will leak this information periodically even when they are not near any access points of this network. E.g. from my home I can guess several companies my neighbours are working for.

To be more exact, the data is encrypted and authenticated, but the 802.11 headers are only authenticated in both CCMP (AES) and TKIP. That is summarized in these two diagrams from 802.11i Overview, IEEE 802.11-04/0123r1:

  CCMP MPDU Format

  TKIP Design (1) – MPDU Format s

Practice

If you concretely want to see yourself how it looks like in detail, you could e.g.

Monitor a wireless adapter using airmon-ng. No need to connect to the network.
Capture some packets using airodump-ng.
Investigate the capture file (.cap) using Wireshark.

First without decrypting anything. (That's what you were asking.)

Configure Wireshark for decrypting the WPA2 and inspect the capture again.

Go to Preferences > Protocols > IEEE 802.11,
[x] Enable decryption
and add the PSK key for decryption.
Open the (.cap) again and let Wireshark decrypt it.


SSO SP Initiated Single Sign Out - User Experience

I'm a fan of giving the user the choice in simple words. For example when they click logout, if they are in an SSO session, you can give them a popup with two options:

Sign out of this app only (you can invalidate session tokens and at least make them go back to the IdP, but really this option doesn't do much).

Sign out of all connected apps (this calls the IdP logout URL).


Apple vs DOJ - how strong is the 10-try wipe brute force barrier?

Edit 2: See this question for discussions based on more accurate and up-to-date info.

Edit: See also this question which has loads of discussion on this already with quotes from the actual request.

I think the problem might be more complicated than what can be solved by a simple clone. Recent iDevices comes with a security enclave which is an isolated security processor.

Typically, such processor have its own on-board non-volatile memory which is used to store key material. All encryption/security related operations only happen inside this processor and the encryption key never leaves the chip.

The main disk/flash memory can now be completely encrypted and the "wipe" only need to happen in the enclave as opposed to having to overwrite the entire flash chip.

In this kind of scheme, simply copying the flash is obviously completely useless so an attacker/FBI/DOJ must find a way to compromise the security enclave as well.

That is why Apple's cooperation is needed. The security enclave processor does have to run firmware, which are often field-updatable. Security is typically ensured by checking vendor's signature of the firmware. The court order is probably trying to force Apple to sign an insecure version of the firmware that would allow brute-forcing.

The side-effects of this is also obvious. Anyone who gets hold of the firmware can completely bypass the most secure part of the system and steal very sensible data like TouchID fingerprints and Apple Pay card details also stored in the security enclave.


Proxying Requests through Python and Burpsuite not working

I found the answer.  Urllib does not support https proxy.  I found this site which has a recipe for connecting properly.

Here is the code in case the link goes dead:

# urllib2 opener to connection through a proxy using the CONNECT method, (useful for SSL)
# tested with python 2.4

import urllib2
import urllib
import httplib
import socket

class ProxyHTTPConnection(httplib.HTTPConnection):

    _ports = {'http' : 80, 'https' : 443}

    def request(self, method, url, body=None, headers={}):
        #request is called before connect, so can interpret url and get
        #real host/port to be used to make CONNECT request to proxy
        proto, rest = urllib.splittype(url)
        if proto is None:
            raise ValueError, "unknown URL type: %s" % url
        #get host
        host, rest = urllib.splithost(rest)
        #try to get port
        host, port = urllib.splitport(host)
        #if port is not defined try to get from proto
        if port is None:
            try:
                port = self._ports[proto]
            except KeyError:
                raise ValueError, "unknown protocol for: %s" % url
        self._real_host = host
        self._real_port = port
        httplib.HTTPConnection.request(self, method, url, body, headers)

    def connect(self):
        httplib.HTTPConnection.connect(self)
        #send proxy CONNECT request
        self.send("CONNECT %s:%d HTTP/1.0\r\n\r\n" % (self._real_host, self._real_port))
        #expect a HTTP/1.0 200 Connection established
        response = self.response_class(self.sock, strict=self.strict, method=self._method)
        (version, code, message) = response._read_status()
        #probably here we can handle auth requests...
        if code != 200:
            #proxy returned and error, abort connection, and raise exception
            self.close()
            raise socket.error, "Proxy connection failed: %d %s" % (code, message.strip())
        #eat up header block from proxy....
        while True:
            #should not use directly fp probablu
            line = response.fp.readline()
            if line == '\r\n': break

class ProxyHTTPSConnection(ProxyHTTPConnection):

    default_port = 443

    def __init__(self, host, port = None, key_file = None, cert_file = None, strict = None):
        ProxyHTTPConnection.__init__(self, host, port)
        self.key_file = key_file
        self.cert_file = cert_file

    def connect(self):
        ProxyHTTPConnection.connect(self)
        #make the sock ssl-aware
        ssl = socket.ssl(self.sock, self.key_file, self.cert_file)
        self.sock = httplib.FakeSocket(self.sock, ssl)

class ConnectHTTPHandler(urllib2.HTTPHandler):

    def do_open(self, http_class, req):
        return urllib2.HTTPHandler.do_open(self, ProxyHTTPConnection, req)

class ConnectHTTPSHandler(urllib2.HTTPSHandler):

    def do_open(self, http_class, req):
        return urllib2.HTTPSHandler.do_open(self, ProxyHTTPSConnection, req)

if __name__ == '__main__':

    import sys

    opener = urllib2.build_opener(ConnectHTTPHandler, ConnectHTTPSHandler)
    urllib2.install_opener(opener)
    req = urllib2.Request(url='https://192.168.1.1')
    req.set_proxy('192.168.1.254:3128', 'https')
    f = urllib2.urlopen(req)
    print f.read()


Would using Websockets cause PCI compliance failure?

Not in and of itself; however, like any network connection, it is subject to PCI DSS rules such as the following:

  1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
  1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service.

So you'll need to document that any services you set up using WebSocket are necessary and secure; pretty much just the way you would as if it was vanilla TCP.

  1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.

Again... document that it's needed.

I haven't used WebSocket, but it appears to be just an abstraction layer on top of TCP, and so for PCI purposes does not introduce any inherent insecurities over the set pre-existing in TCP (...until proven otherwise, natch).  Obviously for PCI purposes you'll want to pay attention to encryption and make sure that's enabled most places.


Find salt from md5 hash if password is known

With known plaintext, and assuming salting that uses simple string concatenation, some password-cracking suites like hashcat or MDXfind will let you bruteforce the salt. This will only be practical for simple salts (short enough to bruteforce, or if the character set of the salt is known well enough to keep the keyspace small).

For hashcat, the (perhaps non-intuitive) trick is to pretend that the salt is the password, and the password is the salt. This works when the salting is performed as a simple concatenation.

In this example, the known plaintext password is "password" and the unknown salt is "GR7". We'll be using hashcat's algorithm mode 20 (md5($salt.$pass)).

Here's the salted hash:

$ echo -n 'passwordGR7' | md5sum
a598e9df477f07dadee6b6bee9ac1daa  -

... and here's the target hash and "salt" (in the expected hash:salt format), but the "salt" is actually our known plaintext password:

$ cat hash.list
a598e9df477f07dadee6b6bee9ac1daa:password

We then use a '?a?a?a' mask (all three-character printable strings) as potential "passwords" (really the salt):

$ hashcat --quiet -m 20 -a 3 hash.list ?a?a?a
a598e9df477f07dadee6b6bee9ac1daa:password:GR7

To handle salts of different lengths or formats, simply adjust the mask  or attack type. If the length of the salt isn't known, use --increment to try all lengths up to the length of the supplied mask.

If the salt is prepended instead of appended, hashcat mode 10 (md5($pass.salt)) can be used instead (again, remembering that the "pass" in this context is actually the salt, using the same method as above).

I haven't explicitly done this with John the Ripper, but since John supports md5($p.$s) and md5($s.$p) using dynamic formats, I believe that the same technique can be used with John. But these dynamic formats are only on CPU at this writing, so if you have GPUs available, I'd recommend taking a look at hashcat instead.


Can unencrypted keys & logins be kept out of program memory?

As DeerHunter points out, pieces of information that should never be accessed by anything other than a hard-wired set of instructions can be stored in a Hardware Security Module.

HSMs hold the key and can perform tasks that use the key, for example generating signatures, without the key ever being known outside the HSM. An HSM is not a box you keep an encryption key in, to be loaded out when it is used - the key stays in the box, the HSM is designed to never egress the key.

However, if your threat model includes attackers that have physical access to RAM, you have no hope. Thats like asking if it is possible to keep thieves out of your house while allowing them into all the rooms.

If all you are aiming to achieve is never having the encryption key present in RAM in its entirety, you could envision an encryption scheme that did not use the entire key at once, perhaps feeding in the key one byte at a time into an iterative algorithm. The result of this iteration would be a block cypher function.

As usual, the bear has provided an excellent answer that covers this topic, and there is no need for me to repeat his efforts.


Let's break this up:

Bob and Alice want to engage in two-way email communication.
Bob and Alice need to use their personal email addresses.
Eve has the ability to observe all communication in the system.
Eve must not learn about any special communication between Bob and Alice.
(Alice must not learn that Bob is married.)

The last statement (5) prevents you from using collaborative systems to hide communication, since Alice would instantly start wondering if Bob asked her to use such.

However, without Alice participating, Eve will learn about Bobs unfaithfulness as Alice replies to Bob the latest.

I would therefore propose to drop point 5. If Alice actively helps Bob, they can potentially keep Eve in the dark.

To that end, Bob sends encrypted messages to all his friends (different messages to different people). Since Eve cannot decrypt them, she cannot read the message to Alice. And since all friends are receiving mail, Eve cannot infer a special relationship between Bob and Alice.

The important part now is to have many of Bob's friends answer his messages (therefore he must have sent senseful messages to them). Otherwise Eve could infer the recipient of the main communication (Alice), as Alice would be the only one replying.

Of course, all replies sent to Bob should also be encrypted. (But Bob surely only has security-conscious friends and mistresses.)

...To conclude, Bob is better off staying faithful ;)


How to set up two YubiKeys to have the same secret?

FIDO2/WebAuthn relies on a public-key cryptography. The private key is stored on your security token. By default, you can't clone the private key, see https://www.w3.org/TR/webauthn-1/#credential-loss-key-mobility:

In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering multiple credentials for the same user.

So the service provider (aka Relying Party Server) must allow registering multiple security tokens for backup purposes.


Organizing results from netstat using find on Windows

Depending on the version of Windows you are running, powershell should give you what you need.

Something like this:
netstat -ba |Select-String -pattern "EST" -context 1,0

Take a look at this technet article for some select-string info:
https://technet.microsoft.com/en-us/library/ff730968.aspx


Security implications of granting non-root access to privileged ports (<1024)

When you're using rootless Docker/Podman, the risks of allowing users to bind ports < 1024, generally depend on what else is happening on the system.
TBH the old restriction on low ports doesn't really apply that much any more, as loads of sensitive ports are over 1024 (e.g. Docker itself which will default to listening on 2375 or 2376).
There could be a risk where, for example, you had a sensitive service which you wanted to listen on a low port, and you were concerned that a user launched service would clash with it, or if you have multiple users who may want to bind a port on a host, and a malicious user could try to get access to it, before the "expected" user.
However where that's not the case, you're probably fine to allow this. Docker's recommended solution here is to allow this for all low ports, which is less fine grained than the podman recommendation you mention.


Seems to be just corruption because the names don't look structured enough in my eyes. Either way you should definitely run a malware check on your system.

HKEY_CURRENT_USER is simply a link to the registry hive of the user that is currently logged on. To find this hive manually, navigate to HKEY_USERS and select the registry with your security identifier (SID) (to find out this go into command prompt and enter wmic useraccount get name,sid - it will be to the right of your username). Once in this registry hive, does it look the same as HKEY_CURRENT_USER? If not then it's most probably corruption. If it is the same then try logging in as a different user and checking HKEY_CURRENT_USER to see if the same, weird registries are there.

Even still, the there are no registries missing in your HKEY_CURRENT_USER that should be there, so I personally would just delete them.


Why intruder number of threads has an effect on the time delay of indiviual requests

when doing blind timed SQL injection, timing is everything!
if you do this multi-threaded, you need to take care that thread switching does not interfere with your timing attack (both on your client as on the server).
since you have no control over how the server is implemented or how it handles treading, the default advise for any blind SQL injection based on time is to have only 1 tread of it running.
E.A. using multi-threads makes it easy to shoot yourself in the foot with false positives / negatives.


What are the major vulns that affect the Dalvik VM of Android?

The majority of the time that you read or hear about android malware it is in reference to a legitimate android app (apk) that does not actually exploit the android OS. Instead the malware behaves in a malicious fashion. One example is a fake security application which would subscribe the victim to premium text messaging services.

Many other times you will find a cracked app that just has additional ad services placed in it. Cracked apps are typically premium apps that were pirated. These apps are often published on third party stores and not in Google Play.

There is some malware that does use a known exploit. One example is a recompiled version of Angry Birds that received instructions from a Command and Control server. This sample used the GingerBreak exploit. Note that GingerBreak is/was used intentionally by users that wanted to 'root' or unlock their phones.

For a list of known android security bugs see this list of CVEs.

Android malware is a mix of apps that utilize OS exploits and apps that use all legitimate API calls just in a malicious way. If you want to avoid them pay close attention to the permissions of the apps that you install, think about getting a (reputable) antivirus from Google Play and avoid third party app stores with pirated apps. Finally in newer versions of android select "Verify Apps" in the security settings. This will act as a basic anti virus.


How to verify that someone is who they say they are online?

Identity is a malleable concept with an irksome tendency to morph whenever you look at it too closely. What I understand from your description is that you want to be able to track back some actions (i.e. "applying for a job") from a random network user back to the actual individual, in such a way that, should the job application be fake in some way, you have enough leverage to appropriately punish the perpetrator. Or, more accurately, you need to convince a priori the users that you will be able to track them down and, at least metaphorically, break their kneecaps.

Whatever the way you take the problem, part of it lies in the "physical world" (outside of the computers) so it is going to be hard and expensive.

The complete theoretical solution is to have some detectives do the tracking, which is feasible for the Long Arm of the Law but usually not for private business entities, because basic "network users" are identified solely by the incoming IP address, and to link that to a physical identity you must have a look at the ISP log files -- which requires a warrant, or indelicate accomplices. This is said not counting issues with connections from foreign countries (once you know that the connection came from China, well... you do what, exactly ?).

Thus, due to the impractibility and cost of true detective work, you will have to leech on an existing infrastructure which provides the authentication you need. My first thought is about banks. It goes thus: have job applicants pay you a minute sum (say 0.01$) with their credit card (or through Paypal or any other similar banking system). This has several benefits:

The payment operation leaves traces in many places.
Since a transaction was implied, it could help to legally qualify fake job applications as "fraud" (ask your lawyers, they will tell you that this is very good, with a gleam in their eye and a bit of frothing).
Credit card numbers are routinely stolen but you can get insurance against that.

and, last but not least:

People (at large) already know that "you don't mess with the banks". This makes the detection system proactive (you would like to authenticate people, but, even more, you would really prefer that they do not try to lie in the first place).

A conceptual note: as you say, you "know nothing about who is applying". That's the root issue: how can you define a proper identity notion if there is nothing to identify (to be precise, you do know something about the applicants: their IP addresses; but that's not much). Hence the path to the solution: have the applicants commit some information about them. This is what the banking solution explained above is about.


How do you find SSL Keys on Android (to decrypt SSL on WireShark)?

Is the server in which the app communicating with yours? If so can you export a copy of the certificate from their and import into wireshark?

If it's not yours then you don't have the private key to decrypt the traffic. You might be able to proxy the app so as to allow you too break the TLS connection- but it sounds like you tried the man in the middle approach already.

Remember the whole point of SSL/TLS is to stop interception of traffic so without the original keys it's not possible to 'see' into the unbroken communications channel.


In OpenId Connect, why aren't requested claims included in the Id Token?

Consider that the point of the authorization server is simply to decide whether you should be allowed to do something. The point of the user info endpoint is to provide information about who you are. The fact that the authorization server can provide this information to you doesn't mean that it should.

In some cases the authorization server may not know who you are beyond some credential, so it defers to another server to provide more information.


Is TLS secure when full eavesdropping on the network occurs?

Consider you want to send a letter to your friend. The content is secret. So you used a box having a special feature. Both of you will have a pair of keys to lock and unlock the box they are Public Key and Private Key. The scenario is the box can be locked using first key that is public key. But for opening that box you need to use second key that is private key.

Now, if you want to send a message to your friend you can ask his public key. He will give his public key. His private key is not shared with any one. When you receives the public key, you will put your message in that box and lock using your friend's public key. If you tried to open using the box using same public key it won't work because of the security feature of that box. You will send the box to your friend. If somebody tried to eavesdrop the box, they can't. It is not possible because the private key is not known for anybody except your friend. And don't think to break the private key using all key combinations. The algorithm used to lock and unlock the message is very strong and it will take million years to unlock if somebody tried to check using all the keys. The eavesdropper can get two information, who is  sender and who is receiver. All other information is hidden in that box. This is the simple scenario of  How TLS works. If your friend want to reply to you, he will request for your public key, lock the message using the key, send it to you. When you receives the message you will unlock it using your private key.

When you are using a website using https, your information including url, query string, contents, username, password are encrypted using the receivers public key. And the website replies from the website is encrypted with your public key. Your public and private keys are managed by your browser. So the content you are sending to the website is only decrypted by the web server and the reply of that request is only decrypted by your browser. No one else in the world can view or edit that contents. For more information you can Google Public Key Cryptography.


How secure are iPhone/Android/Windows 8 "PIN"/Pattern Lock features?

You are missing the point of the lockscreens of the various mobile operating systems.

They are not an effective deterrent for attackers who has stolen your phone and has an unlimited period of time to attack it. However, they are effective in deterring chance attackers who happens to walk by and only has a short period of access to your phone.


How to protect against backdoors in routers?

Most of the router backdoors I am aware of have been fixed quite quickly.  Believe it or not, the router manufacturers don't usually put the "backdoor" there on purpose -- at least not at the organizational level.  Almost certainly, they are either placed there as a debugging tool and meant to be removed before production, or placed there by a rogue employee.  (What benefit is there to a manufacturer to have a backdoor?  If they want to do something, they can do it via firmware updates.  Also, your network is just not that interesting to them.)

I don't know if "vast majority" is an accurate description either, but I won't quibble semantics.  You asked how to protect yourself, and here are some options:

Have your perimeter-most device (i.e., first hop from the internet to your LAN) be reputable.  Consider a Unifi Security Gateway, or a Netgate SG-1000 at the perimeter.  Both of those companies sell to enterprises, but also price products that can be reasonable for the power user at home.  They have a reputation to maintain, and that reputation is currently quite good.
Consider a router that lets you run OpenWRT or DD-WRT.  These codebases, while not immune to vulnerabilities, are at least open and reduce the risk of backdoors being placed in them.
Don't expose the web interface to the internet.  Backdoor or not, this is where a huge proportion of the bugs are.  Use an nmap scan from the internet to see what exposure you have.
Use a non-default subnet and change the port for the web interface.  I know, I know, security by obscurity, but it actually does help for exploits using DNS rebinding or similar techniques.  (This is only useful against automated exploitation, don't expect it to be useful against a manual attacker.)
Never trust the network.  Even if you have strong security controls, practice defense in depth.  Use TLS and don't click through certificate errors.  This way, even if your router is popped, it becomes only a denial of service instead of a more significant compromise.


Can an OpenPGP master key decrypt something encrypted for a subkey?

The OpenPGP primary key and subkeys are cryptographically different keys and simply bound to each other by special signatures defined by the OpenPGP protocol. They cannot be used to decrypt information encrypted for the other one.

This also implies you should never completely delete your old (encryption) subkeys but simply revoke them; otherwise you'll lose access to your old encrypted documents and messages.


Is it a good idea to use non-Latin Unicode characters in a password?

Probably not - you would find many compatibility problems depending on the supported character sets of devices that you may need to enter your password from.

There are two ways of making sure you have a strong password:

Use a source of entropy that the attacker isn't aware of.
Use enough entropy so that brute force is infeasible.

The approach your proposed method takes is the former. There are usually fewer disadvantages of the latter approach. If you use a password with at least 128 bits of entropy it cannot be guessed in a reasonable amount of time. That is on average - if the attacker is very lucky they might guess it first time - but the same is true with all passwords.

So to get 128 bits of entropy you either need a password with at least 20 completely random characters (using both case letters, numbers plus ASCII symbols) or you need 10 randomly selected dicewords.

So in my opinion this is already a solved problem. Use a secure password generator to create a random 20 character password if you don't need to remember it, or use Diceware if you do.


I don't think that there is a standard way that this type of fraud is perpetrated, but I can tell you what I have seen and what I do when this happens to us, when about once every two months we get "change my bank account" emails sent to suppliers "from" our mail systems.

Our first thought is that the scenario didn't happen and that we have fraudulent staff working in collusion with the supplier.  We have to rule that out, so we may review the staff emails looking for anything suspicious. This invariably turns out to be a dead end.

Then we ask if our own mail system or user accounts have been compromised: we have had this where a bad actor had access to an email account and could intercept, reply and delete mails as they arrived.  It was very cheeky so don't underestimate these criminals.  We spotted this as a users was logged in from two places at one, which is normal because of our business and use of VPNs etc. Because we have an immutable store of all messages we can see the deleted ones.  We put in two-step verification to mitigate this risk and now we are very confident that an email account with 2SV is not compromised.  Not 100% confident of course and it is still an option.

Then we look at the mails outbound from our domain and look for bounces and we ask the recipient email team to look in their logs for our mail.  This has mixed results.  In your case you say that your outbound mail never arrives, so I'd be looking at our outbound logs for mails to the domain and I would be checking the MX record of the recipient domain.  If the message really did go out from our system, I'd get the message ID from the header and ask the recipient mail team to tell me if they have received it.  The results are mixed because often the recipient organisation does not have an IT team and they don't know how emails get routed, delivered etc.  It would be quite unusual for all emails to mydomain.com not be be delivered at all and quite unusual for a man-in-the-middle to be capturing all the mydomain.com mails and forwarding them, but I guess it's possible.  If the recipient organisation never gets the mails then that spins off another query: why.  Of course trying to do this over email when the recipient email system might be compromised is flawed to say the least.  But the fact that your emails do not hit the recipient is a big indicator to me and I would want to get to the bottom of why.  My hypothesis is that the recipient has shared their web-email password and a bad actor is logging into their account because that is a simple approach.  Bad actors can get the password through various ways but one way that i have seen is they send a link to an online O365 doc or Google Doc that required a login and the user logs in using that link and the bad actor then has the password.  There are other ways, I'm just saying this is what I have seen.

You say that your client sends mails cc to a manager but those don't arrive?  That sounds like an interesting avenue to pursue.  I would want the sender to check their logs for mails to the manager and our system for mails inbound for the manager.  My hypothesis being that one or other of the mail systems is compromised.  In the investigations I have run, the compromise has usually (well always now) been with the recipient email systems, the reason for this is that our systems have many defences in depth but we deal with small suppliers who don't have an IT engineering function.  But we keep an open mind always as we really do not know until we have the data.

So now alice.smith@outlook.com sends an email to the recipient.  If Alice Smith's corporate email account were under the control of the bad actor then my assumption would be that they would not bother with the @outlook.com address, but that's just an assumption. I'd ask myself why the recipient is dealing with @outlook.com rather than the real company, but perhaps the bad actor has changed the FROM address.  We get that too of course.  If the email sent out does match the email that was sent back with minor changes the obviously someone has intercepted that mail.  I would want to confirm that though as the scams I have seen often have the email signature of one of our staff, it has a PO number etc but it's totally fake, but looks plausible.  We know this because there is no exact match in the immutable email store that has been altered, but the human sender misreads the situation and says that it is the same email.

We now realise that it's a fool's errand to try to stop these scams most of which now originate with the recipient: their mails are compromised, they answer a fake email and change details etc.  Some of the controls we have put in place to prevent a successful scam include:

2SV on all email accounts
immutable storage for all emails so we can search actual content without the users being aware (we have governance for the process)
Constant communication to staff "don't change bank account details based on an email" and "no, the CEO will never write to you telling you they want you to make a secret payment"
Our internal payroll teams don't (or shouldn't) accept a "change my bank account" email, they should use a form on the intranet so that deals with message spoofing, but not account hijack.  We have so many payroll teams though it does not always get through
SPF, DMARC, DKIM. These are great ideas and I am sure they work well for small organisations.  If you have these in place then the idea is that the recipient mail servers will use these to identify fraudulent mails.  In practice for a big enterprise it's a big old effort and we realised that implementing DMARC and DKIM would kill our business because of the vast number of email sending domains, devices, third parties etc and we would need to employ a team just to deal with that.  SPF works OK for us, most of the time.  If you are not aware of these then Wikipedia will guide you but as I say we found them a great idea but simply too complicated for us to use in our enterprise. O365 may well come with these in place already?
Mail inbound rules that flag spam from known bad domains.  We know about legitimate service providers that host spam sending servers that our mail spam engine allows through, so we flag all mails from, for example, GoDaddy servers.  It's whack-a-mole and we really let our cloud email service provider deal with spam

We have not implemented any third party tools that do "email security" because of the cost and because we have protection from Google, which isn't perfect but it's good enough.

When i look into these issues I find these tools useful

https://toolbox.googleapps.com/apps/messageheader/ to review the message headers
https://mxtoolbox.com/ to check the MX records and other DNS-type data

I have not answered your question directly for your specific case because I don't have enough data, though others may have come across this exact scenario, but I thought it might be helpful to share what I do although I accept it's not a perfect process and I make assumptions that are not 100% proven.


Does a TLS-connection to a proxy-server encrypt the destination url's?

The full URL (hostname and path) is only inside the HTTP protocol and is thus encrypted by the TLS layer. Also, any HTTP headers and payload of request and response are end-to-end encrypted.  But, the hostname part of the URL is usually in the CONNECT request when using a non-transparent HTTP proxy, unless the client itself makes the DNS lookup. With a SOCKS proxy the situation is similar, i.e. the client provides the target IP (SOCKS4) or might provide the hostname (SOCKS5). Additionally the hostname is usually included in the TLS handshake too in clear (SNI), no matter if using a proxy or not.

This means it is known to the provider of the proxy (maybe the ISP) which host your are accessing but not which page on this host. Also any hop after the proxy knows  at least the target IP because this is needed for routing. And if SNI is used (i.e. in most cases) any hop can also find out the targets host name.

In short: the goal of TLS is not to keep privacy or to allow anonymous connections. The goal is to protect the data transferred between client and server against sniffing and modification.

  And who does the DNS lookup?

With a SOCKS4 proxy it must be done by the client (browser). With a SOCKS5 proxy or a HTTP proxy it can and will usually be done by the proxy since these protocols can transport the hostname instead of the IP address.

Edit: I was not aware that recent versions of Firefox and Chrome actually support connecting to a HTTP proxy with HTTPS. In this case only the connection to the proxy is visible to any hop before the proxy and thus the URL including the hostname and IP address is fully protected on the path to the proxy. On and after the proxy this additionally TLS protection is removed and thus the hostname and target IP address are visible again as described above. I would assume that the browser sends the hostname and not the IP address to the proxy (because this is done with a normal HTTP proxy too), so the DNS lookup will only be done at the proxy.


Based on these HTTPS requests what type of attack is this?

It's difficult to know just by looking at the requests exactly what the attacker is attempting. However, the most likely scenario is that the attacker is simply fuzzing your API and looking for any anomalous responses that would warrant manual review by the attacker.


It is a base 64 encoding for an HTML five web page with the following content:

Sign in with your email and password.

Receiver's Email Address

Password

Stay signed in
Uncheck on public devices.
This PDF is protected VIEW FILE

Sign in with your receiving Email and Password.

click
You can see the html page if you copy and paste the encoded base 64 into https://www.base64decode.org/ and then copy and paste the decoded result into a file and open it with a browser.

There is a JavaScript URL that returns an error:

<Error>
    NoSuchKey
    <Message>The specified key does not exist.</Message>
    <Key>renga-&</Key>
    <RequestId>DE746594286EECD9</RequestId>
    <HostId>
        SI3jiVV8+qsJR19JyD0fo+qXukQtBkoGl5wEyOlw8Ei2pGsCdm5O1qnTaz6+YQxp73pItZfPegQ=
    </HostId>
</Error>

It may have been a security risk once, but it appears to be benign at this point.  Nonetheless, I would not select or do any other actions other than "inspect" on any HTML elements when viewing the page.

In general, I delete all emails with attachments.  If someone wants to share a document, they can post it online as a PDF or HTML.  If a picture, they can share it on a social network or send it as a Facebook attachment it.

Email is a horrible communication device from a security point of view.  It arose as a messaging device during a time when only research labs, defense systems, and major universities used networking at all.  Transition away from it if you can.


Metasploit reverse_http(s) PAYLOAD for linux target

If reverse_http(s) is not in your payload binaries then you can manually add it. You can download and add the payload from the link below. At the bottom of page there is a download link

https://funoverip.net/2012/10/metasploit-stager-reverse_https-basic-authentication-against-proxy/


How to verify that a host applied a firewall ruleset as is?

If the attacker has enough control of the host to manipulate your codes perception of the state of iptables then the host is compromised and you can't trust it at all! Iptables maybe patched to subtlety allow the attacker to bypass your rules but still respond telling everyone on the system that everything is fine.  Iptables is useless at this point: putting a Bulletproof vest on top of a gunshot wound  won't stop the bleeding!

The only real solution I can see is to use  tripwire or an other host based intrusion detection system  to monitor the host for changes that look malicious. Whatever you do though you cant be 100% your host isn't compromised. It's a matter of risk mitigation.


Android N - Security Crypto Provider is deprecated

My question is are they talking about whole javax.crypto package ?

No. They are referring to the Crypto provider for javax.crypto.

  Do I need to remove these all ?

No. So long as you did not manually specify to use the Crypto provider, you are fine. Search your code for the string "Crypto" (with a capital C).


Argon2id key derivation rate calculation question

You've assumed that the derivations can happen in parallel, which might not be possible, but your calculation will give you an answer to the correct order.


Strategy for electronic document (PDF) signatures

See https://crypto.stackexchange.com/questions/29501/how-can-cryptographic-signatures-be-somehow-linked-to-a-physical-signature for an outstanding explanation of how services like DocuSign actually work - including their use or cryptography (or lack thereof). In short, these types of services basically function as a 'witness' to attest that someone with access to a particular user's account agreed to the terms of a particular document. Although these services tout the use of cryptography in their marketing materials, cryptography actually does not play an integral role in the actual 'signing' process.


Benefits of open-source security

  More people can inspect the source code to find and fix a possible vulnerability. This can lead to both faster discovery of unintentional
  security vulnerabilites and prevention of intentional vulnerabilites
  (backdoors) in the code put there by the developers themselves.
  Proprietary software forces the user to accept the level of security that the software vendor is willing to deliver and to accept
  the rate that patches and updates are released.
  The end-user of open-source code has the ability to change and modify source to implement any extra "features" of security they may
  wish for a specific use, which can extend to the kernel level if they
  so wish.
  It is assumed that any compiler that is used creates code that can be trusted, but it has been demonstrated by Ken Thompson that a
  compiler can be subverted using an eponymous Thompson hack to create
  faulty executables that are unwittingly produced by a well-intentioned
  developer. With access to the source code for the compiler, the
  developer has at least the ability to discover if there is any
  mal-intention.
  Kerckhoffs' principle is based on the idea that an enemy can steal a secure military system and not be able to compromise the
  information. His ideas were the basis for many modern security
  practices, and followed that security through obscurity is a bad
  practice.

https://en.wikipedia.org/wiki/Open-source_software_security

Eventually the point is; if I can read it, I can find it. I can find the mistakes and malicious code lines in any kind of computer program "easily". That means open-source is more secure than closed source.

  The development of Linux is one of the most prominent examples of free
  and open-source software collaboration.

https://en.wikipedia.org/wiki/Linux


Is it secure to refesh a JSON Web Token (JWT) auth token using the user credentials?

The refresh mechanism is precisely built to avoid saving credentials. Credentials give you access to the whole account, whereas the refresh token only gives you access to auth tokens that will work for the designated domain.

You say you app is stateless, but if you can save credentials why can't you save a refresh token?
Besides, your app should handle expiration of the credentials as much as it should handle the expiration of the refresh token. Here are a few ways for credentials to expire:

User changed password
User lost right to run the app
Account was suspended
User changed username

So here is the basic design you should follow:

Try communicate with your resource API using your auth token
If 1. failed, try acquire an auth token with your refresh token
If 2. failed, show login view to acquire a new refresh token

I suspect you are using OAuth. Respect the design pattern you're following, doing anything out of the pattern will put you at risks.

You could also offer your users the possibility to revoke a session (refresh token). That way, they can log out a compromised device without having to change their password. If you save the password, the only way to remotely log out a device is to change the password, hence logging out all you devices.


When to set security questions for a web application?

No right answer.

I hate security questions though. Never remember them. Usually fill them with random stuff. If I do need to recover the site, I'll call the company or file a support ticket anyways.

You didn't give enough information to really understand the situation, so here are some options.

Option 1
 1. creates account
 2. confirms email
 3. answers sec questions
 4. Uses site

Option 2
 1. creates account
 2. answers sec questions
 3. confirms email
 4. uses site

Option 1 and 2 are the same. Both questions and confirmation are required before the user can do anything.

Option 3
 1. creates account
 2. Uses site
 3. Tries to do something (save data, print, email, etc)
 4. Forced to confirm email
 5. Forced to answers security questions

I like option 3 if your site supports it. The user can use the site, but you block them from any real functionality until they confirm their email. It gives the user a chance to evaluate the site before committing extra time.

Option 4
1. Creates account
2. Confirms email
3. Uses site
4. Next Login, asked security questions

Option 4 is how gmail approaches extra security features. The present the user with an option to enter phone numbers, and other recovery items. Of course, they don't do security questions. They use phones. Which is a lot less burden on the user.


I found an unknown UFW rule on my ubuntu server - have I been compromised?

Any open port can only be dangerous if there is some process listening to it. You say there is no process listening to it. So I would say there is not much risk.
See RFC 6335. All ports are split into several regions that have different purposes. To 49152:

Ports in the Dynamic Ports range (49152-65535) have been specifically
set aside for local and dynamic use and cannot be assigned through
IANA. Application software may simply use any dynamic port that is
available on the local host, without any sort of assignment.

Some of applications has used it. Which one, it is impossible to say.
Should you worry? I don't see reason to expect high risk.
If you are curious what might have cause it, I'd suggest to look at syslog. There might be entries where this port is referenced.


OAuth2 - Resource Owner Password Credentials grant

These are really two questions.

How can I guarantee that requests from sources claiming to be this client application can be trusted?

You can't. The specification says:

  The resource owner password credentials grant type is suitable in
  cases where the resource owner has a trust relationship with the
  client [...]

The resource owner (aka. user) has to decide if he trusts the client, not the authorization server. If the user decides to trust a third-party app so much that he enters his plain password, you can't automatically detect if the third-party app is trustworthy.

What's to stop them client making authentication requests to that endpoint with the client id? I'd consider assigning the client a client_secret, but it just seems like that won't solve the issue because a user could just find it in the app.

OAuth2 differentiates between confidential and public clients. Confidential clients are "capable of maintaining the confidentiality of their credentials", for example a web application which access another on server-side.

Native applications (like an Android app) are mentioned explictly as public clients:

  A native application is a public client installed and executed on the
  device used by the resource owner. Protocol data and credentials are
  accessible to the resource owner. It is assumed that any client
  authentication credentials included in the application can be
  extracted. [...]

Therefore a client secret won't add security to a native application in most use cases.


I found a browser extension I don't trust installed, should I worry?

The short answer: Yes, you should be worried.

There have been quite a few cases recently of malicious (or hacked) browser extensions harvesting user data, notably Catch-All last year, and the MEGA.nz extension being hijacked by hackers this year (and plenty of others, but that's enough examples to make the point).

Without knowing more, such as knowing how the extensions came to be there, and what permissions they had (see this question), it's hard to be certain exactly what the risks are. But assuming the worst is the safest option.

Malicious browser extensions are a serious risk to personal information and password security.


I copied my .gnupg folder from Mac OS X, and now Seahorse lets me sign my own key. Is this normal?

If you generate a public / private PGP key pair and publish the public half without signing it with the private half you're leaving yourself susceptible to a denial of service attack. Once you push your public key to a PGP server, it can be modified by an attacker and redistributed.

The attack goes something like this: attacker gets your key from the PGP server, modifies the user ID (email) while the key fingerprint will remain unchanged so the key will still look authentic.  They then redistribute they key as widely as possible, maybe through another PGP database.

Anyone who doesn't already know your email and has to rely on the public PGP database to find it will send messages to this new ID and you'll never get the mail.  Still, the attacker won't be able to decrypt them without getting your private key so it's just a DoS and one that isn't very effective IMHO.  Very few people use PGP servers as address books these days.

Still it's a possibility and one that's well known and easily defeated.  Last I remember most PGP applications sign they public key when the pair is created by default but it's been a long time since I've created a new key.

There's a good write-up about this here: http://www.heureka.clara.net/sunrise/pgpsign.htm


Should I complie software after making all the variable and function names "1-2 character"?

Often times what you are seeing with those few-character variables names is JS code that's been minified and packed down to reduce its size, allowing the client to download- sometimes significantly- fewer bytes than if the code was otherwise not minified; the slight obfuscation you are seeing is merely a byproduct and not the main goal of minification. Something like JS Compress can compress code up to 80%.

If you are seeking true obfuscation you could try something like obfuscator.io which can make it harder to decode what is actually going on, though it is important to note that all front-end code obfuscation techniques can be reversed. Obfuscation serves to slow attackers down rather than keeping information secured.


Is Stonesoft's "advanced evasion technique" a major problem?

I don't know specifically about Stonesoft, but not only is IDS evasion real, it's also nothing new.
There have been any number of techniques, vectors, and attacks to evade IDS - and really any network filtering mechanism - dating at least back a dozen years or so to RainForestPuppy's classic work on evasion mechanisms. New techniques come out all the time.


Certificate - Digital fingerprint vs Signature

The "fingerprint" (or "thumbprint") is NOT a part of a certificate. It is computed by some software (e.g. Windows) as a hash of the complete certificate (including the signature).

The point of the thumbprint is to serve as a human-manageable identifier for the certificate. For instance, when you import a certificate in the "trusted root" store of a Windows system, a popup appears that displays the thumbprint of the certificate, and asks you to check whether this is the right value. The user who is importing that certificate is then supposed to check the thumbprint against a reference value (e.g. a signed paper document that was provided by the CA sysadmin); comparing two 40-character hexadecimal values is not the summit of user interface conviviality, but it is still a lot more doable than checking the 2000-character hexadecimal encoding of a complete certificate.

The point of such a check is to make sure that what is imported is the genuine root CA certificate, not a fake one that was substituted by a malicious attacker. Thanks to the thumbprint-checking, how the certificate was transported becomes irrelevant (e.g. it could be sent over plain HTTP or even in an email).

Using the thumbprint in that way is safe as long as the thumbprint is computed with a cryptographic hash function that offers second-preimage resistance. As far as we know, this is still the case for SHA-1 (SHA-1 has known theoretical weaknesses with regards to collisions, but collisions are not relevant here).


Security of login-data saved in browsers

The problem with web-browsers is that they run arbitrary code sent to them by random sites and ad-networks on the Internet. Because of this they are commonly the first line of defense for keeping the badware out. Some companies choose to manage this risk by greatly restricting where employees are allowed to go.

Over the years there have been a variety of attacks focused on extracting browser-cached login credentials. All browsers have some built in way to store login info, and a couple have plugins that extend or armor this very process (1password comes to mind). Browsers that use a single master process to do most things tended to be more vulnerable to these sorts of attacks.

Browsers are a lot better about this than they used to be, but it is still a risk that needs to be managed.

One thing to note though, is that with Internet Explorer it generally wasn't possible to get the user's Security Token the same way an attacker could get the cached site-passwords since the Windows security model requires a deeper penetration for that. Once the badware has installed a couple rootkits, all bets are off though.


If your referring to spam comments then you might want to check out the WordPress Akismet plugin which checks comments against the Akismet web service to see if they look like spam or not.
Its very good and in a lot of cases eliminates all potential spam. I use it on my blog and in a year its blocked ~4,000 spam comments.


Affected by Marlboro Ransomware (".oops" extension) - Which decryptor to use to decrypt the files?

You can use the decrypter available here:

https://decrypter.emsisoft.com/marlboro

I am the author of said tool. Yes, I did see the answer above. However, I can't comment because of lack of reputation. To address what has been said:

The decrypter doesn't need an internet connection or the infected machine. So feel free to run it in a VM with no internet access or disconnect the network cable. If for some reason it doesn't work, please let me know.

Also due to a bug inside the malware, it will truncate up to 7 bytes from the files. There is no way for me to restore those. So some files may not work, depending on how sensitive the file format is to having some bytes missing at the end.

Regarding our reputation:

The decrypter is EV signed. Meaning, we went through the extended verification of the CA so the identity of the company has been thoroughly verified. Whether you want to trust that, is up to you. We have released a tonne of decrypters (as can be seen on https://decrypter.emsisoft.com), cooperate with law enforcement agencies in the No More Ransom project, take part in various reputable AV comparison tests (AV Test, AV Comparatives) and are a Microsoft anti-virus partner.

If you run into any issues, feel free to let me know or shoot me a message :)


Phones broadcast the SSIDs of all networks they have ever connected to. How can these be obtained by an attacker?

Fairly easy to be honest, all you need is to do is listen for Probe Requests. There is a nice blog explaining how to go about setting up a computer with BT5 to listen for them here.

With a networking card that supports "Monitor mode", you are able to pick up so called "Probe requests". Once the networking card is set up to be in monitor mode you can use something like aircrack, wireshark or hoover to capture the probe requests.

For example when using ubuntu and wireshark, set the network card in monitor mode:

sudo ifconfig wlan0 down
sudo iwconfig wlan0 mode monitor
sudo ifconfig wlan0 up

Now start wireshark and set the filter for "wlan.fc.type_subtype eq 4".

That's it, now you can see all the SSIDs being probed for around you.


Do LAMP log files sometimes contain sensitive information?

Yes, it's possible it may contain sensitive information. A lot depends on what you consider 'sensitive'. That the IP address 123.123.123.123 access www.hotpron.xxx at 7pm on Sunday contains no user identifiable information but might be extremely sensitive to someone.

The normal logging provided by Apache will only record

GET variables
any cookies you explicitly include in the log format

It will also record usernames used for authentication by the webserver (rather than the code itself) via the mod_auth add ons. Again this is configurable.

And the error log will contain anything your application chooses to write to it.

It's possible to get it to log POST variables as well using (e.g.) mod_security - but this is more involved.

Generally most people would consider it very bad practice to pass authentication tokens (usernames, passwords, session identifiers) via GET variables.


Is it safe to store encrypted volumes on cloud syncing services?

Take a look at Ferguson's criticism and the official response at the bottom of page 2 and top of page 3 here:  http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/follow-up_XTS_comments-Ball.pdf

XTS sector/block mode (used on Truecrypt, Drivecrypt, etc) has a temporal quality that can certainly leak information.  Ferguson says an adversary who observes 4000 writes to an encrypted 4K sector will have obtained access to well over a million (2^20) ciphertext blocks encrypted with the same tweak and key.

I'll add that since most crypto volumes of windows users these days will be formatted NTFS or FAT32, the attacker has a pretty good idea where to look for frequently changing file system structure data that (a) has a defined range of possible known plaintexts; and (b) a predictable location given the size of the volume file.

Putting encrypted volumes in the cloud does all the "work" that the IEEE response said would make the attack on a volume infeasible.  The security model was never meant to be solid when you make the entire internet into a potential evil maid who can monitor the changes on the encrypted volume.  Even less so if the cloud service is doing the versioning that does even one more step for the attacker (i.e., collect and aggregate just the changed sectors).


Why doesn't Google's "new sign-in from X" email notification contain the IP of the computer that connected to my Gmail account?

I think this an answer you will only be able to get from someone who works for Google. But I do have a few theories:

Google does not want to scare none technical users with a set of numbers they have no idea what they are.
Why show the IP when they can just show the location? Most users would probably look up the IP anyways so Google saves them time by showing them the location (I notice that in your notification it does not say the location but usually they do).

Note: If you ever want to see the IP's of any session that logged in, you can scroll to the bottom of the page on Gmail desktop version and on the bottom right under "Last account activity" click on "details".


Using DD to get the hash of a non-system partition encrypted by VeraCrypt

Your dd command is simply copying 512 bytes to the output file. If you want a hash, you need to pipe it into a hash function such as:

dd if=\\?\Device\HarddiskVolume11 bs=512 count=1 | md5sum

For example on my Linux machine (with normal slashes instead of Windows backslashes):

dd if=/dev/sdb bs=512 count=1 | md5sum
1+0 records in
1+0 records out
512 bytes copied, 0.00163753 s, 313 kB/s
5b31a7aa24ccde6a44083cb30e33db4d

--------  edit --------

I see; you are trying to get a volume header not produce a hash.

First you need to make sure you're viewing data in a consistent manner. I'm not sure what Windows commands and tools you have available, but I suggest you display your data in a canonical format. One way is by piping your data to hexdump, for example:

dd if=veracryptcontainer bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes copied, 0.0578936 s, 8.8 kB/s
00000000  21 09 b4 29 58 67 31 ca  22 f3 8f bb c9 65 33 63  |!..)Xg1."....e3c|
00000010  54 de 18 44 2e 95 2e 7b  74 6b cc 4a dd 80 77 8b  |T..D...{tk.J..w.|
00000020  e8 c3 fb 5f ec 44 ea 67  1a de 9a 21 2a e9 06 c8  |..._.D.g...!*...|
00000030  bb 5a b8 c0 79 ad 66 c2  6b 51 03 03 8c ba 74 94  |.Z..y.f.kQ....t.|
00000040  96 de 57 8f 34 6b 65 e0  92 56 bf 14 71 0b 37 43  |..W.4ke..V..q.7C|
00000050  f3 dd d2 cd 06 aa 50 ee  46 20 c9 2d 55 4b a5 df  |......P.F .-UK..|
00000060  73 cf a3 d3 a3 d3 b2 86  07 a0 d0 1b 4f ea 68 ce  |s...........O.h.|
00000070  77 01 98 e0 5b ea e5 22  be ff 09 0b ef 6e f9 ce  |w...[..".....n..|
00000080  c9 e6 6a 15 30 85 ff e5  bc 7b 5e b8 2f 35 f1 4a  |..j.0....{^./5.J|
00000090  ac 1a 76 e5 33 e2 37 8d  fd a0 b8 e5 ad e2 85 58  |..v.3.7........X|
000000a0  0f 8a 1a 42 85 f5 23 2b  b9 be ef 8e a8 68 82 b0  |...B..#+.....h..|
000000b0  63 a5 91 1d 7c 74 b4 c9  bc 9f fe 4e a1 e8 63 17  |c...|t.....N..c.|
000000c0  af 77 0d 73 70 7d 27 12  a6 48 3d 82 bc e2 ba 08  |.w.sp}'..H=.....|
000000d0  be c5 2d 4a a9 86 d6 e6  1f 9c 5e da d1 0e c9 e6  |..-J......^.....|
000000e0  0b 94 47 df 3a 21 f3 73  3a d4 56 d3 a2 cb 0c de  |..G.:!.s:.V.....|
000000f0  ca 20 64 bb f0 c9 1a f4  b4 a7 78 c1 d9 3a 85 7a  |. d.......x..:.z|
00000100  51 f8 27 02 c6 4c f3 03  e1 69 b7 5f a2 9d 6f 10  |Q.'..L...i._..o.|
00000110  c2 dd ac 1f 39 5c 76 e6  44 15 f7 12 7c 25 42 6a  |....9\v.D...|%Bj|
00000120  d9 68 91 2b b5 9b 79 be  70 c7 07 a4 97 2f 53 57  |.h.+..y.p..../SW|
00000130  1c 62 22 89 7a fd f0 66  e8 ce 4e 33 78 9a 6a 2c  |.b".z..f..N3x.j,|
00000140  7d b3 d1 3a bc dd a7 2b  bf 7a 5f ce 93 55 c7 2e  |}..:...+.z_..U..|
00000150  41 b2 24 9e fe 94 17 8a  34 17 2f 8a 3b d0 b9 d1  |A.$.....4./.;...|
00000160  ca 6b 07 1f 3c 40 66 88  f9 38 b2 d1 2a 07 b3 01  |.k..<@f..8..*...|
00000170  10 3c a8 5a 8c 62 42 fa  37 df 4f 16 3d 73 f5 9d  |.<.Z.bB.7.O.=s..|
00000180  08 3b 22 d0 a0 58 b7 fa  f1 0c f8 0e 6f c0 eb ce  |.;"..X......o...|
00000190  2f 7f a5 36 12 3f 14 52  28 97 c9 42 e3 71 66 81  |/..6.?.R(..B.qf.|
000001a0  92 90 6f 74 ee 42 df 49  1a 08 77 53 83 0c bc e2  |..ot.B.I..wS....|
000001b0  13 a5 76 49 96 50 b4 e2  66 17 95 b4 6f f4 7b 9b  |..vI.P..f...o.{.|
000001c0  73 72 ae da ed 4e 2a 82  2d b4 7b c8 1d b4 f4 9e  |sr...N*.-.{.....|
000001d0  8f f9 30 ee f1 50 db 3d  bc 55 25 27 0b 62 78 15  |..0..P.=.U%'.bx.|
000001e0  bb 6b 9a f0 ac 3c e1 b4  e3 9f 00 8d 5e b3 aa bd  |.k...<......^...|
000001f0  72 55 6c 2e c5 34 ff 48  4c 18 41 e2 2b ca 20 17  |rUl..4.HL.A.+. .|
00000200

Second cracking Veracrypt without knowing at least a targeted subset of candidate passwords is a mighty undertaking. Veracrypt non-system hash round counts defaults to a half million. On top of that it allows custom round counts.

The Veracrypt volume header structure is documented here: Veracrypt Volume Format

If you pull this off, please tell us!

---- Second Edit -----

I fired up a Windows VM and tried out "DD for Windows" which I had never used.

When you run dd --list, pay careful attention to the target device. Does it show more than one partition? I plugged in a simply FAT32 thumb drive with only a single partition but DD for Windows showed it as two partitions like this:

\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR2
  Removable media other than floppy. Block size = 512
  size is 4089446400 bytes
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\HarddiskVolume5
  Removable media other than floppy. Block size = 512
  size is 4089069568 bytes

Examining this in Linux with fdisk shows the start of the one and only partition is not zero. Apparently DD for Windows represents this offset as a partition.

The net result is that the difference in sizes of the two partitions divided by 512 is the skip=value you need for your dd command if you picked the raw device instead of the partition.


Security difference between web tokens and message signing

Signed tokens are useful in the situation where there is a separation between the server that logs you in and the server that provides the service. The server that logs you in provides you with a token, signed with its private key. The server that provides the service doesn't need to know that key, can check with the login server's public key to ensure it is valid.

Simple sessions are great for single server setups, but can be more challenging (though not impossible by any stretch) to scale, since the session id needs to be looked up server side in order to validate it - a session id is valid if and only if it is in the server's active session list. That means that if a session is created on one server, there needs to be extra work for a separate server to recognize it. There are frameworks for cross-server sessions, but it isn't the default in most cases.

If you do do tokens, you need to ensure that all tokens you accept are appropriately signed and that you check that they are exactly as you expect. There have been some vulnerabilities noted that happen when you are not rigid about the algorithms you accept on your site - you need to go beyond the JWT standard and actually enforce your own stricter standard in general. (I disagree with the conclusion of that article, but you should be aware of it if you do JWT or similar tokens)


Yes, if you uncheck that your traffic will be unencrypted.


Entering payment information in Android Apps

If the app opens the payment page within the app, there is no way of knowing whether this is actually a HTTPS secured page or whether it is an unsecure site or even just part of the app itself which may grab your details and send them off to the malicious developer of the app.

The same goes for apps that ask for your Facebook details in order to login.

At the end of the day, you have to trust that the app is not tricking you into entering your details.


Hash pepper in web application possible?

The use case of a "pepper" is to make it impossible to crack password hashes in the case the attacker has obtained the password hashes but not the pepper value. One such scenario would be limited SQL injection, where the database contents can be read but not the file contents.

One way to provide similar security would be to use asymmetric encryption. The client encrypts his password hash with the public key of the server. The server has the corresponding private key and can decrypt the password hash to verify it. This way, the client can perform the work to make the password hash available only to the server.


How to gain credibility for your application?

There are several popular approaches to this.

First, is getting an independent, 3rd party auditor to vouch for you. This is most effective if it is done by a well-known name (e.g. get Troy Hunt to vouch for you, or Charlie Miller if you're on Apple's OS), or a huge household name (if your target market are non-technical / non-security folk) - e.g. E&Y, or Accenture.

Taking this a step further, you can get accredited by a 3rd-party regulation or certification. This is possibly the most popular, and IMO likely the least effective.
This could range from PCI-DSS (which you would have to do anyway if you handle credit cards), through to the infamous "HackerSafe" (I think its called "McAfeeSECURE!!1!" now). Either way, it doesn't actually show any real quality, and in some cases is easily spoofed. cough cough

There is a third option, which is much more difficult to do right, but a lot more effective particularly with those that most understand what this means. This option requires two steps:

Actually being secure, and having a strong process to ensure this;
Sharing details of that process, and what it actually entails.

Being secure is a much wider question and out of scope of this answer; sharing the details is obviously much less common in big corporates, though I am starting to see this in more startups and even larger, but technical, enterprises.

This could include information about your SDLC; explanations of your security requirements; technical details about your implementation; possibly an open bug bounty, but at least a statement of response to researchers (and follow through!); maybe even opensourcing your codebase, if relevant; and so on and so on.

Obviously you would need an experienced security expert to help you get your application to be secure; a very good one could help you "open the kimono" in a productive, yet secure, manner. Done right, this could even increase marketing efforts, and still not reveal any sensitive details that could help an attacker bypass your controls.

Interestingly often old-school security pros (especially those with a corporate background) will insist on not revealing anything; but not only should this not at all increase your risk or attack surface (if done right), it can definitely help allay any potential customer fears or worries, especially if they understand what they're reading.
Just make sure you have someone who knows what they're doing.