Optimal variable sizes in the Secure Remote Password protocol

RFC 5054 has a bit more precise recommendations. To be coherent, one must try to achieve a given "security goal" expressed in bits as a parameter t: namely, that the system is secure against attacks which have a computing power up to 2t elementary operations. The traditional value for t was 80 bits, but advances in technology make available computing power uncomfortably close to that limit. Since cryptographers just love powers of 2, it is now customary to use 128 bits as security goal. Even with an over-optimistic estimate of how long Moore's law will keep on and what it means, 128 bits are still safe for at least the next 40 or 50 years, and beyond that predictions are rather meaningless.

To get t bits of security, you should have the following:

The Diffie-Hellman private elements (here a and b) should have size at least 2t bits (hence 256 bits -- that's what RFC 5054 recommends, by the way).
The involved hash functions should have output size at least 2t bits in all generality, also shorter output size are tolerable in many cases (2t bits of output are about having 2t resistance to collisions, but in many cases collisions are not an issue, we just want 2t resistance to preimages, and for that t output bits suffice).
Symmetric encryption keys and MAC keys should have length at least t bits (and AES can work with 128-bit keys).
Ideally, salts should have length 2t bits so that risks of having a collision (two identical salts for distinct users) are lower than 2-t, but you can have shorter salts because the server can control how many users it may have, and it will certainly be much slower than 2128 (here, we are talking about the computing power of the server, not the computing power of the attacker).
The value u, as an online challenge, should have length t bits, but there again, a shorter value is perfectly tolerable because the size of u can be exploited only in online attacks: with a 32-bit u, an attacker has a 1 in 4 billions chance of pulling off an impersonating attack, but every failure is visible to the client and server. There again, the server will have some trouble serving billions of requests in a short time, and will certainly not do it discretely. Also, the attacker could also try to guess the password itself, under the same online-check conditions, so it is rather meaningless to have a u longer than the expected average password entropy -- and 32 bits of password entropy are already an optimistic figure.
n (the prime number) should be large enough that discrete logarithm modulo n has difficult at least 2t. Such "difficulty" is hard to estimate since it works on costs which are of distinct nature than what is used to, e.g., break symmetric encryption. Nevertheless, there are tentatives. 4096 bits are quite an overkill; I would personally be quite happy with 2048 bits.

SRP results in a shared secret value S, which is then extended into symmetric key material through a Key Derivation Function. SHA_Interleave() is a proposal for such a KDF. In RFC 5054, the KDF defined in TLS is used instead (under the name "pseudorandom function"). For proper data tunneling, you will want four 128-bit symmetric keys: an encryption key and an integrity check key in both directions. If you use a combined encryption-and-integrity mode, then you only need two 128-bit symmetric keys (one in each direction).

This really looks like you are reinventing TLS with SRP, something which is hard to get right at so many levels that you really should use the genuine TLS instead.


Is it common? Yes.

Does this provide any increased security? Not at all.

As it is, CAPTCHA provides minimal benefit, even in the best situations. Remember, the alleged purpose is to reduce flooding of a certain request, protecting a specific asset. I say "alleged", since that is not what CAPTCHA is even designed to do - it is designed, quite explicitly, to "tell computers and humans apart".
There are many possible ways to abuse a service via overuse, even as a human. Likewise, there are many legitimate uses for a computer accessing the service.
A good summary here on Sec.SE

That said, it is not clear from your question what the CAPTCHA is ostensibly protecting: if this was a feature to anonymously send an SMS, for basically any internet user, that could be a decent use of CAPTCHA to prevent spamming and overuse. (FTR, there are still much better solutions, but nonetheless this is still kinda valid-ish).
It does seem from your question that unvalidated users cannot actually send SMS, so if its just a question of viewing certain pages, that is definitely pointless.


Intercept DNS query packet and send spoofed response after ARP poisoning

You can do this using DNSchef. It is described here at the Kali Webpage. You can also find a useful documentation at the developers webpage.

When it gets more complex I suggest you to use configuration files instead of command line switches.


What are potential risks of using PGP for website login?

As this is for education/learning purposes and not a production solution, the normal warnings about not rolling your own security solutions don't apply. However, still strongly recommend looking at some of the established solutions - possibly doing so after attempting your own solution is a good idea as you may understand why things are done a certain way or some of the issues a little more.

Some things to consider with your solution (just off the top of my head, no real deep thought).

Cut and paste - or using the clipboard generally has a number of security risks. Last time I looked (a while ago now), Metasploit even had a module which you could use to steal the contents of the clipboard.
Your scheme is really only providing assurances in one direction. There is nothing which would prevent me from getting your public key, spoofing the site and then creating a situation where you think your authenticating against the site, but are actually authenticating against my spoofed site. Similar issues with man in the middle attack - attacker can simply pass through the encrypted string to you, get back your decrypted version and then login to the site. You will need to ensure your connections are over SSL with a valid and verifiable SSL certificate.
Randomness of 1000 character string. This is often the big weakness. It is vary hard to generate true randomness and is why some programs which require randomness will do things like require you to move the mouse around while the random value is being generated. If your initial 1000 character string is at all predictable, then it would be possible to narrow the search space for decrypted versions of the string and effectively bypass the need to have your private key to decrypt it.


Do any speculative executation attacks affect ARMv7 CPUs?

ARMv7 is a version of the ARM CPU specification, not a specific CPU design.

Some ARMv7 implementations, like Cortex-A15, make use of speculative execution and are affected by the Spectre vulnerability. Others, like Cortex-A5, do not implement speculative execution and are unaffected.

For details on which ARM cores are affected and what mitigations exist, refer to: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability


How to tell if Microsoft office has been patched for a vulnerability?

Microsoft provides extensive release notes for all of their products. They clearly label patches that fix a security defect.

https://docs.microsoft.com/en-us/officeupdates/


How common is it for CAs to issue end entity certificates with Extended Key Usage marked as critical?

While absence of evidence isn't evidence of absence, the general answer is "no, TLS certificates do not get their EKU marked as critical".

RFC 5280 says "This extension MAY, at the option of the certificate issuer, be either critical or non-critical."
CA/Browser Forum's Baseline Requirements v1.6.3 has opinions regarding root EKU (don't have them) and intermediate EKU (if needed, SHOULD be non-critical); but on end-entity (or "subscriber" in their terminology) EKU it has no opinion regarding criticality.
For timestamp authorities RFC 3161 says "This extension MUST be critical."

So, critical EKUs exist, but it's not common to have critical EKU for a TLS Server or TLS Client certificate.


Is it possible to store a user's third-party private API key securely?

It is not certain that there is a 100% secure solution to any static-secret problem (that's what you're describing btw). Also, there is always a trust relationship between your users and your service. You certainly don't want to be storing your user's secrets -- use it and discard it immediately is a good model.
All risks must be properly assessed, according to impact, likelihood, etc. For example, I use the excellent service, OctoTree, with GitHub. I have given them an access key to my account. I trust them because I don't have any private repos (and therefore the impact of disclosure is low), and it doesn't profit them to misuse or disclose this information. For me the risk is low so I give access to OctoTree. Your users will have to make the same assessment with you.
Btw: having a private key in a URL, as suggested by your post, is totally insecure anyway, so you don't have to worry about security on your end.
If you must store someone's key, use Hashicorp Vault's kv store. If you can run it, then it's the most secure you're likely to get.


It depends on the app, of course, but most (citation needed) major apps use HTTPS.

Facebook talks about this specifically:

  ... virtually all traffic to www.facebook.com and 80% of traffic to
  m.facebook.com uses a secure connection. Our native apps for Android
  and iOS have long used https as well.

It is still possible that the TLS connection could be broken by MITM, but there is a process called Certificate Pinning that helps to prevent that. Fewer apps have this turned on. In the quote from Facebook above, which was in 2013, they said:

  We're actively testing pinning in Facebook mobile apps and plan to use
  it in browsers as well.

So, is it possible that your app credentials could be sniffed from the network? Yes. But many apps use TLS and Certificate Pinning to make this unlikely. You need to investigate each app to determine what they use.


Why superuser or administrator account should never locked?

Most of the time it does get blocked. Not in the sense of blocking off the account, but blocking the IP that tried to connect.

I use OSSEC. If someone tries to log in on ANY account wrongly more than 5 times, the connecting IP will be blocked and I will get an email containing what IP tried to log in.

To prevent from locking yourself out you can whitelist some IP's that will never get blocked.


Why would Keepass2 decrease the password quality after adding another character?

I haven't reviewed keepass2 source code, but entropy calculations are very dependent on the model used.  My guess is your change, causes keepass2 to jump between different models for how its doing the underlying calculation.  Any entropy calculation for a given password is necessarily inexact if the method that generated the password is not being used.

For example a very naive way to model a given password like P@s$w0rd would be assumed to be assume this was 8 random characters chosen with from a set 96 possible printable ASCII characters, with an entropy of lg(96^8) ~ 52.7 bits -- a somewhat reasonable password (against online attacks or against a hash like bcrypt with suitable number of rounds).  Randomly choosing 8 characters from printable ASCII is as likely to produce P@s$w0rd as any other password (even ones that look random 9MD10]'e)..

However, you can really see that there's an lower-entropy way to generate this password.  It's based off a very common base word (password) -- slightly modified with on average maybe four ~4 possible mutations (4 = 2^2 so 2 bits) for each letter.  So by being one of the say 1000 most popular base-words (10-bits of entropy) plus 2 bits for each letter, so a total of about 26 bits of entropy -- which is very weak.

Therefore, some password calculators will search for recognizable patterns to discount for this effect.  They may recognize a pattern in a longer password or a password with a larger character set, that they did not recognize earlier.  E.g., they may not realize that d@s$w0rd is based off of password (with a repeating d being a rotated p and not using any capital letters) and may give it a higher score than P@s$w0rd.


Should I obfuscate passwords before hashing?  Should I pre-hash them on the client?  What about salts?

Q1: "obfuscating" the password buys you nothing here, in terms of security; it just makes the code more complex, which is a bad idea.

Q1a: The hash of the password is "password-equivalent": presenting it is enough to get authenticated. So hashing changes nothing to security: this is equivalent to exchanging the password in cleartext. For security, you really want to use SSL -- you will not get much security without it. Actually you can forget all about crypt() and Blowfish and the "15" iteration count until you have enabled SSL: the lack of SSL is a much wider security issue. crypt() with Blowfish is very good, but using it without a SSL-protected password transfer is like putting a steel padlock on a tent flap.

Q2: The point of the salt is to be unique per password instance; a big enough random salt ensures such uniqueness "probabilistically". So you change the salt whenever you create and change a password (i.e. when you add a new user account, or when a user changes his password). There is no need to re-salt a password which does not change.


Do 2FA sites leak info by confirming a correct password guess?

If I'm understanding your question properly, the attack you are proposing is to brute-force passwords against a server like this, then once it shows you the MFA screen, go try that password on other websites that this user has accounts on.
This is a great question! Good find! But you seem to be overlooking two points:

This is no weaker than not having MFA, which also confirms the correct password ... by letting you in.

No hacker in their right mind will try brute-forcing a password against a live server which typically rate-limits you to like 5 guesses per second. Or in the case of the big providers like GMail or Outlook, have complex fraud-detection systems that do auto IP-blocking of suspicious activity. 99.999...% of the time, password brute-forcing is done against password hashes stolen directly from the database on which you can guess (m|b)illions of passwords per second.

So while I agree with you that there is the potential for some data leakage here, I think the risk is minimal, and far outweighed by the user inconvenience of having to fumble with their OTP fob just to find out that they typo'd their password.

Update addressing comments since this has become a hot network question:
There are two types of Multi-factor authentication (aka "2FA" or "MFA") that really need to be thought about separately:

SMS or Push Notification 2FA: when you get to the 2FA screen it sends a code to your device that you have to type in. For many users, this is probably the only type of 2FA that you've been exposed to. The attack described in the question will not work in this case because the user will receive a 2FA code they did not request and they'll know something's wrong.
Moreover, doing the 2FA step regardless if the password is correct is actually harmful it this case because:

An attacker could potentially cause the user to get a huge monthly data / SMS bill, or crash their device by filling its memory with notifications.
It also leaks which users have 2FA enabled, and which are easy targets.

"Offline" 2FA using code-generator tokens, apps, or public-key enabled smart cards / USB sticks. This is the kind of 2FA that government, military, and corporations use. So while it's less visible to end-users, it's by far the more important type of 2FA because of the value of the data it's protecting. In this case, there is no "built-in" notification to the user when an attacker gets to their 2FA screen. And usually all users are required to use 2FA, so there's no harm in leaking which user have 2FA enabled, because it's all of them.

Imagine this scenario for Case 2: a corporate VPN that sits on top of the Windows Active Directory. Public-facing VPNs get hammered on all day long by password guessers, so there's nothing unusual about those logs. But if I can have the user's password confirmed by the VPN's 2FA screen, then I can walk up to their laptop and log in confident that it will not lock out the Windows account - which would certainly get noticed by the user / IT. The question correctly points out a security hole that the pattern of "got to the 2FA screen and entered nothing / entered something incorrect" should certainly be flagged as more severe than your standard "incorrect username/password" and should notify the end-user to retire their password.


The threat depends on who your adversary is and the way the firmware is protected.

Case A: Signed Firmware:

Some people have more resources for example if the threat is from government based malware (who may be able to coerce the manufacturer to hand over signing keys) then it's a more serious threat then if you are concerned about some random malware developer. The threat still exists but on a smaller scale.

Case B: Write Protect Screw:

Some motherboards have a "write-protect" screw that you must remove before the firmware can be adjusted. While this doesn't provide the same type of security it does ensure that you can't be attacked except during a timeframe you know about. That being said you'll have to know Thow to inspect your motherboard for a removed write-protect screw.

On the subject of mitigating an attack:

I would take the advice in the comments and require that all future updates are signed. For past attacks though your best case would be to manually flash a new safe copy of the firmware through another device. (It'd be a nice hands on activity however I'm not able to provide assistance nor instructions on this type of activity as I do not have the experience to do so).

Severity of the threat:

The threat is difficult to remove however it's a very targeted attack and since there are so many different types of computers the attacks have to be extreamly targeted and are out of reach for most malware developers. If a large group got together with a lot of funds they might be able to mass target multiple computer users but it'd be an extreamly expensive attack to pull off and it wouldn't make enough of a payout to justify the initial cost of doing so. It's easier and by far cheaper to mass target a specific vuln and keep attack new users.

Please leave a comment on my answer if you have any questions about my answer and/or need further clarification on anything :)


How dangerous is an unsecured printer to a network?

Securing a printer with a password might not necessarily help at all. Some printers may be reset to factory defaults via SNMP over the network or SNMP commands embedded in print jobs. Some printers even might provide back doors(1, 2).

Some printers have universal computing capabilities (PostScript, Java) and services that can be accessed over the network. This may give rise to vulnerabilities that affect the network itself, e.g. cross-site printing, print job manipulation, or file system access. For an overview you might read Jens Müller, Vladislav Mladenov, Juraj Somorovsky, SoK: Exploiting Network Printers.

(1) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0788
(2) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2012-4964
(3) https://www.nds.rub.de/research/publications/sok-exploiting-network-printers/


Smartcards and Openssh

The point of the smartcard is that you cannot extract the private key for the keypair generated but that the public key is generally accessible.

For *nix you should install opensc (github.com/OpenSC) toools.  On ubuntu:

$ sudo apt-get install opensc
$ sudo apt-get install opensc-pkcs11

Additional packages that you may find useful include OpenSSL (for engine-pkcs11.so installed above -- but not required for this process).

Back to the main question involving ssh and smartcards:

Taking ssh as the example, a 2048 byte RSA key generated on the card, you must put the public key on the remote hosts.  Then when you ssh to the remote hosts from you desktop (on the desktop: smart card reader with smart card inserted) you will be prompted to enter your pin to unlock the card.

Extract the Public Key

On my test HSPD-12/PIV the first key slot is the authentication key and the second is the signature key. I will use the opensc-tools to extract the public key.

# note:  use 'lsusb' to see if you can see your card reader, if not fix it.

$ pkcs15-tool --read-certificate 2 --out my_key.pub

On your remote hosts put the contents of my_key.pub into your ~/.ssh/authorized_keys2 file in the same way you add other public keys.

Openssh example:

    $ ssh -I /usr/lib/opensc-pkcs11.so martin@remotehost
    Enter PIN for 'MARTIN PALJAK (PIN1)':
    martin@remotehost:~$

The above was taken from the OpenSC project wiki:  https://github.com/OpenSC/OpenSC/wiki/OpenSSH-and-smart-cards-PKCS%2311

uDude


Malware - are removal tools acceptable or is bare metal re-install the only safe option?

It actually depends a lot on the malware in question as to whether a removal tool is in fact a really feasible option. Whether said tool works or not depends on how much the author of the tool knew about the original malware and what it did.

To illustrate my point, take a look at something like Autoruns. There are a whole slew of ways to get your chosen executable to run on windows startup which autotools mostly displays, but only two of those are standard choices for the average software engineer. Malware authors can easily use many of the other areas, or even multiple areas, to become much more persistent across reboots.

Next up is the damage you can to the windows registry. For example, the handling of .exe files is in fact denoted by a registry entry, so there's an attack point with which I could damage your system if you undid it naively. Likewise for other common extensions such as word documents. The question becomes, does the removal tool author know what these values were  prior to the viral infection? Does the tool even detect these changes? I could easily hide a re-install malware executable in such a route, triggered by say a plugin load into internet explorer, or such like.

Next up is the most difficult to recover from - what if said virus starts trampling all over various files you own? It's entirely possible it could patch parts of windows this way, or your user data and programs, storing copies of itself, which means you'd have to know it did this and search for the damaged files, or else scan all files for the payload. Which gets even harder if it is self modifying. If any of these payloads are triggered, a re-install is a likely behaviour.

The final case is the old rootkit, which could hide the infection from the cleaning program. You can go some way to detecting rootkits if you try hard, but it is significantly non-trivial.

I should also point out at this stage that websites offering to clean/disinfect your computer are a great attack vector for any malware author. Emails introducing yourself as Mr So and So with £850,000 USD they just happen to want to give away are pretty obviously frauds to most people, but the computer says "alert, you have a virus" in a way that looks legitimate to your average home user and before you know it, they've installed said "product". They don't necessarily have the technical expertise to realise the scam here.

I do not trust said cleaning tools or services unless they come from reputable vendors.

The insurance industry employs the term "write-off" when the cost of repairing or fixing something is greater than the cost of replacing it. In my mind, undoing the damage to an operating system a "good" (as in, highly effective) piece of malware can do is probably not worth the time and effort it takes unless you are (very) determined to learn about the infection and the behaviour of the malware. So I would write off the install in all likeliness.

That said, some malware is fairly simple and does not impact the system as badly as it could. In which case, a removal tool might well be all it takes to clean it. The problem is knowing that it is in fact just a simple piece of malware.

Further update: Based on this.josh's comment - a lot of malware I personally have seen has not been so advanced as to be incredibly difficult to remove. However, a common trend I have seen on infected PCs is for the PC to be infected with multiple pieces of malware, all doing different things. Often, a single initial infection seems often to be built entirely to do this. Tracking all of those pieces down and deducing whether they're part of a whole, or separate entities and what variant they are is a time-consuming process which keeps full time malware analysts employed at varying reputable vendors. I personally therefore have two questions of "malware removal" tools you find:

Do their authors have the same level of experience in removing malware as the likes of Symantec, McAfee etc?
Have their authors had the same amount of time to analyse the malware? I know how to use disassembler tools, but I can tell you the process of working out what something does from disassembly is one that takes a lot of time to learn and time to do even if you're an expert. I know because I'm not that great at it.

I have a hard time believing what appear to be "silver bullet" solutions.

Obviously there is a caveat to this - reputable companies offering virus cleaners (which happens sometimes) are likely to work and unlikely to be malicious. It's about making a judgement call as to how much you trust the author of the tool and how sure you are they are who they say they are. I would say, however, that it is known that some malware is capable of disabling reputable anti-malware products (although it isn't common) and that prevention is pretty much always preferable to cure.

Compare it to being burgled, if you've ever had the misfortune to have that happen. Some things are obviously missing, like the TV. However, to give a full list of what is missing and out of place is very hard to do - did they take X, or did you just leave it at someone else's house? Or in the car? Where's Y? The same applies to malware - a full account of the damage done is hard, especially as, just like thieves, each piece of malware is different. Like thieves, malware has some common traits, like targeting autorun methods so that is what makes it obvious there's been an intrusion, but as I say, fully accounting for everything is hard.


From my knowledge WPA2 does this (encrypting the connection between client and router with a key different for each device)

WPA2 uses the authentification handshake to generate multiple keys. 2 of these are:

Temporal Key (TK) – Used to encrypt/decrypt Unicast data packets
Group Temporal Encryption Key

The first one is used to encrypt unicast connections like communication between client and router. The second one is used to encrypt multicast/broadcast messages.

In the case of the mitm attack the attacker persuades the victim to think he needs to send specific/all packets to his address. So the client encrypts the packets with a key the attacker is able to decrypt because the client thinks the attacker is the one he wants to talk to.

Think of it this way: all letterboxes in a city (wifi-network) can only be opened (decrypted) by the correct owner. You want to send secret data to your friend Joe who lives at Goodstreet 1. But you don't know that. So you ask the people of the city where he lives. Alice (also living in the city) convinces you that your friend lives at Badstreet 1. So you put your letter in the letterbox of Badstreet 1, Alice reads it/alters it and forwards it to Goodstreet 1. So even when the letterboxes are secure Alice managed a mitm-attack.

Edit: Professional routers/network equipment have countermessaures against things like ARP-poisoning to try prevent MITM-attacks.

Saying "So what's the point of encryption then? MITM renders it useless!" is not different than saying that a burglar alarm is useless in a public building or theft by a friend you invited to your house.


For the most part, the answer is yes. With conditions.
The specification for OTP systems in general doesn't give any particular recommendations for storage of shared secrets.
The HOTP specification provides a little more guidance in Management of Shared Secrets.

We also RECOMMEND storing the shared secrets securely, and more
specifically encrypting the shared secrets when stored using tamper-
resistant hardware encryption and exposing them only when required:
for example, the shared secret is decrypted when needed to verify an
HOTP value, and re-encrypted immediately to limit exposure in the RAM
for a short period of time.  The data store holding the shared
secrets MUST be in a secure area, to avoid as much as possible direct
attack on the validation system and secrets database.
Particularly, access to the shared secrets should be limited to
programs and processes required by the validation system only.  We
will not elaborate on the different security mechanisms to put in
place, but obviously, the protection of shared secrets is of the
uttermost importance.

The TOTP specification provides the following as requirement 7 (R7) of Algorithm Requirements.

The keys MAY be stored in a tamper-resistant device and SHOULD be
protected against unauthorized access and usage.

The same document then expands on this (regarding both serverside and clientside storage) in its Security Considerations section.

We also RECOMMEND storing the keys securely in the validation system,
and, more specifically, encrypting them using tamper-resistant
hardware encryption and exposing them only when required: for
example, the key is decrypted when needed to verify an OTP value, and
re-encrypted immediately to limit exposure in the RAM to a short
period of time.
The key store MUST be in a secure area, to avoid, as much as
possible, direct attack on the validation system and secrets
database.  Particularly, access to the key material should be limited
to programs and processes required by the validation system only.

There is no mention of the shared secret being separated from other credentials, either in the aforementioned specifications or in the OATH OTP MFA recommendations.
The reason for this is that, if your password manager meets the standards described above, then (as you intuit in your question) it's very unlikely than a successful attempt to steal your credentials would target the password manager itself. It's much more likely that your credentials might be stolen during transmission, such as by fooling you into typing your password into a bogus login page, or by somehow reading your authentication traffic.
OTP will protect you here. Even if an attacker were able to see everything you send with a login form, they would only get a single, transient code. The key does not get exposed when sending the password, and therefore your account is protected.
NB: It is not necessarily unreasonable to decide for yourself that you shouldn't keep shared secrets in the same vaults as their associated passwords.
The most rudimentary purpose of two-factor or multi-factor authentication is that a single breach would not be enough to compromise an account. For example, one of the earlier forms of 2FA is the PIN associated with ATM cards. If only the card gets stolen, your money is safe. If only the PIN gets stolen, your money is safe.
In this sense, storing your secret keys in the same vault as your password creates a single point of failure, militating the most rudimentary benefit of MFA. It is a very theoretical risk, given the extreme security requirements for the vault itself, but theoretically, the risk might become significant in certain threat models.


public hotspot: Tor vs Antivirus Safe area?

TL;DR: "Tor Browser plus being careful and ready" should be completely equivalent to "Safepay through BitDefender WiFi Premium protection".

In your scenario, both are per se equally secure. The data being sent on the air is encrypted, so connections to HTTPS sites without either Tor or BitDefender, and connections to plain HTTP sites with either of them, are all secure, even if protocol vulnerabilities must be considered (e.g. vulnerable HTTPS on some old web server).

But there is yet another possibility -- that the WiFi access point itself is malicious. In that case it can try and mount a MitM attack and try to take over your "view" of the Tor network, identifying itself as a safe node and running a virtual exit point. This requires significant computing power, but the AP could actually be an Intel Core i7 with a suitable WiFi network card for all you know. Both HTTPS and Tor connections would be vulnerable, even if you should see some sort of Certification Authority warning (unless, of course, the CA is backdoored - this would only be theoretically possible for government-level attackers, though).

In this second scenario, BitDefender would be more reliable (again, unless someone got to BitDefender) because their "WiFi protection" is actually a VPN to BitDefender's servers, and the Safepay browser directly interfaces with them with mutual authentication (this also for billing purposes - WiFi protection isn't free). An attacker might be easily able to impersonate a BitDefender customer to the server, but wouldn't be able to trick Safepay into believing that he possesses a valid BitDefender server certificate unless he does.


In Unix, everything is a file! Just use the partition with your encrypted data as the filename.
So if for example your encrypted partition is /dev/sdb3 just use

truecrack -t /dev/sdb3 -w passwords_file

But actually you only need the first 512 byte of the partition to crack the password! Just copy them to a file and use this file for truecrack or hashcat.

dd if=/dev/sdb3 of=~/header_sdb3 bs=512 count=1 conv=noerror,sync

Then you can use the file ~/header_sdb3 to crack the password!

If you need a complete step-by-step tutorial, try this


What may a attacker do when they gain have password to my wifi router

Assuming the attacker got your WiFi password but NOT your router administration password (they are not the same thing!), then it's unlikely the attacker can do anything to re-establish access to your network.
In theory they could have attacked devices on your network (such as your PC, phone, IoT/"Smart Home", or the router itself) to attempt to leave a "back door". How hard this would be depends on what devices you have on the network, how secure they are inherently against such attacks (phones are generally pretty good, IoT generally very bad), and whether you have given them strong passwords and other security configurations (home routers used to ship with a default password - often just "admin" - for example).
If the attacker got into the router - either because the password was guessable, because it wasn't configured to require one, or because they exploited a pre-auth vulnerability on it - then there's a lot they can do. They could turn on external (remote) management so they can get into it without being on your WiFi, through your Internet connection. They could create a second WiFi network (from the same router, with access to your local network and Internet) and hope you don't notice. They could turn off its firewall. They could potentially even set it to proxy all your Internet traffic through their own computer, on the Internet. What's more, those are just things that might be possible from the official admin interface, but most home routers are vulnerable to command injection attacks allowing an attacker to run arbitrary programs on them. Thus, the attacker could do all sorts of things, including installing a remotely-accessible back door in the router, intercepting all Internet and local traffic on your network, launching attacks against other devices, etc.
Similarly, depending on how secure your other devices on the network are, an attacker could potentially have done lots of other harm. For example, if you have file sharing enabled on your PC, they could potentially have read any files you shared, and maybe overwritten them; if they could overwrite an executable file then they could have arbitrary code running on your PC now.
Additionally, they could in theory have done some harm to you by abusing your Internet connection. For example, downloading pirated media (they don't care if you get sued or your ISP cuts your connection) or even doing criminal stuff like launching attacks on other sites or dealing in child porn or similar (they don't care if you get arrested; it's just cover for them).

Realistically, though, they were probably just somebody who wanted Internet access for, at worst, watching porn they don't want their dad to see in their own router logs, or something. They might have noticed any other devices that were advertising file shares or similar, maybe even tried some obvious password guesses (such as "the same as the WiFi password"; never reuse passwords) but the odds of them actually trying to leave backdoors or commit other crimes is pretty low.


Is it safe to post the output of Linux dig (DNS) commands?

If you are running dig on public DNS, then the output is the same for everyone, and Public.

But that does not mean that it is "safe". It is possible that you disclose an unsafe amount of info in the public DNS record. But, since it is public, it is already disclosed, and you are not adding more risk by posting it.


Metadata-free Email: How can SENDER directly, anonymously, and securely ask RECIPIENT’s mail provider to deliver a metadata-free email?

Nearly all mail servers in today's world are configured to throw out messages which fail to include that information.  The primary reason is simply to prevent spam.

The third best thing you could do is if your friend had their own mail server and you have an account on that server as well.  In this case your client would connect directly to their server and the transfer would be within that same machine.  However the mail server should also be configured to only allow secure connections (ssl/tls) as well.

The second best is to not use email at all but rather use a chat or voice type program that can establish a direct connection between your two machines using encryption with a pre-shared key that wasn't transmitted in the clear.  Of course, traffic monitoring would show that data was transferring between you and your friend even if the contents were hidden.

However, if you are truly paranoid, the best thing is to just talk to them in person by whispering directly in their ear... while in a room that is shielded from all outside means of snooping.  Then again you'd need assurances that your "friend" wasn't going to share the contents of the conversation with a third party AND for anyone actually watching your movements they would still be able to know you two met each other.


How viable is MITM interception of email, really?

There's a difference between confidentiality and authenticity.  Opportunistic TLS provides confidentiality against a passive MITM attack, but the NSA will create fake certificates.  So let's say there's a TLS connection from mail.verizon.com to mail.comcast.com.  Unless there's a certificate that asserts mail.comcast.com is run by Comcast, and unless mail.verizon checks that certificate was issued by a certificate authority it trusts, then the NSA could create a certificate for mail.comcast, intercept the connection, and everything would look ok to the mail servers.

So the answer is, it's completely viable, and it's not exaggerated.

See How to detect the NSA MITM attack on SSL?


Do any DNS registrars support multi factor authentication?

I'd say that this could definitely be a legitimate requirement.  Control over DNS records for a domain can give a lot of power to an attacker (adding new hosts in a domain for a phishing attack or even redirecting a comapanies home page), so protecting it from attack is important and as with all publicly accessible high-value services, using 2-factor auth is good thing to consider.

As to providers that support it DNSimple is one that does.


Ysoserial and Jenkins commons collection exploit - what can you do?

Just read on in the same article and you will find:

  This vulnerability is amazing. Runs in memory and isn’t going away anytime soon. Remote code execution in many many things including custom applications

So this vulnerability will allow remote execution as a non-privileged user in many cases. From there is is often possible to elevate the privileges, i.e. to super user and maybe to attack other machines in the internal network.

Of course this needs malicious user input. If you can guarantee that no such input is ever sent to the application then you are probably safe. You probably cannot guarantee it for public installations. You might think you can control it for internal installations but I would not count on it, because internal and external applications are usually both accessed by the same browser. And using CSRF , XSS or similar attacks an external site can harm an internal site by using the browser as a trampoline.

  What is possible to do?

This is also explained in the The Fix - Kind of... part of the post. In effect, you need to fix the relevant library, replace the library with a fixed on inside your application and roll out the application everywhere.


Why does Google consider Thunderbird not secure enough?

Thunderbird doesn't support two factor authentication, so Google has a means of generating a special credential set that can be used with Thunderbird. When configured in this way it works fine with Gmail, but I guess it is less secure than proper TFA.


How to implement the fix for Forward Secrecy on Debian Apache OpenSSL?

These are NOT lines:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

These are ciphers and should go inside the SSLCipherSuite in appropriate form.

Implementation:

First, make sure that there is no other SSLCipherSuite (except vhosts) that may override your new cipher suite settings. If there is, comment it.

Then, below the commented line or below SSLProtocol line paste your cipher suite. It should look for example like this:

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!DSS

Explanation:

the first is directive (SSLCipherSuite) for Apache server
ciphers (e.g. DHE-RSA-AES128-SHA256) or cipher groups (e.g. DSS) are separated by colon (:)
exclamation mark after a colon means that this cipher or group should be left out
plus after colon means that this cipher or group should go at the end

By the way, don´t use the cipher suite you mentioned in question. RC4 is obsolete and prohibited in TLS since over a year. (Thanks @Michael Kjörling)


I don't know of any bootloader that will allow you to change the selected OS based on password entered alone, I would say you would need to customise a bootloader to achieve this.

This link may be of interest to you also:
veracrypt

As may this previous Answer


Is this bash command vulnerable to code injection?

You added in a comment, that you care about breaking out of the command and not attacking netflash directly by supplying a specific malicious parameter.

The answer to this is no, you cannot break out of this construct. Bash understands that you are supplying a parameter and doesn't allow you to manipulate the statement itself. Bash would have to do an implicit string concatination at this point, which it does not do.

As you mentioned, if eval was used, exactly this kind of concatination would take place and it would be vulnerable. Without eval, it is safe.

There might of course be a vulnerability in netflash itself, that can be triggered by the supplied parameter, but I understood that this is out of scope of the question (and would require a deep dive into netflash).


How can citizens prevent government-led Internet blackouts?

Preventing government-led Internet blackouts is highly unlikely, since governments have very close ties to the telecom industry for a reason.

By the time Effects-Based Operations on that scale are in play, the likely outcome of a conflict is already decided. Voice communication would be of much more value, and that's a completely different question in my opinion.

To answer your question though, while satellite internet access as Thomas Pornin points out is possible, using dail-up connections over a land-lines or mobile phones to international access points that in turn connects to a encrypted channel would be the most likely solution. International dial-up numbers will only work with international calling service that's working and methods to pass the audio signal to the access point via the phone. Here's an example of instruction on how to connect, and a list of dail-up ISPs access points.

Ham radio users also might be of use, for example, Telecomix, a group of Europe-based Internet activists, were aiding Egyptian protesters for days.  They were trying to establish contact by amateur radio or shortwave, and then forward the audio signals from modems in Egypt to the Internet.


What is the best place to put my IDS network sensor?

It depends on what you want to do

If you want to see what threats are being aimed at your from the internet. You can put the IDS outside the firewall (assuming you've hardened it appropriately) and behind the router.
If you want to see what potentially malicious internal traffic you have inside your perimeter then monitoring from a point between the firewall and internal LAN is more appropriate.

Consider what traffic you want to examine, the find the relevant point in your network that the traffic HAS to flow through to get there.
Since Snort is a free IDS and hardware is fairly cheap, it may be possible for you to invest in more than one IDS.

I'd also recommend the following read from SANS about configuring and placing IDS's


Approach business(es) with security vulnerabilities

This all depends on what tools you used and how you actually found the vulnerability. Some places running a simple NMAP scan is legal, while other places it is not. If you ran more intrusive programs, then you leave this alone. Forget it. If you still feel obliged to tell them, then do so anonymously.

You have two options. Leave it alone. Just forget it. Probably the safest. Depending on how you yourself connected to the net, there is most likely something in their logs from your scan. For all you know the server is a honeypot.

If you choose to contact them then legal advice is exactly what you need, and consider that the odds are not on in your favor. If you feign ignorance then you won't seem very professional, and your move can also be viewed as an attempt to sell your services.

It all bounds down to which country you did this in, and if you take a look at the history from similar incidents, then you'll see that in some countries this often ends with a lawsuit.


Let's break it apart.  You have an encryption key:
YOUR_KEY
You use this to encrypt the data in your database:
ENCRYPTED_PII_DATA = AES(PII, YOUR_KEY)

You don't want your key stolen so you encrypt it with AWS KMS and it gets stored in your application as:
YOUR_KMS_ENCRYPTED_KEY
Therefore when your application launches it grabs YOUR_KMS_ENCRYPTED_KEY out of its own store and sends that to AWS KMS for decryption:
YOUR_KEY = KMS_DECRYPT(YOUR_KMS_ENCRYPTED_KEY)

Thus restoring the original YOUR_KEY which (presumably) you store in memory and use to decrypt all your PII as needed:
PII = AES_DECRYPT(ENCRYPTED_PII_DATA, YOUR_KEY)

So what happens when you ask AWS to rotate its master key?  In your case: nothing.  AWS KMS keeps all the old versions of its own encryption key around so that it can continue to decrypt any data it had previously encrypted.  Your application doesn't know anything about the rotation of course, so the next time your app launches it will grab YOUR_KMS_ENCRYPTED_KEY out of its store, send it off to AWS again, ask for it to be decrypted, and AWS will return YOUR_KEY just as it always has.  You will then be able to decrypt your data with YOUR_KEY just like you always did.  However rotation will give you another option.  After your app decrypts its key, it can go ahead and ask AWS KMS to re-encrypt it again:
YOUR_KMS_ENCRYPTED_KEY_V2 = KMS_ENCRYPT(YOUR_KEY)

This will return back a new encrypted version of YOUR_KEY which is encrypted using the new AWS master key.  However, this is still just an encrypted version of YOUR_KEY, and when you ask AWS KMS to decrypt it again, you'll still end up with YOUR_KEY.  As a result, from the perspective of your PII, your master key has never changed.  You will still be able to decrypt your PII just as you did before, since your key has never changed (just the encrypted version of it).
In other words, since you aren't using KMS to encrypt your PII, but instead are using it to encrypt the encryption key used for your PII, you aren't actually rotating the key used for your PII.  If you also wanted to rotate the key used to encrypt your PII then you would have to manage that process yourself, which would mean:

Generate YOUR_KEY_V2
Use YOUR_KEY to decrypt your PII
Re-encrypt your PII with YOUR_KEY_V2
Encrypt YOUR_KEY_V2 - YOUR_KEY_V2_KMS_ENCRYPTED = KMS_ENCRYPT(YOUR_KEY_V2)
Store YOUR_KEY_V2_KMS_ENCRYPTED and throw away YOUR_KMS_ENCRYPTED_KEY

(just make sure you do this in a way that you don't permanently lose access to data if any of the above steps are interrupted, which is probably the hard part)
Hopefully that was clear and answers your first question.  Your last question however:

Is it even necessary to rotate the data key? Or rotating master key
every year is sufficient.

Is unanswerable.  Only you can decide if it is necessary to rotate the data key.  Your company may have guidance about what kind of key rotations are necessary and when, but otherwise it's not like there is a law about this.  You have to decide for yourself what risks you are trying to protect against, the best way to mitigate those risks, and which steps are worth the effort.  As an example, rotating the KMS master key may provide some protection in the event that someone grabs an old key out of a stolen backup, but provides no protection in the event that someone manages to grab YOUR_KEY directly out of the running application.  In the latter case all PII would be accessible to anyone who stole YOUR_KEY.  The only way to protect against that would be by using AWS KMS to encrypt the PII directly, but of course doing that has monetary and performance costs.


Remove a privilege from a Windows admin account : good or useless idea?

On the whole, as long as Administrator has sufficient privileges to do his administration tasks, then he can more or less directly take full control of the machine. For instance, any user who can tap into kernel memory can alter the tables which define his own privileges, and give himself all possible privileges.

Removing a specific privilege may help only in the case that some malware runs on the machine and trips on the lack of privilege, even if putting it back would be easy. This assumes that installed malware is mindless. Moreover, if malware may break on the lack of SeImpersonatePrivilege, then non-malware software may equally break.

This is equivalent to putting a bear trap in your living room. A potential burglar, groping in the dark in search of your valuables and unaware of your cunning ambush, might trigger the trap and be incapacitated. However, this works only as long as burglars do not adapt: if too many people put bear traps in their living room, then burglars will learn to use a torchlight to see where they are walking. Moreover, no bear trap would change the disturbing fact that a burglar did enter your house, and can still enact considerable mischief without stepping into the living room. Finally, the trap may backfire: you could also inadvertently walk into your own trap.


Is CORS helping in anyway against Cross-Site Forgery?

I'll start my answer by saying that many people misunderstand the Same Origin Policy and what CORS brings to the table.
Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents CSRF. This is not the case. All the SOP does is prevent the response from being read by another domain (aka origin). This is irrelevant to whether a "classic" CSRF attack is successful or not.
By "classic" I'm referring to the types of request that were possible before CORS came about. That is, the types of request that can be sent via HTML forms as well as XHR (e.g. GET or POST without custom headers).
The only time the SOP comes into play with "classic" CSRF is to prevent any token from being read by a different domain.
Of course, now we have CORS and all sorts of cross-domain requests are possible such as PUT and DELETE, CORS does in fact protect against these by requiring a pre-flight. However, generally speaking CORS is not providing greater net benefit because the reason this functionality is available in the first place is due to CORS.
All CORS does is relax the SOP when it is active. It does not increase security (except perhaps allowing cross-domain resource sharing to be standardised and prevent developers from introducing flaws with something like JSONP), it simply allows some exceptions to take place. Some browsers with partial CORS support allow cross site XHR requests (e.g. IE 10 and earlier), however they do not allow custom headers to be appended. In CORS supported browsers the Origin header cannot be set, preventing an attacker from spoofing this.
I mentioned domains were different origins. Origins can also differ by port and protocol when talking about AJAX requests (not so much with cookies).
Finally, all of the above has nothing to do with forged requests coming directly from an attacker, for example with curl. Remember, the attacker needs to use the victim's browser for their attack. They need the browser to automatically send its cookies. This cannot be achieved by a direct curl request as this would only be authenticating the attacker in this type of attack scenario (the category known as "client-side attacks").
The benefit of CORS is that it allows your domain to allow reads from another trusted domain. So if you have http://data.example.org you can set response headers to allow http://site.example.com to make AJAX requests and retrieve data from your API.


Security risks of the following authentication flow

To determine if a certain design is "secure", one must refer to the threat model of the application (which should explain the risk appetite of Party A and Customer X).
But yes, depending on the relationship between Customer X & Party B, one can see at least three potential security threats:

Spoofing: with the client_id/client_secret pair, Party B can identify as Customer X. This could be totally intended/accepted by Customer X.
Repudiation: If Party B makes changes on behalf of Customer X, Customer X can't claim it wasn't them (or at least, for Party A, in theory, there isn't a way to clearly know)
Information disclosure: Party B can garner whatever sensitive information Party A keeps on Customer X

Having said that, usually, Party A has no way to restrict who Customer X shares their token with. This would usually be done through the Terms and Conditions of the service. An example that comes to mind are online budgeting apps that require access to bank accounts to track expenses, and that used to require the user's banking credentials. This is obviously against most (all?) banks' T&C, yet many users of said budgeting apps would pass on their credentials anyway.

A bit related, but a common approach that Party A could use, when trying to mitigate the risks above, is to treat Customer X as untrustworthy. This would mean, for example:

Not use the client_id/client_secret as the only auth factor, and require an additional 2FA
Clear the token as soon as the behavior of Customer X seems to have changed (either because they are connecting with a different IP/user-agent/etc.)


Next steps after exploiting blind SQL injection

It looks to me like you explored this one pretty well. But pentesting means enumeration, enumeration, enumeration. So if you want to go deeper you should also try to find out everything you can around other potential attack vectors. Web server paths and the like. Maybe you find an admin logon page. Can you fully enumerate the db? What about user tables and passwords?

That said, you wouldn't be the first one who can't turn a SQL injection vuln into a reverse shell. If you can fully enumerate the DB that is already a pretty significant breach of the target.


How secure is manually over writting files?

Different filesystems for different operating systems work differently. But no matter which filesystem you use, this is unlikely to overwrite the data.

One thing you need to understand about filesystems is that the friendly directory- and filenames are usually an abstraction for the human user. On the actual hardware, all the file data is one big lump of one's and zero's. In order to find a file, there is a file table which maps human-readable file paths to hard drive locations and lengths.

  I batch rename them 1-100.jpg, I then change the extension of all the files to .txt.

This will change their names in the file table, but not change any of the data.

  I then make 100 blank text files and over write the converted image files.

This will truncate the length of all the files in the file table to 0 bytes. There is no reason for the filesystem to overwrite the actual data. You will likely end up with lots of space marked as empty, but which still contains the image data until the filesystem needs the space for new files.

  I then split the 100 blank txt files and split them 50/50, renaming them both the same and over writing, then split to 25/25, rename and over write, till I get just one file. Then I just delete this file.

I am not really sure what you mean with that, but it sounds like something which would again just affect the file table entries but none of the actual data.

If you want the filesystem to actually overwrite the data and not just the filename, you usually need to replace the content of the file with new content of the same length and then save it under the same name. So the manual way to shred a file would be to open it with a text editor and replace the content with the same number of random keystrokes (you can use copy&paste if you like). This is of course very tedious, so you might want to use one of the many file shredding programs which are available for free.

Also be aware of the special intricacies of shredding files on solid-state-drives. Their wear leveling algorithms create another layer of indirection below the filesystem which the operating system is not aware of and might result in data not actually being overwritten on the hardware even when the filesystem tells the hardware to do exactly that.


Skip date check in Server certificate in Chrome

There is no way to disable the expiration check of a certificate. If there is a way to accept the certificate anyway depends on the use of explicit HSTS (via Strict-Transport-Security HTTP header) or implicit HSTS (i.e. specific domains like .dev) always require HTTPS. If HSTS is used a certificate which is considered invalid cannot be accepted.


Is 90 day expiration for unique URL too long?

Two problems with this question:

"is XYZ too long?" where "too long" is a qualitative, arbitrary value
Security through obscurity

Nobody can say for sure that X days is too long. If there's nothing at stake and none of this has any value, then X can be infinite and nobody will care.

If there's something at stake, or something of value, though, it depends, and that's where you should perform a risk and threat assessment.

You have a 90 day requirement over which a task may occur; your solution to enabling someone to perform that task is an unknown unique URL and no other protections.

A unique (but unknown except to the trusted party) URL is an example of security through obscurity.

The longer the lifetime, the more chance someone unauthorized will access the URL. The higher the payoff, the shorter that timeframe is likely to be and the larger the likelihood that an attacker will invest time, effort and money in breaking in (or getting someone to forward that URL to them).

Payoffs may include revenge for disgruntled employees/contractors; just because no dollar value is attached to something doesn't make it worthless to hack it (you mentioned reputational damage).

If trusting input is important, leakage of the secret (URL) could lead to erroneous, malicious or misleading information being entered.

So my $0.02 - if it's worth protecting, do a careful analysis on how trustable you expect your user population to be, or just stick with username and password authentication; use a unique URL for password recovery / mail account authentication.


Vulnerability testing without the use of exploits?

I would consider 2 possible approaches - I note that you are trying to verify an exploit for escalation of privilege exploiting a bug in the kernel.  For the sake of the experiment, I would ignore user space software even though this is probably a bad idea.

Approach #1 assuming that you may need access to data on the server in question, I would install a VM with the exact version of the Linux distro and kernel in question and try out your exploit.   The VM will effectively sandbox the server from the real host and if you do succeed in crashing the VM - no harm done.

Approach #2 assuming that there are no data dependencies - I would install a VM with the same distro and kernel on any other Linux box you might have in the shop and try out your exploit.

If this is an important machine and your organization has assets worth attacking I would not make any assumptions regarding patches becoming available and being applied before you were attacked.

OTOH - if the machine is not mission critical and the general state of the server farm security countermeasures is good (machines patched regularly, firewalls maintained properly) - I would reduce your level of concern and take the time in the lab


Are temporary blocks sufficient response to network probes?

Security, in all senses is a layered approach. Each defense you have is one more against the plethora of attacks that can be thrown at your network.
Automatically or permanantly banning IP addresses that are actively scanning you is fine, it provides a mild level of security in that those IP's will then be unable to attempt more advanced scanning techniques against your machines without changing IP's. With any luck, they'll believe you're offline altogether and just move on to the next target. Usually a block of a few days is more than enough.

Its important that you ensure your firewall is configured correctly and does not respond when it does not need to.

  A sophisticated attacker won't get caught by the firewall's probe
  detection, and will have other IPs in other netblocks available.

There are other solutions available like Intrusion Detection Systems (IDS's) that may be able to combat more sophisticated attackers if they are a worry.

  We would be better off blocking the probe as it occurs, before they
  have time to get a complete picture.

as a general rule, You should be dropping all traffic that does not match your inbound rules anyway. If the firewall then notices traffic that is attempting to scan your network, then add them to the blacklist (permanently or otherwise)

  Many of these are going to be dynamic IPs, which could later be
  reassigned to legitimate users who need to access our services. Over
  time, it will become increasingly unmanageable (the list is already
  quite large), and will pose more potential for disrupting legitimate
  communication.
  This is why it is reasonable to have the temporary blocks (for 'x' number of days) in place.

Best practices are to keep blocking (even if temporarily) any suspicious/hostile IP addresses. This obviously cannont be the only security you have in place so checking that your firewall rules are up-to-date and correct as well as investing in an IPS should be something worth thinking about.

Hope that helps.


More than three domains hosted on the same IP address

This is not a sign of a problem for your server.  There's an important detail here, which is:
104.27.182.86 is not your server.  That IP belongs to cloudflare.
Cloudflare provides a large number of services to websites and sits in between the public internet and a server.  Someone who uses Cloudflare doesn't point their DNS to their own server - they point their DNS to Cloudflare, and then point Cloudflare to their server.  As a result, millions of websites point to Cloudflare's IP addresses.  Because they service more websites than they have IP addresses, they often direct multiple websites to the same IP address.
Apparently you use Cloudflare, and so the DNS for your domain points to them, not to your own IP address.  When your Cloudflare account was setup, you (or whoever set it up) would have pointed Cloudflare to the actual IP address of your server.  You can confirm this in two ways:

Here is the list of IP addresses owned by Cloudflare.  If you are unfamiliar with CIDR notation, the line which says 104.16.0.0/12 is of interest to you, as it includes all IPs from 104.16.0.0 to 104.31.255.255.
AKA, 104.27.182.86 is owned by Cloudflare, not AWS.
If you check your Elastic IP in AWS, you'll see that it is something other than 104.27.182.86.  Only Cloudflare knows the actual IP of your server - this is one of the advantages it provides, and one of the reasons why people use it.  Cloudflare sits in the middle so that the person requesting to view your website never communicates directly with your server.  In this way, Cloudflare is able to protect your server from a wide variety of attacks.

Additional Notes
The above details should make it clear that this is not evidence that you have been compromised.  However, here are some more related details for future reference:

Shared hosting sites will have multiple domains served from one IP address.  However, to the best of my knowledge, AWS does not offer such services.  If you sign up for a VPS directly from AWS, you should expect to be the only one hosting any services on the given IP address
Therefore, if you discovered that the DNS for other domains was pointing to the IP address of your VPS on AWS, and confirmed that the sites in question are actually being hosted on that IP address, then yes this would be a sign that your site had been hacked.
Fortunately, 104.27.182.86 is not the IP address of your server :)


How to bypass PHP username and password check in this CTF challenge?

Since the script does not check that the user exists using some non-existing username with an empty password succeeds in my test:

 echo challenge('Foobar','') ? "MATCH\n":"nomatch\n";

 PHP Notice:  Undefined index: Foobar in ...
 MATCH


Is all metadata necessary for decryption included in a symmetrically encrypted GNU Privacy Guard message?

Yes, it is.

You can verify this easily by yourself by encrypting a file with gpg -c filename and then decrypting that file with the password you have specified. No further parameters are required.


How can I set up a VPN connection in Windows 10?

Integrated home routers typically provide no VPN services, so using Windows 10 or any other VPN client to connect to one will not work.  If the router has a VPN server, you would need to take very specific steps there to set it up before doing anything to the client computer.  After taking these steps, how to configure the computer would be obvious.  Questions about how to accomplish this would be best asked in a StackExchange about computers such as SuperUser (https://superuser.com/)

The more relevant question here is, why do you want to connect to your home router using VPN tunneling?  Is there a specific security goal?  Do you not trust WPA?  Forcing WPA2 with AES would help a lot...


Why does Portswigger's solution to the lab "SSRF with whitelist-based input filter" work?

As per the RFC 3986:-

  The userinfo subcomponent may consist of a user name and, optionally,
     scheme-specific information about how to gain authorization to access
     the resource.  The user information, if present, is followed by a
     commercial at-sign ("@") that delimits it from the host.

RFC3986 section-3.2.1


As designed, this makes your system significantly less secure.  That's because you've turned a token which authenticates an entire session and embedded it into a URL, where it is much more likely to be exposed, such as in browser history or in logs.  If that token is exposed, so is access to the entire user session.
What would be more secure is if you you created an authentication token that was restricted to that URL (say, by taking a hash of all of the remainder of the URL and embedding that in the token).  That would limit the scope of the exposure to access to that particular URL.
In addition, you should also make sure that either the JWT does not contain any identifiable information or that it is encrypted, so that if it is exposed, you haven't revealed potentially sensitive information about the user, and also you should limit it to the shortest possible timeframe possible to minimize the consequences of exposure.  These latter two options are best practices anyway, so you should consider adopting them regardless.
With those constraints, using some sort of authenticated URL isn't intrinsically insecure.  They're used with suitable constraints by many websites, including Amazon S3, and while putting the data in the header is better, using the authentication in the URL isn't bad.


Do SSD's offer significant performance boost for Scrypt?

Nope because you run it in memory not from the hard drive.

The only form of hash cracking I know so far which  uses a hard drive, are table lookups like Rainbowtables. Even in that case the benefit of an SSD is limited since it's read in sequentially. SSDs are good for random reads and writes.


What is the state of the art on reading keystrokes based on vision?

Any camera that is able to capture images at a good frame rate would make his password visible when the video is reproduced in slow motion.

As you say about passwords being matched in a wordlist, it would not be so effective, since passwords can be (and should be !) random strings mixed with numbers and other special chars.

But, even if some of them are not completely visible, you can use for example, in the case of a hash recovery, an attack called mask attack

Hashcat and john the ripper for example have this kind of attack implemented. It works as you giving a mask, for example:

potato?d?d?d?d

It means, try potato + ALL combinations of numbers (?d), from 0 to 9. Since there are 4 occurrences of ?d, it will try all from potato0000, to potato9999.


Automatic OCR Document Capture Security Risks

This is a good question for your vendor, although it may not be easy to get a helpful answer out of them.  This is really no different than asking, "We're running a website, and it accepts connections from the internet.  Is it possible that an attacker can send malicious code that allows them to execute code on the application server?"
Is it possible?
Of course.
Is it a practical risk?
Probably not but it's impossible for us to say.
The person best able to assess the likelihood of a vulnerability is a vendor.  You could also hire a professional to perform a security assessment or penetration test (with the vendor's permission, presumably).  No one here can tell you the likelihood of an actual issue though, anymore than you could tell me how easy it would be to break into my home.


How to generate a config file from a .csr using OpenSSL (or other)?

I also had this question, and tying a number of threads together, I cobbled together this bash script to create a config file:
for pem in $1 ; do
echo "[ req ]\ndefault_bits\t= 4096\ndistinguished_name\t= req_distinguished_name\nreq_extensions\t= req_ext\n[ req_distinguished_name ]" ;
IFS=","

    for att in `openssl x509 -in $pem -text -noout | grep Subject: | cut -d: -f2 ` ;

        do VALUE=`echo $att | cut -d= -f2-9 `;
            case $att in
              \ C=*) echo "countryName_default = $VALUE" ;;
              \ ST=*) echo "StateOrProvinceName_default = $VALUE" ;;
              \ L=*) echo "localityName_default = $VALUE";;
              \ O=*) echo "organizationName_default = $VALUE" ;;
              \ OU=*)  echo "organizationUnitName_default = $VALUE" ;;
              \ CN=*)  echo "commonName_default = $VALUE" ;;
        esac
    done

        openssl x509 -in $pem -text | grep -A1 Subject\ Alternative\ Name | tail -1 | xargs echo "[ req_ext ]\nsubjectAltName = "
done


Internal access to security sensitive data in a company

A lot of a correct answer for you will be up to the jurisdictions that you are subject to (laws, regulations, contracts with customers, etc.)

But, as for industry standard ways of dealing with access to customer data, you would need:

a ticketing system to record the request by customers for changes (and thereby, permission to access)
clear separation of duties for all parties to ensure that no one individual can by-pass controls
logging of all systems involved to trace the activity of the data access and also to show the state of the data before and after the access
independent internal auditing of all of the above to make sure it all happened according to plan

But, as I said, the details of all of these things will depend on the laws and regulations that you are subject to.


Are there other ways for a CA to have their certificates included in a browser?

Depends on the browser and the host OS, but it is usually possible to tell the OS or browser to trust a new CA.

For example, if you are using Internet Explorer or Chrome on Windows then you can import a certificate into the Windows "trusted root CA" certificate store and it will be trusted unless another certificate is pinned.  Firefox is more complicated.

As another example, you can install a new certificate on Android.  This should work for most or all browsers, but they might ask you to make an exception before trusting your new certificate.

Other operating systems and browsers have different mechanisms for certificate installation.


How does ASCII-Armoring help to prevent buffer-overflow attacks?

If the address is getting treated as a null terminated character string at some point, inclusion of this "ASCII-Armored" address would cause functions that work with null terminated character strings such as, strcpy, strlen, sprintf to stop processing at the end of the libc address.


What type of attack should be used in order to pass this authentication

You would be able to attack this with a buffer overflow, but it is not necessary. In order to get a buffer overflow exploit working you will need to perform dynamic analysis on the exe, using a tool such as OllyDBG. You would then run the program, passing it overlong strings until you get it to crash. The type of crash you are looking for is control over eip. Typically you would just pass a whole string of AAAAAA and check the CPU registers when the program crashes, if you see eip 0x41414141 or similar, you win and are just a few steps away from breaking the code.

However, I would attack this in a very different way. The password is stored in the exe file, but it is obfusticated - it is generated by multiplying and rotating a series of values such as 0x55555556 and 0x66666667. It then compares your password against the generated value, and branches one way or another depending on whether they match. All you need to do is subvert this branching condition. This can be achieved very easily with a hex-editor.

For a clue; the command you want to edit resides at 0x4013b3 (_main+58).


How to get public key if we know domain name?

use -showcerts for the full chain:

openssl s_client -connect www.host.com:443

public key:

openssl s_client -connect www.host.com:443 | openssl x509 -pubkey -noout


Two-factor verification without a mobile phone?

Several initiatives are ongoing to address this issue.  Google has been working with the YubiKey folks to create a tiny dedicated USB dongle device to act as a second factor.  You can see details here Forbes story here.  You can also use YubiKey today to kludge up a solution if you are so inclined.


If your infrastructure is tiny, much of the details of running a CA (e.g. CRLs and such) can probably be ignored. Instead, all you really have to worry about is signing certificates.

There's a multitude of tools out there that will manage this process for you. I even wrote one many years ago. But the one I recommend if you want something really simple is easy-rsa from the OpenVPN project. It's a very thin wrapper around the OpenSSL command-line tool. If you're going to be managing a LOT of certificates and actually dealing with revocation and stuff, you'll want a much more complex and feature-complete utility. There are more than enough suggestions already provided, so instead I'll just stick with the basics of what you're trying to accomplish.

But here's the basic procedure. I'll explain it with OpenSSL, but any system will do.

Start by creating your "root" CA -- it'll be a self-signed certificate. There are several ways to do this; this is one. We'll make ours a 10-year cert with a 2048-bit key. Tweak the numbers as appropriate. You mentioned you were worried about hashing algorithm, so I added -sha256 to ensure it's signed with something acceptable. I'm encrypting the key using AES-256, but that's optional. You'll be asked to fill out the certificate name and such; those details aren't particularly important for a root CA.

# First create the key (use 4096-bits if that's what floats your boat)
openssl genrsa -aes256 -out root.key 2048

# Then use that key to generate a self-signed cert
openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256

If you encrypted the key in the first step, you'll have to provide the password to use it in the second. Check your generated certificate to make sure that under "Basic Constraints" you see "CA: TRUE". That's really the only important bit you have to worry about:

openssl x509 -text < root.cer

Cool. OK, now let's sign a certificate. We'll need another key and this time a request. You'll get asked about your name and address again. What fields you fill in and what you supply is up to you and your application, but the field that matters most is the "Common Name". That's where you supply your hostname or login name or whatever this certificate is going to attest.

# Create new key
openssl genrsa -aes256 -out client1.key 2048

# Use that key to generate a request
openssl req -new -key client1.key -out client1.req

# Sign that request to generate a new cert
openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key  -sha256 -CAcreateserial

Note that this creates a file called root.srl to keep our serial numbers straight. The -CAcreateserial flag tells openssl to create this file, so you supply it for the first request you sign and then never again. And once again, you can see where to add the -sha256 argument.

This approach -- doing everything manually -- is in my opinion not the best idea. If you're running a sizable operation, then you'll probably want a tool that can keep track of all your certificates for you.

Instead, my point here was to show you that the output you want -- the certificates signed the way you want them -- is not dependent on the tools you use, but rather the options you provide to those tools. Most tools can output a wide variety of configurations, both strong and weak, and it's up to you to supply the numbers you deem appropriate. Outdated defaults are par for the course.


An IV is used to make sure that the same input (plain text) results in a different output (cipher text) even if the same encryption key is used - which can be guaranteed if a different IV is used all the time. The IV does not really be kept secret and insofar it is not comparable with the encryption key. But it should be as unpredictable as possible which means it should have uniform randomness (no IV is more probable than any other).


Could a VPN server hide all user's information?

A properly setup VPN hides information about the public IP address of the user, not more and in case of improperly setup VPN often less. It does not hide any cookies, browser history, hardware capabilities, internally used IP addresses or even the existence of internal systems which can be detected through various means. This means fingerprinting of the browser and of the environment it is running in it is still possible. Side-channel and timing based fingerprinting of the browsers state regarding for which sites HSTS information are stored, where the user is currently logged in and similar are also still possible.

But the most common leakage are probably still improperly configured or improperly designed VPN. A DNS based information leak happens for example if the locally used DNS server still points to some internal IP address (typically the home router) or in case of SOCKS proxies (which are not real VPN but often used for privacy)  when the client is not using the ability of SOCKS5 to resolve DNS but does it outside (default setting for Firefox). There are sites like dnsleaktest.com which help in detecting such a leak.

Another major problem is a missing support for IPv6 in some VPN. Thus if the network is connected with IPv6 and IPv6 capable sites are visited this traffic will completely bypass the VPN. There are sites like ipv6leak.com which help in detecting such a leak.


Are ordinary OS X desktops at risk from bash "shellshock" bug (CVE-2014-6271)?

Define "risk".

The core of this attack is to create an environment variable that looks like a Bash scripting function but ends with the invocation of a program, and then cause Bash to be run.  Bash will see the environment variable, parse it, and then keep parsing past the end of the function and run the program.

Any method of triggering Bash execution with at least one attacker-controlled environment variable will work.  Web server CGI attacks are getting the attention right now, but a user logging in over SSH could do it (a failed login, however, can't).  It's possible that some FTP servers could trigger it (say, through running a post-upload script).  A PackageMaker-based installer could trigger it, but if you're running a hostile installer, you've got bigger problems than this.  There are probably many other ways as well.

The average desktop user doing average desktop user activities is unlikely to have open attack vectors that could be used to trigger this bug, but Bash shows up in enough unexpected places that it's impossible to say for sure.


You can view the Network Vulnerability Tests (NVTs) here or here, the majority of these will be downloaded as .nasl files (Nessus Attack Scripting Language).

To see exactly what they test against or to edit them the simplest way to install OpenVAS and update it, then look at the code for each of the .nasl files in the filesystem.

By default these can be found at /var/lib/openvas/plugins


How do programs prevent data from being leaked?

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for example VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments;
BootArgsValid = TRUE;
burn (bootArguments, sizeof (*bootArguments));

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.

This is generally one of the problems in designing safe and secure programs, if you implement methods to prevent memory leaks you have to ensure there is no way to prevent them from getting called.


How to Combine RSA and AES for Steganography Project

I would say don't do it, it looks like someone else is already working on an openssl steganography implementation on github. If you are using pictures for your steganography they are sort of already a shared secret (if someone has the original picture they can see yours has modified LSBs) so you could pick an easier shared secret cryptosystem.


What factors increase the probability of duplicating a GUID?

I've seen GUID spoofers so... The concept is out there. I'm sure given time, a determined attacker would succeed in duplicating the GUID even against the new standard.

Perhaps, an alternative would to not based authentication on time, and place but, instead ensure that authentication is unique to the individual(not the machine/terminal). Secondly, that the data is completely encrypted from sender to receiver. PGP comes to mind but, once you start securing everything the network also has to be prepared to accept the added overhead.

Networks admins start complaining about right now, and then the executives see $$$ only, and decline or dilute the process so that it will get done,
"slowly but, surely..."

If you are preparing to present this I would suggest you show them they'll lose more $$$ in the long run being insecure then, they will if they are secured.
They love numbers no mater if its - or +. Its their language, like technical terms are ours. Research, what hackers are researching. In this instance Google will come in handy. Think like the attacker would have too for a second, and see where that takes you.

Hope it helps ;-)


Building a project on ARM Cortex-M, anything I can do to keep IP secure? Dealing with Chinese knockoffs and sick of it

"Burning chips with bad firmware." This can result in extremely serious consequences that might even jeopardize lives.

There is definition for this type of activity. It is called sabotage and can have very serious legal consequences.

You are essentially running a cyber attack on hardware by maliciously inserting corrupted firmware with the sole purpose of bricking the device.

This is a technique used by black hats to cause irreparable damage to targets they attack. There is a chance that you will be treated as a criminal and wind up doing jail time. You can also be sued in court for countless amounts in damages.

I would not advise this unless you want to open a colossal can of worms. People understand the need to protect IP but this type of sabotage not only crosses the line but literally jumps over it. It moves from the realm of simply protecting IP and into the realm of malice.

You seriously need to consider a different way to go about this issue without causing destruction to hardware.


Account information gathering on subnet device

Your questions are fun ^^

Start with nmap, look for cheatsheats; n0where.net has all kinds of fun stuff to read about.

Maybe follow up with metasploit, there is a another vuln scanner I used to use quite often...I'll have to do some digging but, had pretty good luck with it. Its been about a year since I've written a detailed security assessment so, I'm a little rusty.

Again low hanging fruit. If you can find some vulnerability that allows you to gain access, someone has probably already written a script that does most of the work for you. You just need to identify weak points of your target. Try some vulnhub targets at home (probably what you guys are using).

If there is a web server built into whatever image (I presume) you guys are attacking take all of the usable information you can from that. Like look for company directory page, index, something like that and create usernames from it. I would make a list of last name first initial and first initial last name. Same thing if there is an ftp server.

Read up on John.

Make yourself a password list and those usernames you created, put them in the password list. I would put the company name in there too.

Get yourself a user list off of the target system. Put those in the password list.

https://askubuntu.com/questions/410244/a-command-to-list-all-users-and-how-to-add-delete-modify-users

http://www.cyberciti.biz/faq/linux-list-users-command/

I wouldn't start out trying to crack passwords from the get go. It is a long process sometimes. Try to focus on vulnerabilities, privilege escalation, pivoting.

Hope that helps or at least points you in the right direction.


Why is security across a network "hard" to achieve?

Basically, it's hard because there are so many little things that can go wrong. Often these little things can almost completely undermine the security of a network when found and exploited. However, when designing these security systems, it's very easy to overlook a small detail that might cause a problem later. To make things even harder, attackers and constantly and actively exploring different way to break security systems, and there's a lot of financial intensive to do so.

This is why most security experts will tell you to use pre-made solutions, instead of inventing your own. Getting it right by yourself is very difficult to do, and the pre-made stuff is already somewhat "battle-tested" in the field. Note, that even when you use existing tools that are secure, you have to be careful to use them correctly or they will still be insecure (WEP is a great example of this. They took secure algorithms and implemented and combined them in incorrect ways.)


Are There Any Measurements for Web-Application Complexity That Positively Correlates to Num. Vulnerabilities?

Whenever we submit an offer for a penetration test we are facing the same question: How complex is the application? Complexity leads to additional attack surface, which leads to a lot of tests, which might lead to a lot of findings which require a lot of documentation. This effort has to be reflected within the offering.

To determine the possible complexity we discuss the application from different points of view:

Code

How many code files?
How many lines of code?
How many functions?
Centralized input validation?

Representation/Features

How many forms?
Authentication available?
Session handling available?
User initiated registration?
Password reset?
Captcha?
Database access?
File download?
File upload?
Mail sending?
etc.

It is not unusual that a customer can't answer these questions. Taking a look at the application allows to get a feeling for it. A crawler like Wget or the according Burp module might help to collect the desired data. A simple grep/find lets determine the forms and other aspects responsible for complexity very quickly. But this kind of blackbox analysis always comes with some uncertainty.


There is no DNS spoofing involved. The name given in the Received header is the name claimed by the sending MTA in the EHLO command during the SMTP dialog. From RFC 5321 section 4.4:

4.4.  Trace Information
... insert trace ("time stamp" or "Received")
information at the beginning of the message content ...
This line MUST be structured as follows:
o  The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.


Does flagging a file as read-only prevent a hash from changing?

There are two scenarios that would explain why your file can still be changed, despite it being write protected:

If you start your program (Excel) as a user who is allowed to change the permissions, most notably write permissions, of the file, then the program (Excel) could simply re-enable write permission without telling you. That's generally a bad idea, but maybe Excel is dumb. Libreoffice Calc asks whether you want to modify the write permission flag. I'd assume Excel would, too.
If your program DELETES the file and recreates a file with the same name, it will look as if the file changed, even though it was actually completely removed and replaced by a different file which just happens to look mostly identical. This is possible because deleting a file isn't prevented by denying write permission to the file.


Which CRL should an intermediate CA crlDistributionPoint contain?

Which CRL should the crlDistributionPoints contain to for the intermediate CA? The root CA's CRL or the intermediate CA's CRL?

The crlDistributionPoints must point to the CRL which will contain the revocation for the certificate itself. Thus in case of an intermediate CA this will probably be the CRL signed by the issuer CA, although it can be any other CA as long as a trust path can be constructed.

  Which CRL should the root CA contain, if any?

The root CA can not be revoked. Trust for the root CA is not established through certificates but because it is integrated as pre-trusted in the browser or OS. This means if the root CA gets corrupted it must be removed from the browser/OS without any kind of CRL mechanism.

  Should user or server certificates signed by the intermediate CA point to the intermediate CA's ...

Again, they should point to the CRL which will eventually contain the revocation record. Which CRL this is depends on how the revocation is implemented at the CA.

  where would a client look for a CRL to see if a given certificate has been revoked?....

The client looks into the possible revoked certificate and extracts the crlDistributionPoints from inside this certificate. Then it downloads the CRL from this point and checks if it contains the serial number of the certificate.


How do so many vulnerable IoT devices stay alive and online?

While attacking systems was kind of a fun sport in the past for some it is now mainly a business. Simply destroying systems has very low return of investment while still having a risk of getting charged for criminal activity.  It is much more lucrative and worth the risk instead to infiltrate a system and use it as base to attack and infiltrate more systems. Attackers even make sure that the original vulnerability gets closed so that other attackers cannot "steal" the system from them.

But there are also attacks which destroy systems. Only this is done not for fun but instead to cover the tracks and to massively harm the victim as done for example in the attack against Sony Pictures.


Find a stolen iphone that isn't activated

Your carrier has a history of the approximate location of the phone based on the cell towers it connects to.

Get in touch with the police and they will in turn contact the carrier to get the info from them.

If the person connected the iPhone to their own Wi-Fi you can also ask the police to obtain the connection logs from your online services still configured on that phone (e-mail, Facebook, etc). With the IP address of the Wi-Fi connection it'll be very easy for them to track down the owner of that particular Internet connection.


Client-Authentication during TLS/SSL and Replay-Attacks

I think you did not fully understand how client authentication works and the article you cite does it describe it only in a simplified way. To cite from this article:

  The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server.

The import part is that these are not random data generated by the client only but that part of the random data is generated by the client and another random data are generated by the server. Or to say it more correctly: the client signs all messages send and received so far with its certificate. These messages include among others also 256 bit random data generated by the client and another 256 bit random data generated by the the server.  See RFC 5246 (TLS 1.2) section 7.4.8 for the details.

  If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

Since the signature in the CertificateVerify message also depends on random data generated by the server a replay attack can only be done if the server would use the same random data in a handshake as in a handshake previously sniffed by the attacker. But this can only happen if the random generator in the server is severely broken or if the attacker is extremely lucky because the probability that the server uses exact the same 256 bit random number as in a previous handshake is nearly zero.


Does setting DNT make one a target to extra tracking?

I would say no.

This is from Wiki:

  "There are no legal or technological requirements for its use, when
  it's enabled by default on browsers. As such, websites and advertisers
  may either honour the request, or completely ignore it in cases where
  it's automatically set".

So if an organisation wanted to track you and DNT was set, they could just ignore it and carry on and track you anyway. Any respectable organisation that observed DNT would probably not engage in such behaviour.