TLS/SSL Certificate - Key usage and encryption

... how it proves anything about my identity to the webserver?

It does not. It only proves the identity of the server to you so that a man in the middle attack (where someone claims to be google.com) is not possible.
If client identification is required (usually not) client certificates could be used.

"The certificate is intended... Proves your identity" does not mean that the certificate is actually used for this purposes. It only means that the certificate can be used for server authentication ("identity of a remote computer") and for client authentication ("your identity"). But in this case it is only used for server authentication.

Actually "your identity" is in fact confusing because it does not mean your identity at all. What this means is that if you would own this certificate (which you don't) then you could use it as a client certificate to prove your identity. Other certificate viewers (Chrome on Linux) show this Extended Key Usage in a less confusing way:

 TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)
 TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)

  Also I'm wondering why there is no "Key Encipherment" or "Key Agreement" purpose for this certificate? Is the 2048 bit RSA key (visible under the details tab) used for encryption?

The certificate I get for google.com with Chrome has no RSA key but is an ECDSA certificate with a 256 bit key. But with some changes to the cipher preferences I can also get the 2048 bit RSA certificate.

According to Which key usages are required by each key exchange method? it needs digitalSignature in the ECDSA certificate and it has this. According to this Q&A it would also need "Key Encipherment" for ciphers like AES128-SHA (which google supports). But the 2048 bit certificate is missing key usage completely so in this case we refer to RFC 5280: 4.2.1.12.  Extended Key Usage:

  This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension.

Thus if no key usage is given but extended key usage we can imply the key usage from this. And in the same section of the RFC it then states that serverAuth implies digitalSignature, keyEncipherment or keyAgreement. Therefore we have the required keyEncipherment even if it was not explicitely given.

Apart from that neither RSA nor ECDSA keys are used for the encryption of the connection itself, only for authentication and with the ciphers inside the key exchange. Encryption of the traffic is done with symmetric encryption using a key created within the key exchange. See How does SSL/TLS work? for more details.


Why is cross site scripting in URL dangerious if I don't use cookies?

There are a lot of other dangers from XSS, not just stealing cookies. Your page could be defaced, data which is secured (for instance with ip-protection) can be stolen or it even can be used to do some time-based attacks on internal networks the attacked browser may be connected to.

So you definitely should have a look at the OWASP XSS Cheat Sheet to protect against things like these.


Poodle - possible to protocol downgrade if SSLv3 is disabled but still have SSLv3 ciphers enabled?

If your server does not support SSLv3, then it does not support SSLv3. "Protocol downgrade attacks" are methods to force a client and server to use a protocol version that they both support even though they both know at least one newer version that they would have wished to use, given the choice.

Anecdote: I am French. Back in 2005, I was walking in the streets of New York (5th avenue, I think); I was there for a congress. A few paces ahead of me, I see two tourists speaking together, and they speak in French. Two minutes and three blocks later, one of them notices me, and (crucially) that I was handling a map. So he resolves to ask me a question because they were a bit lost. He then talks to me in English. That's understandable: in New York, English is the "basic language". That guy knew two versions of the protocol (the English one and the French one) and obviously preferred the French one (since that was what he was using with his wife). Fortunately, I leveraged my previous knowledge (that he knew French) and we continued the conversation in French.

So that's it. A protocol downgrade attack is when you arrange for two French people to speak in English by preventing them from realizing that they both know French. However, that can happen only because they both agree to speak English. If one of them disables the "English" protocol (because he refuses to speak English, or simply does not know it, or knows only the utterly unintelligible Texan-accent variant of English), then of course they won't speak English at all, attack or no attack.


Global check of input/output of known hash functions

Hash ID is a new, open sourced, project trying to achieve exactly the thing that you are looking for:

http://code.google.com/p/hash-identifier/

Encryption formats supported:

ADLER-32
CRC-32
CRC-32B
CRC-16
CRC-16-CCITT
DES(Unix)
FCS-16
GHash-32-3
GHash-32-5
GOST R 34.11-94
Haval-160
Haval-192 110080 ,Haval-224 114080 ,Haval-256
Lineage II C4
Domain Cached Credentials
XOR-32
MD5(Half)
MD5(Middle)
MySQL
MD5(phpBB3)
MD5(Unix)
MD5(Wordpress)
MD5(APR)
Haval-128
MD2
MD4
MD5
MD5(HMAC(Wordpress))
NTLM
RAdmin v2.x
RipeMD-128
SNEFRU-128
Tiger-128
MySQL5 - SHA-1(SHA-1($pass))
MySQL 160bit - SHA-1(SHA-1($pass))
RipeMD-160
SHA-1
SHA-1(MaNGOS)
Tiger-160
Tiger-192
md5($pass.$salt) - Joomla
SHA-1(Django)
SHA-224
RipeMD-256
SNEFRU-256
md5($pass.$salt) - Joomla
SAM - (LM_hash:NT_hash)
SHA-256(Django)
RipeMD-320
SHA-384
SHA-256
SHA-384(Django)
SHA-512
Whirlpool
And more…

Enjoy!


How are ECDSA signatures computed for X509 Certificates?

The signature is computed over the tbsCertificate (To-Be-Signed) data.

https://tools.ietf.org/html/rfc5280#section-4.1:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

https://tools.ietf.org/html/rfc5280#section-4.1.1.3 says:

  The signatureValue field contains a digital signature computed upon
     the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
     tbsCertificate is used as the input to the signature function.  This
     signature value is encoded as a BIT STRING and included in the
     signature field.  The details of this process are specified for each
     of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

  By generating this signature, a CA certifies the validity of the
     information in the tbsCertificate field.  In particular, the CA
     certifies the binding between the public key material and the subject
     of the certificate.

So, the trivial version of what you got wrong is that you also need to exclude the leading 30 82 03 02.  And you didn't trim enough off of the end.  Namely, the 30 0A 06 ... part (the signature algorithm identifier).

But, using that already shown ASN/DER parsing, you see that the root SEQUENCE contains three children. The signature is over the first child only.


EICAR Virus Test maliciously used to delete logs?

No, it won't work this way.

Reading the documentation from EICAR we can see why:

  The first 68 characters is the known string. It may be optionally appended by any combination of whitespace characters with the total file length not exceeding 128 characters.

So, the file must start with the said string, and must not be larger than 128 bytes. All of your logs will probably start with a timestamp, and have more than 128 bytes on it.


How can I make sure that I have the correct root certificate in my browser?

At some point, you need to trust someone. Whether this is your browser maintainer who embedded the certificate or the website of the certificate authority that provides the root certificate.

For sure, if your trusted source is compromised, their is a risk of you being tricked.


Metasploit creating .ZIP files instead of .APK files?

The command is ok and apk file is created.

An apk file really is a zip file with the extension changed (as @Josef said in comments), so your problem is other. Maybe you have apk files associated in your O.S. to a program which usually open zip files and that's because you are thinking is a zip file but it is an apk file. Checkout that!

EDIT Look at this. Try to sign your file.


How do I secure Apache against the Bash Shellshock vulnerability?

Aside from CGI, one overlooked use of sh is in exec() calls, or through the use of system() and popen(), on most Linux systems this means bash. The exec() family of calls are often used with "/bin/sh -c" to provide various features like shell redirection, pipelines or even just argument expansion when invoking processes.

Apache uses exactly this (via APR, see the use of SHELL_PATH  in apr/threadproc/unix/proc.c) when you use piped logs, and also in other circumstances such as external output filters (via ExtFilterDefine), and processing of #exec cmd SSI includes. This behaviour almost certainly applies to many third party modules too.

The best steps to take to secure your web server:

patch or upgrade your bash package (if you do this yourself make sure there are no stray sh instances, check for sh in any manually set up chroots too)
run Apache in a chroot, use a minimal /bin/sh if and only if it is required:

in Apache httpd 2.2 switch from using "|" to "||" in piped logs, this removes the need for /bin/sh (available since Apache 2.2.12)
in Apache httpd 2.4 make sure you're not using "|$" in piped logs, this reverts to the httpd.2.2 behaviour. 2.4 supports | and ||, neither use /bin/sh

make sure the default CGI scripts are disabled, double check from the top-level Options (e.g. <Directory /> down for ExecCGI
consider mod_security if you're not already using it. Red Hat have provided some rules which can be used to log and clean up the environment in KB article 1212303.

You may also consider using "#!/bin/sh -p" in scripts, this forces bash into privileged mode, this prevents importing functions from the environment (along with other changes). This might help if you have vulnerable CGI scripts on a system, but no patch and no compiler. This might not work on Debian and derived systems, so check carefully.

(Also, if /bin/sh is bash, don't blindly replace it with something else, it might affect your startup scripts.)

Any application code that runs via CGI (other than bash scripts), or under Apache modules (Python and PHP in your case) may also play a part in this. If any variable can be sufficiently controlled by an attacker (URI-encoding may be a challenge), and if the application uses /bin/sh when invoking processes, and if those variables are preserved while doing so, then you might have a problem.

If you are running a contemporary Linux system, but you have not set up a chroot or some other container for apache, you should be able to use unshare and a bind mount to replace /bin/sh when starting Apache (or any other service).

unshare -m -- sh -c "mount --bind /usr/local/bin/bash /bin/sh &&
    /usr/local/apache2/bin/apachectl start"

The advantages to this are

less risk of breaking things, since you can selectively replace bash
you can log and audit attempts to invoke sh more easily

(What you cannot easily do with this is write a bash script as a wrapper to inspect and log suspicious variables, you'll need to use something else of course...)

If you're running auditd on Linux, you can easily watch the use of /bin/sh by adding a couple of rules to audit.rules and reloading:

-w /bin/sh                -p x
-w /bin/bash              -p x

(I need both, since sh is a symlink to bash)

Red Hat have published an alternate approach, a runtime "fix" which you can use with LD_PRELOAD, you can find that in the advisory. This could also be adapted to log dubious variables, if required. Given that there are currently questions over the completeness of the patches so far, this solution is probably a good short-term fix for Apache at least.

You can also find more general Apache hardening tips here: Apache Server Hardening


Any known protocol for establishing trust between an inherently untrustworthy source and a server without a 3rd party?

As usual, the problem is one of definition. Namely, what makes the device 'D' more "genuine" than a PC run by some ill-intentioned individual ? If you get down to it, you will say something like: device D is genuine because that's the true piece of tangible hardware, the accumulation of atoms which came out from the factory. This is fine as far as definition goes, but it does not map well to network configurations. From the point of view of the server S, there are only IP packets; zeros and ones; the server has no access whatsoever to the manifestation of the device in the physical world, but only to what it sends.

In the abstract world of networks, you are what you know. What allows a server S to recognize a remote device D as a "true device D" is that D can do things (i.e. compute things) that require some knowledge than only D possesses.

This means that you have mostly two ways out of your conundrum:

At some point in the building process where the device D is still on secure premises (e.g. in the factory), inject some secret key into the device. At that point, you can procedurally (with eye witnesses) make sure that only a true, genuine device will obtain such a secret key. The key can then be used later on by D to demonstrate that it is a real device.
Do the initial pairing between D and S under the physical control of a trusted (sworn) agent, who makes sure that the true device is used. In practice, the said agent would plug the device in his laptop computer, use some authentication mechanism to talk to S (as an authorized agent), and forward data in both directions.

I have seen (actually done) both kinds where devices were payment terminals, with a lot of money at stake, justifying the overhead of sworn agents. If your device is of the cheaper kind, then this overhead may unbearable to you. On the other hand, if you inject "sensitive information" in a cheap device, then maybe you are running to your doom: if the information is worthwhile, then some device owners will try to open it and extract the information. They do that for mere music and video files !


Convert CSR to self-signed x509 Certificate

Self-signed certificate means that the certificate is signed by itself. Since signing is done with the private key you need the private key which matches the public key in the certificate. This means that if you want to keep the public key from the CSR you also need the matching private key.


How likely is it that a video I downloaded is infected and contains a virus?

Any video format can weaponized if there is a vulnerability in the code responsible for parsing given file format.
You should keep your OS and media software up to date in order to minimalize possibility to be exploited.
Even if video is "infected", but your app is up to date, you should be safe. As long as malicious video file is not exploiting 0-day vulnerability.


What happens if the text editor I paste e.g. passwords in, sends everything to the developer?

Much of the phishing spam you receive is a link to malware that is attempting to install a malicious key logger on your computers.  Key logging is a highly profitable way to steal credentials, passwords, credit card numbers, etc., so the thieves are highly motivated to do this.

Can an attacker to create a malicious plug-in for your favorite editor that would perform some trivial but useful function, acting as a Trojan Horse, but underneath serving as a key logger?  That's not only possible, it's the bread-and-butter of typical attackers.  It seems the trick would be getting developers to install it, and finding a way to hide the malware and traffic so these tech-savvy users are unaware that their keystrokes are being recorded; however, people are people, and anyone can get phished.

Your question is if this is likely.  In the last few years there has been an increase in attackers attempting to break into code repositories, with the intent to implant malware hooks directly into application source code.  Krebs has at least one story that hints at this.  There is no reason to think this avenue of attack isn't still being explored.

So the standard advice applies to editor plugins as much as to any other application you might download: don't install software from untrustworthy repositories; don't fall for phishing attacks; compare the checksums before installing, etc.

Is the editor itself betraying you?  Again, make sure your editor came from an official repository or web site, and not simply from the first random link from google.


Are signature based antivirus or antimalware effective?

A signature-based detection system can't be the only solution, but it can be part of the solution. Indeed you'll find that a lot of the AV products that have behavioural detection and heuristic detection also still employ signature-based detection. It's simple, it's fast, the chances for false positives are very low. But the chances for false negatives are high, and you certainly fail against novel attacks.


segmentation fault at strcpy while perforforming a buffer overflow

Edit: I was able to replicate what you saw in a debugger at first. I set a breakpoint at strcpy, and trying to step over it would result in a segfault. However, if I set a breakpoint on the instruction after strcpy, I do not get the segfault until the end of main:

 → 0x56556239 <main+144>       lea    esp, [ecx-0x4]
   0x5655623c <main+147>       ret

So I suspect there is some oddity going on with the debugger in this case that gave a false assumption about where the crash was happening. It's clear now that it was overwriting the address that is eventually referenced here. I tried different sizes for the overflow, and eventually found one that got me a crash that bypassed this and gave control over EIP; a size of 268 seems to work.

Original Answer:
Considering that the segfault occurs during strcpy and you are thus unable to overwrite the return address, I think the problem may require a different approach. The presence of printf(buf); seems like this is supposed to be solved by exploiting a format string vulnerability. It may allow you to overwrite nearly any arbitrary address. If the stack address pointing to the saved return pointer is on the stack, you may be able gain control by writing to it.

I'm not exactly sure why the segfault is happening where it is, but I suspect the stack layout may simply be unfavorable for hijacking execution flow with a buffer overflow. It is "undefined behavior", after all.


Twitter.com in private browsing leaks data to normal browser. Other sites as well? Bug or feature?

This is not a feature in Twitter or the Chrome version you're using. It's either a bug in the browser or a misconfiguration on your side.

Please refrain from using non-standard and non-official browsers. Instead of using SRWare Iron (a fork of Chromium), you should use Chrome, which can be easily configured to reach your privacy goals.


Most attacks on salted hashes assume that the salt directly accompanies the hash, usually directly in the hash format itself, or in a "hash:salt" format.

If you know the plaintext and you're trying to figure out the salt, you can use methods like the ones in my answer here.

If you know neither the plaintext nor the salt, that's trickier. MDXfind can generate short salts for you and also accept wordlists as plain text, so if it's a short static salt shared among many passwords, you can discover the salt.

But out of the box, most tools aren't going to try to guess both the plaintext and the salt simultaneously unless you do something to explicitly make that happen.


Why does Google 2FA not display the correct location when behind proxy?

I have run into a similar issue with one of my personal VPSs.

When I browse through a SOCKS5 Proxy through my vps in LA my google home page thinks I am in Hong Kong.

After some googling, I figured out that its most likely just a error in someones GeoIP Database.

I would check https://www.google.com/search?q=what+is+my+ip against the ones listed in the 2fa logs ... but its most likely a non-issue


web app 3rd party JS dependency vulnerability management

This is a common issue for legacy systems and not only about JS Library.
Mainly it is a risk and needs to be analyzed, managed, accepted, and documented.
Analyzed
That depends on your risk management process. But mainly, identify the current vulnerabilities with real exploitations so you highlight the real risks for risk owners (the one who is going to accept it). Good to have a PoC.
Managed
Propose the workaround till the risk is remediated... for your case, CSP and other browser-based protection might be a good suggestion.
Accepted
Get acceptance from management (risk owner).
Documented
Document for tracking and follow-up purpose.


Forensics, evidence collection vs data acquisition

As far as I know evidence is generally defined as

Any information of probative value that is either stored or
transmitted in a digital form

Hence evidence is the information that can be used in the court of law to support your case.
When you acquire data from a source like logs or data files or images, you analyze it and find the if there is anything suspicious in there that will help your case in court. So when you ask

Imaging the RAM on a live system;
Retrieving logs from a running a webserver;

These are sources from where you acquire data to perform investigations. You look inside them and find something of credible value to help your case in court. If you find something that a malicious process was using the RAM then it becomes evidence. If you don't find anything in the log files you keep them in the case file regardless if it is of value or not. It's like real physical evidence. If blood stained bat with fingerprints is enough to prove the crime then there is no point presenting the footprint of a dog that you photographed during your visit to the crime scene just in case. These are technically the investigation team's property and is kept as evidence in their case file.
I hope you get the idea. :)


Security implications of using an algorithm to lengthen and salt passwords before using them?

I'd say that it doesn't add much. Base64 is just an encoding, it doesn't add any entropy to your password.

It's also quick to compute so it won't slow down a brute-force attack.

The only thing it can prevent is an attack against an universal rainbow table that didn't take into account the base64, but maybe some rainbow table out there did take this into account. It wouldn't be more complicated to compute that a standard rainbow table. The only good way to prevent a rainbow table attack is to use a salt.

Also, always assume that the salt is known. The purpose is to prevent rainbow tables not brute-force attack. The best way to prevent brute-force attack is to use a slow hashing process like bcrypt.


Starting out, where should I be looking for vulns? Big bounty sites vs. smaller projects?

The choice between projects with big bounty offerings and small projects with no budget at all is getting less and less important.  Projects like Google's Patch Reward program mean that even bugs in GCC can earn you money if you write a patch to fix the bug.

You can earn recognition for projects without bug reward programs.  As an example, a couple of Googlers started using their fuzzing framework to look for bugs in ffmpeg and now, two years later, they have had over 1,000 security bugs patched.  They chose ffmpeg because it had a history of security bugs, was easy to test and it was used by lots of people.  It also shows that you can spend a long, long time on a single project.

But in order to receive the right kind of recognition, the quality of your reports must be high.  Some people submit lots of reports and get lots of CVEs but vulnerability database maintainers hate seeing a new report come through because it's so much work to extract the truth from the report.

The best advice I can give for getting started is to find a project that you enjoy working on and know well that's written in a language you know well or has a class of bugs you know well (such as XSS or memory corruption).  That way all of your focus can be on learning the new tools and learning the vulnerability database process rather than learning a new project and programming language.

Finding a project with a history of security bugs is a good idea if you can manage it.  The theory is that although it has had a lot of bugs fixed already, there are many more left undiscovered because the developers are not good at secure coding practices.  Projects where the developers are good at secure coding just don't have as many security bugs to find.

Later, once you are well grounded in all of those new things might be a good time to expand into new languages and new projects.

I did just think of an interesting class of apps that fit several of the criteria above.  A new-ish phone app with an infinite number of inputs, an exponential growth curve and a history of security flaws that has just been purchased for exorbitant amounts of money by a large company with an existing bug bounty program.  Yep, WhatsApp.  Although any ridiculously popular phone app that performs network access would be a good candidate for fuzzing so Candy Crush Saga, Flappy Wings, Splashy Fish, Telegram, Threema, etc. are all good candidates.


Website is under attack, how to deal with the constant requests

Setup Fail2Ban, or it's equivalent, to automatically block the IP addresses scanning you. They may try again from other IP addresses but this will radically slow them down. It will also make their efforts more expensive labor-wise and in most cases, it will stop them quickly.

Fail2Ban is easy to setup quickly. Once you have more time look into tools like mod_security and integrate that into your Fail2Ban setup.


How Browsers prevents Malware and Phishing attacks

Safe Browsing API
Google offers Safe Browsing, which uses URL lists as well as heuristics:

Safe Browsing works in two ways to help protect you against phishing and malware. First, Google downloads a list of information to your browser about sites that may contain malicious software or engage in phishing. If the URL of the site you're on matches anything in the list, your browser will contact Google’s servers for more information to make a decision. If your computer then decides that you're visiting a risky site, it can warn you about it.
Second, Safe Browsing helps to protect you against targeted phishing attacks (sometimes called “spear phishing”), where a site may not already be known to Google so isn’t on the list of phishing sites. Chrome does this by analyzing the content on the site and warn you if it seems suspicious.

The Safe Browsing API is used by Chrome, Firefox, and Safari, but the effectiveness varies by implementation.

Microsoft
IE uses its own methods of protection (SmartScreen), but the process is very similar to Safe Browsing.
Effectiveness of each browser from various tests show vastly different results depending on the type of tests run.


Can I encrypt the packets that are sent to my router?

Is there a way to encrypt traffic to avoid MITM attacks?

Many! Almost every good method for this involves a public/private keypair. To ensure that you are corrected to the correct endpoint, you must know trust the other side's key. If you don't somehow verify the key on the other end of the connection, the value is very limited as an attack can substitute themselves during the connection setup.

As long as your endpoint is verified, you can make a safe connection from open WiFi at DEFCON and have a safe connection (so far as we know, but the researchers do like to play there). SSL, SSH, IPSEC... they all follow these rules.

Since you mentioned a secure connection to your router, there are two things to look at. The first is that if you're trying to protect against people who aren't authorized to connect to your network and you're wireless, WPA2 with a strong passphrase will keep you from associating with the wrong access point or them associating with your access point... as long as you have WiFi protected setup turned off, anyway.

The second thing is back to the "uniform" setup that should work even with mischief on your own network: a VPN. Enable an appropriate VPN (IPSEC or other; there are a few) on your router and connect to that when you come online.


Is it safe to deploy software without memory protections such as DEP/ASLR?

DEP/ASLR is just layer of security. It doesn't secure you against everything, and against any sophisticated attack in particular. Unlike @ConsideredHarmful thinks, DEP/ASLR being disabled alone isn't a vulnerability, as DEP/ASLR just adds a layer of complexity to an attack by randomising memory locations.

The security paradigm in general should be not to try to come up with a single "indestructible" layer of security, but instead apply as many of layers of security as possible, so if one layer is compromised, the other layers would protect. Just like democracy! With ASLR/DEP disabled, you make it easier for a potential attacker to attack, but this isn't the end of the world


Is this (explained in body) a possible attack vector when using haveibeenpwned API?

Every decision in Information Security revolves around managing risk. If you ask me whether your hypothetical threat can materialise in an actual attack vector, I would say that theoretically it is possible, but practically highly unlikely.

The risk of an account compromise as a result of your application's users choosing a weak (or breached) password upon registration is definitely more significant and, therefore, you should manage that risk by implementing the necessary countermeasure. Here, HIBP is one countermeasure (among others such as password complexity requirements, 2FA, etc.) which reduces that risk to tolerable levels, but some form of residual risk still remains because of various other threats, including the one you mentioned. Having said that, you can further reduce the residual risk by downloading the PwnedPassword file and load it on a local database within your network.


Each person should have their own key pair (obviously). Additionally you can utilize one keypair that signs all users' keys (corporate key). Users' keys should sign that corporate key and set owner trust to "full". That way all users that are signed by the corporate keys are automatically fully trusted.

You can also use trust signatures (gpg uses tsign command) if you want to expose this trust information outside or want to introduce more levels of company keys (like intermediate certificates).


How could we provide certainty to users that education material on phishing, isn't phishing itself?

You can try the following options:

Have someone trusted in the organization warn them that there will be a test that will target the organization.
This way if they see your message they know that it is a test and all is okay and it is not a sophisticated phishing scam.
Add your contact information regarding any questions and that way when they call you can explain to them the situation (You should place this in a visible place on the "You made a mistake" page so they can clearly see it).


A typical VPN client works like this: it connects to the server, and then it instructs the operating system to give him all packets which are to be sent to any address in a given set. For instance, let's assume that the VPN client advertises that it should handle all packets meant for 10.0.0.0/8 (i.e. all IP addresses which start with "10"). When the OS sees a packet which should go to address "u.v.w.x", it checks whether "u" is "10"; if yes, then it gives the packet to the VPN, which does its magic with it and forwards it, under heavy encryption/MAC/whatever to the server; otherwise, the packet is emitted "to the Internet" as the OS would have done without the VPN client.

Details on how this system is implemented depend on the VPN implementation (e.g. it may declare specific "routes"; or it could intercept all outgoing packets with firewalling rules and redirect the packets it is interested in;...).

If you have two VPN clients and their "advertised sets of addresses" do not overlap, then chances are that they will live together nicely at the IP level: each will grab the packets for its own virtual network, leaving the other packets untouched. However, they might also fight for the "interception resources" which may result in the first VPN client to be wholly deactivated.

On the other hand, if both VPN advertise overlapping sets of addresses, then trouble is pretty much guaranteed. If you are lucky, the second VPN will refuse to run with an explicit message. Otherwise, one of the clients may take precedence, possibly intermittently, and things will be weird and confusing. Possibly, one VPN server will receive the packets which were due for the other VPN, thus incurring a severe data leak.

There will be trouble with DNS. Applications and humans do not want to deal with IP addresses but with host names. The DNS converts host names to IP addresses. A VPN being a "virtual private network", it uses names which are not visible to the worldwide, Internet DNS. Therefore, a VPN client will not only intercept IP packets, but also the name resolution system, and redirect some (if not all) of name resolution requests to a dedicated DNS server on the VPN.

Your two VPN clients will compete for that redirection. Things might just work well if the clients manage to redirect requests for just some domains. But chances are that hijinks will ensue. Some names for one VPN will probably cease to be convertible to IP addresses, resulting in reduced functionality. Possibly, one VPN will receive name resolutions for the other VPN, so not only is the functionality broken (because the DNS in one VPN will not know what to do with names from the other VPN) but some private data leaks from one VPN to another (host names are rarely very sensitive, but that's still a leakage).

In this last situation, the VPN which receives name resolution requests for private names of the other VPN is in ideal position to respond with forged DNS answers and redirect all traffic from the other VPN to itself.

So don't do that. Running several VPN clients concurrently is a source of trouble, hard-to-diagnose failures and potential data leaks.

To avoid issues with multiple VPN, you should endeavour to use more "controlled" forms of VPN. For instance, a SOCKS proxy with ssh. This would allow you to run one Web browser which redirect all its traffic to another host (the "VPN server") while leaving the rest of the machine (and, crucially, other browser instances) unaltered. See this answer for instance. Some purists say that such proxying is not a VPN, but for many practical purposes (anything which is Web-based, really), this is functionally equivalent. See also the alternative with port-based tunnels.

I used to do that a lot at one time (a dozen or so port-based tunnels, and also SOCKS proxying, and it was all working well). The SOCKS solution works well for name resolution too: the name resolutions requests from the Web browser will go through the tunnel, to be resolved on the other side (i.e. in the VPN), without touching the local DNS configuration. Port-based tunnels require a static local name declaration.


Can someone identify this login screen? It ain't normal Windows 10 screen

It looks like HP Bloatware - I have seen screens similar to this on other HP laptops that utilise HP Security software and other features such as the laptop's fingerprint scanner.

Please see here for a similar scenario where the user enabled the HP settings and changed the logon screen: https://superuser.com/questions/690743/login-screen-changed-in-windows-8

  I use an HP Probook 4440s 64bit laptop with Windows 8 Enterprise installed. There is also a utility called HP Security Tools and I enabled a password protect option from it. Doing that somehow changed the normal Windows 8 lock screen to look something like this:

This was Pawan's solution (in case link becomes broken):

  Okay, found the solution myself. Posting it here for further
  reference.

  Once you activate the Spare Key protection, the Windows Logon checker
  is added to HP Protect Tools. So disabling the Spare Key doesnt take
  away the login screen, which is a result of added layer of protection.

  To bring back the old, normal login screen, open HP Client Security
  --> Credentials Manager --> Configure Now

  You will first need to remove the Spare Key protection, if any.

  Then, click on the "Administration" button on the bottom of the left
  sidebar. Administration --> Administration Console --> Increase System
  Security --> Uncheck the "Windows Logon security".

  And its done. That was all.

Sidenote: If it was a security breach on your computer and the attacker managed to load a custom logon screen, then you have a lot more to worry about than them getting your Windows logon credentials.


Will double encryption increase the security of cipher vs bruteforce?

First point: there is a practical security increase only if both encryption algorithms, taken alone, would be independently vulnerable to exhaustive search, i.e. by using too small a key. That is the main issue, and it is better to fix that. Exhaustive search works only up to the key sizes such that the space of key can be enumerated with existing or foreseeable technology. There are good reasons why a 128-bit key would resist such attempts. Thus, if you use a decent encryption algorithm, there is no need to "double" it. There is no security level beyond "cannot break it": you cannot not-break an algorithm more than "not at all".

Doubling or tripling algorithms has been used in older days to reuse previous algorithms which were definitely too weak on their own; the prime example is Triple-DES (aka "3DES"), built over the previous DES. DES and its 56-bit key space is vulnerable to exhaustive search (it has been done). As @CodesInChaos points out in his comment, doubling and tripling don't give you your money worth: double-DES would use 112-but keys, but would not offer 112-bit security.

In a nutshell, for double-DES, the attacker would encrypt the known plaintext with the first DES and all possible keys k1 (256 possibilities), and also decrypt the known ciphertext with all possible keys k2 (256 possibilities again), and then look for a match in the two sets of 256 "intermediate values". Matching will have cost about 2·56·256, i.e. about 263 (that's the cost of sorting the two sets, so that matches are detected with a linear search). With a merge sort, the sorting-and-matching steps only require linear access, thus compatible with hard disks. We are talking here about 257 128-bit values (two known plaintext blocks, so that there won't be ambiguity about the keys), aka 261 bytes, aka 2 millions of terabytes. One million hard disks is expensive... but technologically doable, contrary to a 2112 exhaustive key search.

Therefore, doubling algorithms does not bring that much of a benefit. Tripling increases security when beginning with weak algorithms (at least when the weakness is only about key size), but, there again, not as much as the invested effort (with 3DES, you have 168 bits of key, but resistance is "only" up to 2112). Of course, tripling also means dividing performance by three, which may or may not be tolerable in any given context. Tripling, quadrupling... does not fix other issues, such as blocks which are too small (3DES still uses the 64-bit blocks of DES, which means that serious issues arise when encrypting about 232 blocks worth of data with a given key, i.e. about 32 gigabytes, which is not much by today's standards).

It is much better to start with an encryption algorithm (like AES) which does not have exhaustive search issues to begin with, making doubling or tripling useless. Doubling (or tripling) algorithms is like a pegleg: it helps you keep upright if you had the misfortune of losing a leg; but, if possible, it is better to keep your two biological legs.


Google uses what are called cookies to do this. Nearly every website uses cookies of some form.

From Wikipedia:

  A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is a small piece of data sent from a website and stored in a user's web browser while the user is browsing that website. Every time the user loads the website, the browser sends the cookie back to the server to notify the website of the user's previous activity.1

Here's some information about Google's cookies: https://www.google.com/policies/technologies/types/


This is going to differ across industry, e.g., educational institutions have been implementing a lot of EDUCAUSE related frameworks/standards/guidelines which would differ from say a day trader who may follow FINRA which may not even allow for non employees to connect. Ultimately, a privacy officer along with an attorney should be tasked with drawing this up. If it were me, and I had to start it, I'd go with what government monitors (+1 if you quickly thought about the NSA)... and I'd go from there aiding the corp. attorney since ultimately, you want to be in the legal clear.


If you want to use regular drive electronics, the answer is, there's absolutely no way to recover the erased data blocks from flash storage like SSDs, USB sticks, SD cards, etc.
See https://www.silicon-power.com/blog/index.php/guides/nand-flash-memory-technology-basics/ for some info on how flash memory storage works.
The tricky part of securely erasing an SSD comes from knowing that the data blocks you want to erase, have actually been erased, and are not just in the garbage collection queue, or in the reserve space area, or in some other special SSD controller area of storage.
There is also the possibility of some data still in blocks that are left over on the bad block list, that the drive is unable to erase any more times and has remapped those addresses to still working areas.
Something a lot of people seem to ignore, is that the SSD controller is continuously trying to maximise the number of erased data blocks. This is to maximise the drive performance. If the OS tells the drive to delete and TRIM (or UNMAP) all of the usable data areas then, giving the drive has long enough to complete the task, it should also cycle through the reserved space too. If the drive has zero remapped or bad blocks, then 100% of your data is unrecoverable, even by data recovery businesses.


Alice wants to send the same public key twice, and Bob has to manually check that they match? Not sure about the practicality of this. If this was a regular thing, and I was Bob, I'd put the photo through an OCR* script to automatically do the checking. And if I was the hacker I'd write a script to automatically alter the public key and generate a corresponding photo. Overall, I think this is not secure.
* OCR: optical character recognition


Monitoring laptop activity while logged into school's Microsoft account

Logging in to a microsoft portal on a personal laptop that has no remote control software installed does not permit monitoring or control of any other activities outside the realm of the microsoft products being used with or without a VPN in place.

If, however, you have remote control software installed on your computer, whether it's been pushed by microsoft products (e.g. intune), then anything the software is capable of becomes available to the controlling party, regardless of you being on a VPN.


You can't. You'll need to detect the loader, and either mark all files containing the loader as virus, or detect where T and the encrypted area is and decrypt the encrypted area to check whether the encrypted area contains the virus you are looking for.


By law, faxes have to have the sender's phone number printed across the top. This is by law, not technical requirement, which means it's quite possible to not have that information, or at least not have it correct. Either way, you should have call records available from your phone company to help track the perpetrator.

Armed with that information, go file a police report (and assuming USA, an abuse report with the FCC), and then wait for the dream of justice that may or may not ever come.

You may also want to consider an electronic-only fax option. All-black TIFF files cost a lot less to produce, so the effect of such an attack is minimal. You could roll your own using the appropriate software and a fax modem, or you could subscribe to a commercial offering.


The "fingerprint" is a hash of the server's public key. It is not the public key itself; however, hash functions are so that it is not feasible to actually compute two public keys with the same fingerprint. Therefore, if you want to know whether you are talking to the right server (and not some impersonator), then you "just" need to compute the server's key fingerprint (from the public key that the server just sent to you) and compare it with a "reference fingerprint".

Fingerprints are used because they are small enough to be managed by humans: checking a fingerprint entails verifying 40 hexadecimal characters; that's not something that you want to do ten times a day, but it is feasible. When the SSH client presents the fingerprint, it has received the public key from the server, and noticed that this is a new server, never encountered by that client yet, and as such the server's public key cannot be compared with the known and expected value. The client thus computes the fingerprint, and displays it to the user, so that the user finishes the validation business.

You still need a "reference fingerprint" against which to compare that which is computed and printed by the client. You could, for instance, phone the expected server's sysadmin and ask him to spell out the fingerprint over the phone. That way, you can still connect to your main lab machines while you are on a trip to a conference two continents away, and using the laptop of another friendly researcher (because your own laptop broke when you dropped it while getting out of your plane).


Is it possible to become infected with virus, trojan or malware by browsing the infected sites or running installation .exe?

I suggest you check out https://en.wikipedia.org/wiki/Drive-by_download.  It is possible to exploit vulnerabilities (some known some unknown) in browsers or (more often) browser plugins to download (and sometimes execute) files without your knowledge (unless you know where to look). More often the adversary will try to get you to click on something masquerading as legitimate (as this is easier for him).

As for browser safety modern browsers use a number of tricks like sand-boxing to separate malicious code on the websites you visit from affecting you but nothing is foolproof.  Please don't use an old IE or any out of date browser or plugin (patch regularly).

Best thing you can do for yourself besides patching is don't go to dodgy websites and don't click random links you have no reason to trust.  If you have to go to a site that is suspicious do so in a clean virtual environment that has no sensitive data inside it.


I spent some time seriously digging into the Truecrypt/Veracrypt source code and studying the issued audit, and I would bet one of my testicles that the container format is secure.

A simple TC reimplementation exists at https://github.com/bwalex/tc-play. It uses standard Linux kernel device mapper for mounting the TC volume. It reads the volume header, derives the encryption key from your password/keyfiles and seed stored in the volume header and uses the key and linux dev-mapper to mount the volume container. It uses standard symmetric key encryption implemented in the Linux kernel. It's the pretty same code as is used by LUKS - Linux crypto. So, if LUKS is safe than TrueCrypt is safe as well.

The only difference (as mentioned) is key derivation. However, it uses just standard crypto-primitives.

The only question is, whether the particular True/Vera-crypt implementation is safe. I would bet my second testicle that the tc-play  is safe. It's short, and I was able to read it and understand it completely.

You can find even another reimplementation in linux cryptosetup. Many people have been thinking about TC security which could be nother proof.

However...

If you look at the VeraCrypt sources, you realize it contains thousands of lines of code and 99% of the code is GUI. The possible backdoor could be hidden anywhere, and it would be complicated to find it.

If you compare VeraCrypt code and TrueCrypt code, you realize that VeraCrypt maintainer hasn't added anything interesting. He hasn't even fixed the known bugs discovered by the tc-play developer and noted in README. For instance:

"The keyfile pool is not XOR'ed with the passphrase but modulo-256 summed."

This is a documentation bug, which hasn't beend fixed in the VeraCrypt docs yet.

https://www.veracrypt.fr/en/Keyfiles.html (8.)

To implement new crypto-algoritm (which Vera does) is a simple task. Knowing how, you can put any new algo. within 1 hour of coding.


Actually, the process is something like this. A customer would send an email to internal organization like opening an account or getting a loan etc. So, the organization would reply to the same email asking for sensitive information and necessary documents. When the outgoing email hits Forcepoint, it would encrypt and sends it to the customer outside of the organization. When the customer clicks on the link, it would prompt to create an account so, he/she can upload the necessary documents in the future. In this case, there is no client side validation for the first time because, there is no sensitive information sent from organization's end (atleast, thats the usual process). This allows customers to send documents. But, for the second email, he/she have to login to access the documents uploaded lastime and that's how it authenticates the user. Yes, anyone who received an email can create a login and access the email(which only requests for information) but, it doesn't contain any sensitive information.


Is my Google account only as secure as the recovery email?

Yes, or your recovery phone #.  There was a story recently about somebody convincing verizon to switch their phone number to a hacker's phone.   They used that to compromise the gmail address.

Fortunately, it's not always obvious what the recovery email or phone # is.


First off, let's be careful about language, when you talk about a public CA like Entrust, or Verisign, or Digicert, yes there is some software involved for actually creating and managing the certificates, but you're really talking about the people. These companies are trusted CAs not because of the software they use, but because their network admins take security seriously, because their verification specialists are meticulous about checking records before issuing a cert to a new organization (at least for EV certs). So at least 80% of what is means to be a CA is about the humans.

Right, now that that's out of the way, let's talk about the software.

You are talking about software tools to manage a Public Key Infrastructure. To be a CA, you only need 3 things in software:

A public key / private key pair.
A self-signed certificate for that key pair.
A software tool that can sign certificate signing requests (.csrs) with that key pair.

The other 80% is policies around how you manage the data, and how much background checking you do before actually signing a .csr. The difference between different PKI software is how many bells and whistles you get.

OpenSSL is just a command-line tool for doing crypto operations. Generally speaking, it's a bare-bones command-line tool: you put a file in, it gives a file back. What you do with those files is up to you.

openssl ca -cert ca.crt -keyfile ca.key -in infile.csr -out outfile.crt

It will fully support the X.509 standard, plus some basic services for issuing CRLs, responding to OCSP, etc, but the configuration and management will be pretty hand-on.

Something like EJBCA, Active Directory Certificate Services, or Entrust Authority Security Manager (shameless plug!) are a full-blown PKI management systems that run as live webservers, responding to requests, managing their own database, and storing the CA's private keys in a networked Hardware Security Module device. In particular, they come with nice web-based management interfaces (see screenshots below), they can do automated certificate management operations through the CMP protocol, they automatically publish Certificate Revocation Lists (CRLs) every couple of hours about all the certificates they have ever issued, they respond to online revocation checks (OCSP) - ie "hey CA, is cert #23488817 still good?" -, EJBCA and Entrust Security Manager can be used by governments to issue electronic passports, Microsoft's Active Directory Certificate Services and Entrust Security Manager (I'm not sure about EJBCA) have client software that runs on the client's desktop or laptop that will talk to the CA and automatically update the certificate when it's getting close to expiring, and a whole bunch more. See EJBCA's full feature list

TL;DR: OpenSSL technically contains everything you need to run and manage a CA, but it is fairly bare-bones, requiring you to do a fair amount manually on the command-line. I can't imagine managing a PKI of more than about 5 certs with OpenSSL. The fancier PKI products offer convenience by automating as much as possible and providing fancy web-based management UIs. They are designed for systems where you are managing millions of users - think of the public root CAs that issue the SSL certs for the whole internet, or that manage email S/MIME certs for a large government department, or that manage the certificates in a nation's passports. I would guess that 70% - 80% of the CAs in the world with more than 1 million users are running one of the three PKI softwares that I've mentioned here - Microsoft ADCS, EJBCA, or Entrust SM.

(source: ejbca.org)

(source: ejbca.org)


Testing Session Fixation when cookie is unchanged

For there to be a session fixation vulnerability, the server most somehow save some input that you (the attacker) can control as a value for the session ID. OWASP has a handy list:

Session token in the URL argument. (This is what you tried. But do note that the parameter could have any name, and you need to figure out what it is. It does not have to be SID.)
Session token in a hidden form field.
Session ID in a cookie. Since you can not set cookies cross domain, you need to some other vulnerability to exploit this, such as XSS or HTML injection (of a META tag).

If the server always sets a session ID on its own, without involving any user input in the process, this might very well not be exploitable.


AES encryption library that works on Javascript and Java

As long as you are performing encryption/decryption using the same cipher, mode, IV, and other parameters (which can depend on the mode, e.g., padding, associated data, tag-length) then any two libraries should be compatible.

You should test both the JavaScript and the Java libraries on known test-vectors to confirm both are working properly and to confirm that you know that all parameters are set correctly.

Here is a specific example of two crypto libraries that should be mutually consistent: The Stanford Javascript Crypto Library (https://crypto.stanford.edu/sjcl/) and the BouncyCastle Java library (https://www.bouncycastle.org/java.html).

I checked that the above libraries give consistent results for AES in CCM mode.

Update:

Below is an example of a test vector you could try. For this test I used the AES cipher and the CCM mode. I also used a "tag length" parameter of 64 bits and I used no "associated data."

Using the key:

b058d2931f46abb2a6062abcddf61d75

Using the Initialization Vector:

ed77b0e43daccec06c41f472

The plain text:

  849c27d7333fe9fb769725b0f29a6b0d977e504976d709b8b6ef542e455504a20243e9ff2ea72da8ab709f983f85349f0ccb63a3c3d70225b8c06305592487193b8599c4aeeecc513d9f71bce28fa0f3a9ba5b310fed302a360b73e7a546793f1dd7b17c1dfcb6348c1f2dfe86dab6

Encrypts to the cipher text:

  9f14fa396445bf0e206b123e090edf1c41c6ee6b85ec9963721075b9261006b83a68c3179e2824d45ad4a10e0cd44a66b9c4c12c57424a2dff701eac89d968a64b3b221864a163cc9425ee687bdb283c0b9931b5abde531a6e43737ddea7f715779a8ec15ff06808eb54f0e538c5ef4b4f224418c69b9b


How to compile java_atomicreferencearray (CVE-2012-0507) exploit to run calc.exe on system?

My java probably isn't any better than yours, but as I understand the vulnerability, it relies on breaking out of the sandbox to execute code.

I believe that when you replaced the php code with your simple command, you broke the part of the process to get outside the sandbox.

Here is a fairly detailed examination of your problem:
 https://media.blackhat.com/bh-us-12/Briefings/Oh/BH_US_12_Oh_Recent_Java_Exploitation_Trends_and_Malware_WP.pdf

Head to page 7 for a detailed explanation of how the exploit works, and the author steps through the code and its execution.


MySQL authentication, how to pad the 20-byte salt

The blog post at Portcullis security seems to be saying that you have to hash the 12-byte "salt" with SHA1 to turn it into a 20-byte string before prepending it to the hashed password.


UserName and Password information can be seen on https

OWASP ZAP is like a MITM proxy very similar to Burp suite.Ofcourse it can read the https because you must have installed a Root CA certificate while setting it up.There is nothing wrong with your website in regards to your question


Is there a way to tell what the file does before opening it?

What you are looking for is an approach called a "sandbox". It opens or runs the file in a safe bubble to see what it does and to look for malicious actions it might take.
There are many ways to do this and many tools to use. Virtual Machines can be used as a sandbox, there are online sandboxes, and there are tools you can install on your machine that can give you a lot of control.
It is also possible to "decompile" or inspect the file to get a lot of information about what it might do. This is known as "reverse engineering". This is not as complete as running it in a sandbox, but it can offer some detail before you run it.


CSRF protection for an email subscription website - are there any risks of having it turned off?

CSRF is only a threat when the request triggers some security-relevant action. If the request doesn't change anything or potentially expose any private data, it doesn't need CSRF protection. A POST request that just pre-populates a field isn't state-changing, if the user still needs to click "Confirm" before the server is updated. (Of course, the "Confirm" button would still need to have CSRF protection on it, though keep reading...)

Additionally, since the site is unauthenticated, CSRF protection probably isn't even needed. If there's no user-specific data or possible actions that aren't public to the whole world, then an attacker doesn't need to forge requests in somebody else's browser, because there's nothing the victim's browser can do that their own cannot. HOWEVER, if you are planning to add authentication, or if there's a "temporary session" thing where users enter some data that an attacker doesn't know, and the attacker wants to do something with that data other than what the user wants to do with it, then CSRF (and XSS) can still be threats.

Having CSRF protection disabled for specific requests is pretty common, though, when those requests don't change any persistent state or expose any data.


OAuth2 authorization - save token in the cookies or in the session?

Storing the access token in cookies may be vulnerable to some client side attacks (stealing user cookies for example). Use session instead and HTTPS for communication.


how to detect the URL an android app uses

The easiest way to do this is to run a debugging/security web proxy like Burp Suite, Charles, or Fiddler on a machine, and then set the Android phone to use that proxy. Most apps will obey the device proxy rules, and you can see the host and, if not using HTTPS, the full URL.

If it is using HTTPS, you will also need to install the proxy's own certificate on the phone to enable it to man-in-the-middle the connection. Some apps use certificate pinning to make this harder.

Alternatively, use a technique to enable you to sniff the traffic with Wireshark. Frequently I use a hostapd based AP using a USB wireless dongle to do this. Again, HTTPS makes this more awkward.

If neither of these work, you can retrieve the app from the device and then decompile it and find any strings or URLs in there.


No you do not need to rate each control area on C.I. & A. One score for the overall state of the control item in the organization is sufficient. A single score in each area also reduces confusion. Ultimately, the decision on how the assessment will be conducted is part of the clause in 6.1.2. See below for additional info.

  There are many myths regarding what the risk assessment should look
  like, but in reality ISO 27001:2013 requirements are not very
  difficult – here is what clause 6.1.2 requires:

  1) Define how to identify the risks that could cause the loss of
  confidentiality, integrity and/or availability of your information

  2) Define how to identify the risk owners

  3) Define criteria for assessing consequences and assessing the
  likelihood of the risk

  4) Define how the risk will be calculated

  5) Define criteria for accepting risks

  So essentially, you need to define these 5 elements – anything less
  won’t be enough, but more importantly – anything more is not needed,
  which means: don’t complicate things too much.

SOURCE Note: I wouldn't consider this guy definitive but he sums up what I would have said pretty well.


Tech support agent asked me some questions unrelated to tech support or my problem

Major Problem Potential

First, you need to determine whether or not that phone number was a legitimate Microsoft support line. I suspect it wasn't because Microsoft doesn't normally remote into your machine.

Second, if you didn't pay for him to fix your computer then you're already in trouble. No one works for free. That includes major corporations and scammers.

If you gave an unknown person access to your machine, you have already been the victim of a social engineering attack. He doesn't really need to come back later, as he's already done everything he needs to.

Probable Event

Most tech support scammers do one of two things: convince you to pay them money or install a backdoor that gives them continuous access to your machine. Some of them do both. If this was not an actual Microsoft person, this has almost certainly occurred.

Different attackers have different goals, so there is no way to guess what his malware will do. Ultimately, you'll have to assume the worst and address all possibilities.

There are, however, a number of common outcomes:

Your PC becomes a member of the attacker's botnet. It will attack web sites, send spam emails, and take other actions as directed by his command and control servers.
Your PC has a remote access trojan/tool (RAT) installed, and the attacker will personally use your computer in some way---spying, stealing account info, using as an intermediary when hacking other systems.
The attacker has installed cryptoware, and your files will eventually become inaccessible unless you pay him.
The attacker installed adware/spyware, which tracks your activity and loads/embeds ads into web pages in order to generate revenue.

It is definitely possible to mix and match from this list, and there are other possibilities. These things offer the most payback.

Responding to the Event

In the very likely case that this person was not a Microsoft employee, you need to act immediately to preserve your data, sanitize your system, and secure your accounts. This may take some time and money, depending on your personal habits.

Preserve your data. Create new backups of important files, preferably on write-once media like CD-R, DVD-R, or BD-R. USB drives are an acceptable alternative, but I wouldn't connect any device with "untainted" files to this computer. Cryptoware will encrypt anything it finds, so old copies of your files should not be made available to this machine until it is sanitized.

Sanitize your system. You will basically want to wipe everything and reinstall Windows from scratch. Installation discs can be ordered from the manufacturer if you don't have them handy. You can also download a bare Windows 10 installer from Microsoft, but you should do so from another PC---one that is presumably clean.

Secure your accounts. You will need a clean computer for this. Use another machine right away if you have one, or do it from this PC after you've wiped it. Log into all of your accounts and change your passwords. This includes email, social media, bank accounts, etc. If possible, kill all other active sessions. E.g., Facebook lets you see where you're logged in and terminate those sessions.


This could be due to the length restrictions on certificate keys.

Microsoft enforced a minimum key length limit of 1024 bits in August 2012. Check that your self signed cert is created with a key length of at least 1024 bits.

For more info you can check out this blog post What does the “This certificate has an invalid digital signature.” message actually mean?

You can specify the key length when creating the cert with by using the -len parameter like so:

makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r


Design of system based on HTTPS, Client Certificates and custom CA

First let's note that each of your servers will nominally have two keys and corresponding certificates. One is for use as a server in the SSL sense (when the browser, or another server, connects to the machine), and the other is for use as a client (when the machine itself connects to another server). You can arrange for both keys (and certificate) to be the same, but this can add a few constraints. An asymmetric key pair can be used for key exchange or for digital signatures, but not all algorithms support both; also, the certificate itself can further restrain usage to only signature, or only key exchange, through its Key Usage extension. In SSL, when using one of the basic RSA-based cipher suites (e.g. the very common TLS_RSA_WITH_AES_128_CBC_SHA), the server key is used for key exchange (i.e. asymmetric encryption of a secret key randomly generated on the client side), but certificate-based client authentication necessarily uses a signature.

Therefore, if you want to have one private key per server, then you must arrange for either of the following:

The server key has type RSA and the certificate allows for both encryption and signatures.
The certificate allows for (at least) signatures, and you configure the servers to use only the "DHE" cipher suites (the key exchange part is then done with an ephemeral Diffie-Hellman key pair which the server generates on-the-fly, and the server key is used only for signatures).

The DHE cipher suites are, generally speaking, recommended because they offer Perfect Forward Secrecy: data exchanged over the wire cannot be decrypted afterwards, even if the attacker steals a copy of the server private key.

If you do not want browser warnings, then you should not put the server IP address in the subjectDN but the server DNS name. Browsers (and, more generally, all HTTPS clients), when they connect to a server, want to find in the server certificate the expected server name, i.e. the one which appears in the URL. They want to find it in a Subject Alt Name extension (with type dNSName) or, if such an extension is altogether lacking, in the Common Name of the subject DN. This lookup is for the name only, not for the IP address. This is described in section 3.1 of RFC 2818.

There is no conceptual problem in looking up IP addresses in certificates; it is just that existing browsers don't do that. So stick to names. Besides, names are handy when infrastructures migrate (the IP can change, but the names will remain the same, thus not requiring a new certificate issuance).

That being said, for your exact questions:

Certificate validity can be as long as you are comfortable with, with the following caveats:

Technology progresses over time, so what is thought as a robust key may turn out not to be that robust after a while. So you may want to limit key lifetime so that some operation will be needed, forcing you to reconsider your key size choices regularly. If you use 2048-bit RSA you ought to be good for the foreseeable future, i.e. for the next 20 years or so (further than that, there is no foreseeing, only speculation).
The year 2038 problem may imply some interoperability issues if you choose an end of validity date beyond January 18th, 2038.
You want a handy procedure to cover the case of key compromise (e.g. a purloined backup tape), and "waiting for the certificate to expire" is not very workable if the certificate lifetime is beyond, say, one week. See below.

The CA is crucial for security, so a prudent deployment would be to put it on an offline machine. No network at all means no possible remote hacking, and that's a good thing. However, as explained above, you need "something" to cope with compromise situations, which can be one of the two following things:

You issue only very short-lived certificates, e.g. every week a new certificate good only for one 10 days. Each server receives a new certificate every week. If a private key is stolen, the thief only has ten days to play with it, because afterwards you will not issue new certificates for that specific key.
You use certificate revocation lists: the CA regularly publishes (e.g. each week) a new signed CRL, which contains the serial numbers of the revoked certificates. Clients (browsers and other servers) will download that CRL to check that the server certificate is still good. This is mathematically equivalent to the scenario with the short-lived certificates.

Short-lived certificates have the advantage of keeping browsers out of the loop (only servers will need to be aware of it), but CRL are more likely to be supported out-of-the-box by SSL implementations. To support CRL, you need to put a CRL Distribution Point extension in the certificates.

Either way, your CA will have to push some data elements to remote servers on a regular basis, be they renewed certificates or CRL. This is at odds with the concept of an offline CA. Some solutions imply a physically one-way link (some people use 10baseT ethernet with only one pair of wires connected; I have also, once, deployed a system where CRL are encoded over an audio link, because the line out audio jack is electronically one-way).

I expect most of your customers to put the CA on the same machine than their first server, then forget about it, and be very sorry when their server gets hacked into.


Security questions - SSL secured payment iframe on an SSL secured site

Embedding and SSL frame in and HTTP page is only unsafe if the host page is MITM’d and replaced with a phishing host and phishing frame. This is the only danger. The same origin policy protects everything else so long as they are on different origins (I assume they are because why else would you not have SSL on this page?).

Against a passive attacker, this is safe. If they are actively modifying your traffic and change the frame SRC URL all bets are off. The content of the original page is of course safe still but it’s very hard to know what the actual location of an iframe is as a user.


I found someone asking the same question on the gnupg mailing list archive.

  This a database file storing the certificates as well as
  meta information. For debugging purposes the tool kbxutil may be
  used to show the internal structure of this file. You should backup
  this file.

Source : http://gnupg.10057.n7.nabble.com/What-is-pubring-kbx-td50294.html


Adding a "comment" to PGP mail signature files?

OpenPGP, RFC 4880 "Forming ASCII Armor", defines a way to add comments to ASCII-armored OpenPGP data.

Using GnuPG (no matter whether using GPGTools or not), this comment can be configured using the comment option, either as gpg --comment or in the GnuPG config file ~/.gnupg/gpg.conf, for example

comment Comment you want to add in each file.

The Apple Mail plugin does not overwrite the option, thus the comment will also be added to mails sent using Apple Mail.


How to authenticate a legit thing App on the Internet of Things?

Software is inherently copyable, as all those who have tried to prevent copies of their software from getting out have found.  Crackers have more time to spend than you do, and they only have to find one exploit.

If you're talking about app stores, then you've got five major choices:

Trust your users, and keep your software simple and robust.

I recommend this one.

Choose app stores whose validation mechanisms you trust to be "good enough", and use those.

Second best

Sell a piece of hardware that's an authenticator (a dongle) and then give the app away for free, since without the dongle/authenticator it's worthless.

For instance, a Yubico FIDO, or try to find a Bluetooth smart card reader.
Or use one already available, like the TPM you mentioned.

If you do, be explicit and obvious in your requirements; many customers, myself included, disable TPM.

Spend large amounts of time and effort on so-so solutions that won't do much in the end

And then even more dealing with customers who travel a lot, switch devices often, and so on and so forth who still want your app to work.

Make your own app store, tie each card to an account, and do a per-service or per-time charge that runs out.

And, again, deal with angry customers whose accounts were stolen (perhaps because they use a lousy password) and thus paid for services they aren't receiving.

And the credit card companies who did a chargeback on you.


Is this a viable defense against correlation attacks?

This does not provide you with much benefit.
What you are referring to is called multiplexing, which is the act of sending multiple discreet signals through a single data channel. Unfortunately, it does not provide very much protection against traffic correlation attacks done by a global passive adversary. The reason is that each individual connection will have a different traffic fingerprint. For example, Tor uses 514-byte packets called cells, whereas a VPN does not, making it possible to identify Tor traffic and non-Tor traffic even when they are both being put through a VPN. The same applies to different types of websites. And streaming traffic on YouTube will not mask other traffic from loading an HTML page, since the buffering behavior on streaming sites can be trivially distinguished from the behavior of a web page being loaded.
As grim as this may seem, it's actually not all that bad. While intentionally trying to mask traffic by using overlapping connections may not be particularly effective, simply browsing multiple sites in multiple tabs can actually decrease the accuracy of existing website fingerprinting attacks. This works because most website fingerprinting algorithms rely on the assumption that subsequent connections are both to the same destination. When that assumption is broken, classification accuracy suffers.
There are viable defenses out there, however. WTF-PAD is an experimental protocol which provides low-latency and low-overhead cover against website fingerprinting and other types of traffic analysis attacks. It does this by varying the time and size of individual bursts of packets sent between your client and your guard node. Tor Project has been considering integrating it for a while now.
There are a number of research papers relating to anonymity networks on Free Haven.


is it possible to create a login "key" out of a USB drive?

I don't think he is referring the USB-key solution as a sole authentication method, but as an addition to the normal username-password authentication.

There are two methods I can think of, in order to implement this:
1. Encrypt the entire hard drive, and put the key-file on a USB drive.
2. Leave disk unencrypted and use the USB drive for a login purpose only.

Let's review:
1. Use truecrypt or dm-crypt (or their Mac OS X equivalents) in order to encrypt the entire hard drive using a key-file and storing it on a USB drive. The obvious and major drawback: losing the USB drive will cause the loss of the entire filesystem.
2. Use solutions like pam_usb (http://pamusb.org/)

Do not forget to take in account remote login considerations!


What can a compromised firmware (UEFI) do after the hard-disk has been wiped?

The simpliest malicious firmware can do is to add or replace existing executable files, to make OS load it on boot. This is how LoJack/CompuTrace anti-theft software works.


Is using RC4-MD5/RC4-SHA as SSL ciphers enough for most purpose?

Short answer: yes, things will be fine.

RC4, MD5 and, in some minor measure, SHA-1 all have some known shortcomings, but none of them will make your Web site weak. To be accurate: if using a RC4-MD5 cipher suite makes your Web site significantly weaker, then it is otherwise extremely solid -- more solid than seems to be practically reachable, indeed.

However, you might want to throw in a few more cipher suite, e.g. with support for 3DES and/or AES, so as to accommodate restricted clients. Some people got the messages wrong, panicked, and deactivated RC4 altogether from their browsers.

The "score" in ssltest is nigh meaningless. Don't read too much in it. It is like reputation in security.SE: it more relates to the efforts invested in obtaining a high score than to real security.


What exactly Not Secure means ? Does it means HTTP only website ?

"Not secure" in Chrome means that the site isn't using HTTPS.

  What are all possible reasons for site being Not Secure ?

To get the exact error above, it's just when a site doesn't use HTTPS. However, you can get a similar not secure error if the site's certificate is invalid or if there isn't HTTPS over the whole page.

  Is it OK to have an Account Login Site asNot Secure ?

No, this is not ok - if somebody can intercept a login request, they can see the user's login credentials. IBBoard made a good point in the comments - having a login site without HTTPS which is on the internal corporate network isn't as dangerous as it being a public site where it can be accessed from your home PC. It's still not secure but the only people who can really MiTM the connection are the company system administrators (assuming the network is setup correctly).

  Do Cookies have something to do regarding site as being not secure ?

If the site isn't using HTTPS, this means cookies are sent in the clear. This could cause issues when the cookies contain sensitive data such as tokens, which can lead to session hijacking.

  What are possible ways to make this site as Secure and How can I inform the responsible ones to make it Secure ?

By using HTTPS with a valid certificate, Chrome will mark the site as "Secure". However, as stated by Edu, even a website with a valid certificate can be non-secure if is also serving non-secure content such as HTTP images. Mixed content (Having HTTP items in HTTPS pages) is considered non secure. If you're concerned about the security of this login site, I'd express your concerns to the IT department and see what they can do about it.


How to deal with "confirmation" email for account you didn't set up?

For you personally, ignore it.

You may want to notify Medix that people are pulling these scams, but there is nothing technical or legal that Medix can do against it. You would only do them the favor of being informed (if not already) so that e.g. their support people know these are doing the rounds (if this campaign is large enough, they will get calls).


Is a generic input filter enough?

No, input sanitation is not the proper defense against any attacks, so just because you do have some filters is no reason to call it a day.

You do need proper defenses against typical attacks in place, eg prepared statements for SQL injection, encoding variables on output against XSS, etc.

That being said, additional input filtering is highly recommended as defense in depth.

Usability of your function

Usability is important. If no one knows what exactly your function does and how to properly use it, it will provide less security as people - this may include you in the future - will use it incorrectly or change it.

Your function isn't all that usable though. If I see san($x, "full"), I have no idea what is happening. Same goes for mid and low as arguments (and the naming doesn't even seem to make sense; is low supposed to be less secure - against ... something ... - than full or mid?).

A generic "full" also makes it very easy to change what the code does. Maybe you think that you need ; in some other case, so why not add it? It doesn't seem to do any harm, and it still matches the "full" description.

I would suggest some generic Input class with methods such as getInt($name), getAlphaNum($name), getCleanHTML($name), getRaw($name), getFilter($name, $regex), etc. With names like these, you see right away what you get, and if it's appropriate for the input and the situation. You also know not to change the implementation (getInt should always return an integer, getAlphaNum always alphanum).

Defending against Code Execution

Your example should be safe. I can't break out of the current context or add a new command, because I have neither space nor semicolon, nor any other character that may be used in different shells to add new commands.

Still, as suggested above, I would rewrite it. So it might look like this:

$str = Input::getFilter("cmd", [^a-zA-Z0-9_\-]);
$cmd = "cmd1 foo | cmd2 -arg=". escapeshellarg($str);
shell_exec($cmd); // is this secure?

Now you are using the recommended approach (escapeshellarg), and have an additional filter, where it is quite clear what the filter does currently or might do in the future.

Defending against XSS

First of, your code is bugged. < is $lt (for less than).

Secondly, this will defend against XSS in some cases, but not all. It will not defend against XSS if you are already in a tag context (eg <img src="[USERINPUT]">), or in a JavaScript context (eg <script>var = "[USERINPUT]";</script>).

This is also one of the reasons that input filtering is not enough to prevent XSS (except very strict filtering, eg only accepting integer). You need to know the context to properly defend against it. In most contexts, htmlspecialchars with ENT_QUOTES is good enough though, see this guide for more information.


Verifying encryption in Facebook Messenger secret conversations

Facebook Messenger uses the Signal Protocol. This is the same protocol used in Signal and WhatsApp, and works on standard public-key cryptography principles.

Your key is your own public key, which others can use to encrypt messages intended for you. Alice's key is Alice's public key you (or anyone else) can use to encrypt messages intended for Alice. The strings presented in the app are actually cryptographic signatures of these keys.

To verify that both you and Alice have the correct keys, you have to compare the cryptographic signature of your key on your device to the cryptographic signature of your key on Alice's device and the cryptographic signature of Alice's key on Alice's device to the cryptographic signature of Alice's key on your device. This should be done over a secure channel, e.g. by meeting with Alice in person and comparing the signatures visually.

When you have verified both keys, MITM should not be possible. This is of course assuming Facebook's implementation of the Signal Protocol is correct and secure.

You can also skip the verification entirely for what's known as Trust On First Use (TOFU). With the TOFU approach you simply blindly assume that the keys are correct the first time, and later if someone attempts a MITM attack, the app will notify you that the keys have changed.

There's a Facebook whitepaper on Messenger Secret Conversations here and a formal audit report of the Signal Protocol itself here.


In short, don't use wildcard bindings.

Only bind applicable host names to websites and be specific. For example, only allowing www.website.com will only allow requests with that host header value. Any others will not get processed by the website so you're essentially white-listing the acceptable host names.

By taking the URL Rewrite (or similar) approach, a new rule needs to be added for each "bad" request. This is not a good support model (i.e. whack-a-mole) for there is no way to keep up with the possible combinations. As an example, I could register mysite.foo to your IP and now you need to add a rule. By taking the recommended approach and not using wildcard bindings the request won't even go to IIS for there isn't a website configured to process the request.

The vulnerability mentioned is from websites being configured to accept any host name. In doing so it allows that value to populate the variable which is no longer trustworthy as it could be anything. By taking the approach of only binding specific host names you're ensuring that only those values will populate the variable and are therefore trustworthy.


OpenID Connect: Why use authorization code flow?

Even though the connection between user agent and servers are secure, the user agent may not be fully protected. Since authorization code flow ensures the user agent is not privy to the tokens, security is improved by reducing exposure of tokens to between servers only.


Why are there open ports on my home network router?

In general, you should close them if you have such capability and have no reason to allow incoming connections.

What you did not state, however, is what your home network looks like. Do you have a cable modem and external router, or single gateway device? or?  Who is your ISP?
 Depending on your ISP, you might be talking to an IP entity on their network or on your LAN.


Understanding Oracle 11g password hashing algorithms

What you have matches the documentation I found (both official and not).  Too bad, it's not as secure as it could be.  Even if using SHA-1 (perhaps to be FIPS 140-2 compliant), one could run the data through many iterations to make it much harder to brute force.


Windows Applications for Exploit Development exercising?

I found a very comprehensive list of various applications to use for pentesting. There isn't much I could find however for windows applications, but here's some of them from the link above:

www.oldapps.com - Some old versions of apps which have known vulnerabilities.
www.payatu.com/hacksys-extreme-vulnerable-driver - A windows driver with vulnerabilities such as stack overflow.
sourceforge.net/projects/virtualhacking/files/apps%40realworld/ - This website has a TON of vulnerable applications all ready to be exploited.
www.oldversion.com/ - More older versions of programs.
www.overthewire.org - This has many security challenges - buffer overflows, web exploitation, etc.

The website I linked earlier also has many other resources for practising which may interest you.


You can use the Zest functionality of ZAP to perform your authentication. In the icon bar on the top, on the far right you will find a tape icon that says "Record new Zest Script...". Hit it, choose a name and choose "Authentication" for the "Type" dropdown.

Now open the a browser via ZAP and manually perform a login to you site. Stop the recording by hitting the tape icon again. In ZAP, on the left side where the scanned Sites are shown, switch to the "Scripts" tab to find your script. You will see any recorded requests and you can go on to delete any records that are not necessary for your authentication.

On the top right, next to Quickstart / Request / Response you should see a "Scripting Console" tab in which you will find a button to run your recorded script.

If the script is working, now go back to the context settings you screenshotted in the OP and choose Script-based Authentication. You will be able to select your recoreded script. Hit "load" and fill out the regex patterns.

Now to the part that has cost me a lot of time: you have to specify a user in the context settings although it should not be necessary because the user is part of your script. Just type in whatever you want for username and password.

Now you're done! Start a spider, choose the your context and your fake user and it should be working.


... attackers could steal the hashed data ... and use brute force to deduce back the private data.

There may be some practical issues, regarding how much entropy there is in the input data

$websiteDomain . $myChildSchool . $myPetName . $etc

If some of this info is known to the attacker then those parts have no entropy. The remaining unknown portions could be brute-forced by the attacker if the remaining bits of entropy becomes too low. You should consider:

Bits of entropy of the input data after the attacker has acquired the 'low-hanging fruit'.
How sensitive is the remaining input data, and what are the potential damages of this being guessed?

  The purpose is to be able to recover passwords ... using only my brain and an internet connetcion. I can't remember l33tpa$sw0rd more than one hour, though I can surely remember my parents' names and so on.

Note that every 'secret question' must be answered precisely character-for-character in order for the resulting hash to be consistent. Also add up the bits of entropy to make sure they are sufficient.

Please read this description of the pros and cons of each popular Slow Password Hash with implementation notes. The best options are BCrypt, SCrypt and Argon2, with the former being the best vetted and the latter being the newest one on the market. Personally I would use BCrypt for this project.

  I can't use password_hash() because the result is automatically salted so it produces different hashes each time. I can't manually provide a salt as it is deprecated (produces warning, and likely to be removed in future PHP versions).

This function uses BCrypt by default, which is one of the good options. You would of course need to specify a hard-coded (unchanging) Salt (which in this situation is considered to be Pepper), and it is best if you can set a custom Work Factor. StackOverflow would be able to help you with those two specific requirements to be implemented in PHP.


Kerberos over HTTP isn't officially developed by the MIT project.  It is implemented though using GSSAPI, and the extensions are described in RFC 4559.


Patterns for searching a source repository for private data

The important files vary by programming language, and environment. For example, if you're running nginx, .htaccess files, by default, won't affect the behaviour of the server. However, those same files could really mess things up if someone loaded your application into an Apache environment. Therefore, you need to customise any list to your own needs.

There are some files which are probably always considered sensitive though:

Private keys (id_rsa, id_dsa, *.pfx)
Shadow files (/etc/shadow) - if you're checking these into source control without a very good reason, you're doing something wrong!
History files (.bash_history and similar) - these often have passwords which were mistyped, or used in command lines for interactive tools stored
Log files (/var/log/*) - again, they often have details you might forget to look for in

More specific files that shouldn't be in source control:

.htaccess, .htpasswd - Apache directory specific configuration files
web.config - IIS directory specific config file
wp-config.php - Wordpress config
sites/*/*settings*.php - Drupal config files
*.jks - Keystore files
and so on...

Github have a good sample of gitignore file contents, although these also cover things that shouldn't be in source control due to other reasons (e.g. compiled output shouldn't usually be in source control, due to not being source...)


Can a virus infected usb stick infect a MacBook by connecting to it?

As I understand your question:

You used a known thumb drive i.e. not an unknown device that looks like a thumb drive.

You may have infected a file on the thumb drive from an infected Windows Machine.

You plugged the thumb drive into your Mac and formatted the thumb drive.

You wrote a file to the freshly formatted drive from your Mac.

If I have interpreted correctly, then there is no mechanism I've ever heard of that could have infected your Mac.

Even with a more cavalier approach, cross platform malware is rare. Relax, you're good!


Best practice for encrypting data on Mifare

If you are reading and writing raw data, you may assign whatever meaning you want.
In fact, an epoch of 1603710920 would probably be stored as bytes "5F 96 AF C8" (or perhaps C8 AF 96 5F, if using a different endianness). However, you could equally store the expiration as the number of seconds since birth of your first child, or as days since start of validity. You get to choose the meaning.
Using odd values would probably difficult understanding what is there, but probably not solve the original problem. Let's say you encrypt 5F96AFC8 resulting to 55F1A991, someone fiddles with the contents of an expired card and, trying to enlarge it blindly decides to write 55FF0000. You read the contents and after decryption that decodes to 11/04/2035. So it returns "not expired"
What you probably want instead is authentication, the assurance that the contents of the card have not been tampered with. A really simple way to ensure that would be to include a hmac of the card contents with a secret value. A more advanced solution could instead use an elliptic curve signature over the contents. The point is that you verify that the signature is valid before trusting any data in the card.
This could be done in addition to encryption or not use encryption at all (perhaps the contents of the card aren't secret at all, e.g. "Card #1234 belonging to John Smith, expires Oct 26 2020 10:15 UTC").
In any case, you should note that none of those approaches prevent cloning. If you have a card storing "credit", a user could copy its contents, spend some money, then write back the old contents. They don't need to know which field stores the amount or if it is encrypted. They just know that it reverts back to a card with X credit.
Similarly, John Smith could clone the card of Paula Bean which won't expire for another six months. Being restricted to cloning a full card means that it would be linked to Paula (in case someone would check the name, perhaps John doesn't look like her ☺), but it doesn't stop the potential fraudulent use of a clone.
In case, you should (in the case of card holding money, ideally they would verify the credit online -so John cannot change the amount stored in the card, and cloning Paula's card would still empty her credit-, or at least it should be reconciled so that a card with more credit than inserted into it after deducting the purchases would get automatically banned)


chsh is setuid because in order to change a user's shell, it must modify the root-owned read-only /etc/passwd file.

The system administrator may wish to limit which shells a user may choose, for example if users are assigned a shell which logs all commands to syslog.  The traditional way to do this would be to remove all other shells from the /etc/shells file, as chsh restricts users to choosing shells in that file.  (That then implies that for any users who aren't restricted in that manner, an administrator needs to change their shells by hand - editing /etc/passwd - since they can no longer use chsh to do it.)


Pro's and Con's of current 2-step-verification processes?

So one thing you're getting confused about is that you're combining to different security theaters. Let's instead look purely at the web, and then purely at the phone.
The Web Theater
With the web you're subject to people randomly trying to hack your account. This is protected by a password(something you know) and a username(something you have). In this case if anyone gets the username they can start attacking you and eventually get your account.
Now lets add a second password. YAY! Now they have twice the entropy. But it's still something you know(static). Instead lets change that password to something dynamic. Now EVERY time that dynamic one changes they have to start over because they have to retry every dynamic code and password combination in existence yet again.
That's just not worth it to try and break into. You would only DDOS a server, and if the server is setup correctly then you can't DDOS it.
The Phone End
Okay so now someone has your username, and phone, and you're locked up in a basement... and they've beaten you until you have given them the passwords... and you're just crying and hoping the police show up and save you...
The truth of the matter is that the given part(on your phone) is kept physically secure by you. If you have a worry about physical safety, you should probably already be in the steps of doing something about it(like not lending it out, not displaying notification content on your lock screen(an option on most smartphones), and if you do receive it over SMS and someone sees it, all they see is a string. They don't know what it's for.
If they do know what it is for however then you've already been pwned because they know your username. If someone else knows your username you're doing something else wrong, and this isn't the problem. Your own physical habits are.
What about active connection pins?
The problem is the phone is making the communication, and as such if someone is listening to the phone and performs a MITM on just the phone, they can get access to the account. Generation without communication is much safer because someone can't listen to it. They would have had to have been listening to the initial setup(again separated without communication) to have gotten the pin to generate the time sensitive code. Again that comes into the tied up in a basement scenario. There I'd be much more worried about my physical safety than my account safety.
What about generated codes?
What if I look at a phone and see '8675309 sent 98jdff712hfg' on the screen? What does it mean? I don't know what service that number(usually from a pool of numbers that rotates randomly or is used by many services) is associated with. The only way this would have made sense is if I was sitting over your shoulder and watching the ENTIRE login process. Again that's something much more terrifying and you'd probably be looking out for it as you enter the data.