How to backup files from a infected computer to a USB drive in a safe way?

Most malware doesn’t infect the drive itself but there is a chance. Most likely, the malware that would infect the drive runs when the OS boots.

Boot the infected system from a cd rom or into recovery mode and then copy the files.

Once the files are on the usb, you’d need to scan them.


How to combine symmetric and asymmetric encryption to encrypt large files?

To get the benefits of both types of encryption algorithms you can create a symmetric key to encrypt the data efficiently  and then encrypt that key asymmetrically.
Only the private key owner can decrypt and have access to the symmetric key.


MITM using ARP spoofing with Kali Linux running on VirtualBox with bridged wifi network adapter

1)
The problem is indeed that for communication with the VM the host's MAC address is used.
This is what VirtualBox does when bridging to a wireless network adapter:

 From the VirtualBox manual: 6.5. Bridged networking

  Note:
  Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.

2a)
As a solution I use a wired network adapter. I used an external USB adapter which is operated by the host. I bridged it with the VM. I tested this and it does work.

2b)
What probably also works is to put set the field 'Promiscuous Mode' to 'Allow All' in the Advanced section of the Network adapter settings of the VM. Then the host will pass all traffic to the virtual adapter. I haven't tested it but I expect it to work.


url from another domain in my access log

welcome to the intertubes!!!

  What is the reason behind it?

what you see are scans for open proxies, e.g. someone is looking if he/she/it can misuse your server to browse other sites.

the first one looks very interesting, because it looks like a scanner; when checking the link (please DONT click on that with a browser), it will give back:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><title>AZ Environment variables 1.04</title> </head><body><pre>
HTTP_USER_AGENT = Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 2.0.50727; Media Center PC 6.0)
HTTP_HOST = server7.cyberpods.net
HTTP_CACHE_CONTROL = max-age=43200
HTTP_CONNECTION = keep-alive
REMOTE_ADDR = 80.226.24.11
REMOTE_PORT = 45993
REQUEST_METHOD = GET
REQUEST_URI = /azenv.php
REQUEST_TIME = 1377237144

  How are they doing it?

by using tools and issuing the GET-request directly

no magique at all :)

btw, get used to it, install stuff like ossec and you'll see a lot more scanners brute-forcing your website for wp/phpmyadmin/joomla - whatever-eyploits all day long


The communication is still encrypted, but the trust mechanism is undermined. But usually the most important factor is that users will get ugly warning messages about the security of your site. Most won't make informed judgements about the integrity of the connection, they'll just go buy stuff elsewhere.


CAST-5 aka CAST-128 is a fine choice of algorithm.  It probably hasn't had as much cryptanalysis as, say, AES, but there are no significant publicly-known weaknesses in the algorithm.  It's a 128-bit cipher, which is computationally infeasible to brute force, and so all of the security depends on the security of your passphrase.  GPG performs a technique known as "key stretching" (see the s2k options) to make it harder to brute force passphrases as well.

GPG is a great tool for encrypting text files -- that's basically what it's designed to do.  (Encrypt arbitrary blocks of data.)  You can use a password manager if you prefer to have your data structured/managed for you, or select something that plugs in to your browser.

  Should I add extra information throughout to act as "additional entropy"? Maybe dd if=/dev/random >> file

This won't do any good.  Modern crypto algorithms are not dependent upon any entropy present in the plaintext, but only in the key being used.  A known-plaintext attack on a cipher would render it dead from a cryptography point-of-view, so this should not be your concern.


RC4 encrypt many messages with same password

RC4 is not considered as secure anymore, since there are several security vulnerabilities found in it. More about RC4 on Wikipedia ...

Using the same password for all messages is also insecure, since if the password was discovered, all messages are compromised. Using pattern like 100, 101, 102 will not add much security to it, since attacker can guess what will be the next and previous password.


Yes, if you want, there is no extra security risk as long as you make sure that if caching is enabled, only private caching is specified to prevent this value being cached by any proxy server between users and your system.

e.g. cache-control: private HTTP response header.

The Same Origin Policy will prevent the token from being read on the page (assuming you have not enabled CORS).


Blocking people from taking pictures of me with smartphone

tl;dr

No, this completely falls within the realms of fiction!

The longer explanation

For something like this to work, Alice would need to find an exploit in the camera of Bob, which would then prevent Bob from taking a picture. The only ways of Alice to exploit Bob's camera is for her to send some kind of information to it.

Possible ways for her to do this would either be via what the camera "sees" or via some other channel (Bluetooth, Ad-Hoc Wi-Fi, etc.).

The first way is, to be frank, absolutely nuts. There are exploits related to images and specific image formats, but all those exploit the specifications of how image files are read, rather than the pixels on it.

As far as Bluetooth or Wi-Fi goes, this is a little bit more believable, but just barely above "Zoom and Enhance". If Alice could connect to Bob's phone via Bluetooth, there may be an exploit she could use that would disable the camera app.

However, if Bob used a dedicated camera instead of his phone, then Alice is out of luck and her picture will be taken.

How could I protect myself from having my picture taken?

There are, however, creative ways to hide yourself from cameras. After all, reality can be so much cooler than fiction if you get a bit creative.

Infrared LEDs emit infrared light. This light is not visible to our eyes, but to cameras. This difference is something that hackers can exploit.

By attaching many, high-powered infrared LEDs to your clothing in a way that they shine on your face (e.g. through LED strips on the inside of your hoodie, on your baseball cap, etc.), your face will receive much more light than the surroundings, causing your face to be extremely overexposed.

This will probably stop security cameras, since they will try to set their exposure in a way that most of the picture (i.e. your surroundings) are illuminated correctly.

Somebody taking pictures manually of you may be able to set the exposure correctly, showing your face, but making the rest of the picture very dark. With some clever image manipulation tricks, and multiple pictures taken at different exposure levels, you can be shown in your surroundings, even with such LEDs in place.

Cool, can I see how that looks like?

Here you can see a picture of glasses with just a few LEDs:

Attribution: Tokyo National Institute of Informatics

The two pictures on the top are with the LEDs turned off. This is how a person would see it. The green frame shows that a camera has detected a face.

The two pictures down below show the LEDs turned on. It's much harder to detect details of the person, but it's still doable, especially if you have some reference image. The camera, in this case, failed to identify a person.

With more and/or stronger LEDs, the effect will be much stronger.

Here is also a video, showing them in action with a typical webcam. Again, with some reference, a person is still identifiable.

What about the downsides to this?

Before you go online and order a 500 pack of infrared LED strips, there are some downsides to this technique.

A battery or some other power source is required. This may be the least of your worries, since LEDs don't draw that much power, but running around with a 9v in your pocket may become annoying.
You don't see if it's not working. Unless you regularly take selfies of your overexposed face, you don't know if your security system has failed.
Since you quite literally look like a shining ball of light on pictures, people reviewing security camera footage will probably start investigating why Jesus is casually walking through the mall. It does attract unwanted attention, is what I am trying to say.
You depend on your clothing. Depending on where you go, it might not be feasible to wear clothing close to your face, such as a swimming pool. You may be able to wear a baseball cap, but then you run into the problem of a power source.


Is it possible to sign a certificate such that the issuer is different than in the CA's certificate?

It would be possible to do this, but the simple question is: why?

Let us assume that when signing the TBS Certificate you change the issuer DName to something else. If the specified signer of the certificate is different from the real signer then the process of validating the certificate path would fail.

Check out RFC 5280 Section 6 to view the certificate path validation algorithm. One of the key checks is that the subject of certificate x is the issuer of certificate x+1, which in your question is not the case. Thus, the produced certificate would always fail certificate validation.

In all commercial situations you would not be able to do this, because the issuer part of the certificate is not included in the certificate request (check out the PKCS#10 format) and is set by the CA just prior to the actual signing of the certificate.

But if you were doing the actual programming of the certificate signing (using, say, bouncycastle APIs in Java or C#), then you could change the issuer name. However, in doing so your certificate would fail validation by all systems other than a custom validation system that you would have to build yourself.


Is SQL auth over windows auth a red flag?

In my experience, deferring to windows controller authentication is advantageous for a few reasons:

It simplifies removing access  - how many times has someone logged into a sparsely used vendor platform and discovered that someone terminated years ago still had access? Anecdotally, I've had instances where I didn't even recognize the name of the user, as they had been terminated years before I had even been hired.
You can build your security/access around AD group membership. Similarly to the above, this simplifies updated/maintenance and decreases the chance someone else has access to something they shouldn't.
It lowers your overhead. Adding new users is not fun, and takes time away from other stuff you could be doing. Let the person in charge of onboarding worry about that, and then automatically piggyback off their work.


I accidentally published my SSH key passphrase, what to do?

Technically, changing your passphrase is sufficient if you don't also believe that your (password-protected) private key has also been leaked.

Realistically, you might just want to replace your SSH key with a new one.  They're so cheap they might as well be free, and it removes you from worrying about whether anyone has, is, or will be able to get a copy of the private key with the compromised passphrase.  Remember, if somebody grabs a copy of your key that you backed up months before you leaked (and changed) your passphrase, the passphrase still gives them access to that key - which is the same as you're using today under a new passphrase.

So just change your key.  It's good practice and best practices.

Edit:

@David-Z has suggested that the time involved in replacing the key is a cost to be considered.  I maintain that, since we're talking about keys, that's also negligible, as you can automate the process.  The following script took me about 15 minutes to write and test:

#!/bin/bash

for i in $*
do
    cat newkey.pub | ssh -i oldkey username@$i "cat >> ~/.ssh/authorized_keys"
    ssh -i newkey username@$i "sed -n '/my_old_key/!p' < ~/.ssh/authorized_keys > ~/.ssh/authorized_keys_tmp && mv ~/.ssh/authorized_keys_tmp ~/.ssh/authorized_keys"
    if [ $? -eq 0 ]; then
       echo "Successful key replacement for $i"
    else
       echo "Key replacement failed for $i"
    fi
done

This script will:

Use the old key to append the new key to the remote authorized_keys
Use the new key to remove the old key from the remote authorized_keys

The beauty is that if anything went wrong pushing the new key out, the removal of the old key will fail since it uses the new key, so you're less likely to shoot yourself in the foot.

You'll need to cache your passphrases with ssh-agent so that it doesn't prompt you for these uses of ssh; then just run it with the servers you want to update on the command line:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-GWE6uxZxn9IS/agent.2016; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2017; export SSH_AGENT_PID;
echo Agent pid 2017;
$ ssh-add oldkey
Enter passphrase for oldkey:
Identity added: oldkey (oldkey)
$ ssh-add newkey
Enter passphrase for newkey:
Identity added: newkey (newkey)
$ ./chssh.sh server1 server2 server3
Successful key replacement for server1
Successful key replacement for server2
Successful key replacement for server3
$


If you define the local university proxy in Firefox, every byte of traffic generated by Firefox will be available to them. And that includes:

Time and date of every packet
Source IP (that's you) and destination of every connection
If not encrypted (SSL/TLS/VPN), every single byte in clear
Amount of data transmitted

If the proxy wants to log everything, it can even log all your session for later examination.

Having the capability to log everything does not mean they do log. That would cost a lot in terms of processing power and storage media, so generally they log the origin and destination addresses, protocol, and timestamps. But that is enough to see if you are accessing a research journal or a recreational magazine.

Generally, only the traffic generated by Firefox would be routed through the proxy. But there are some programs that will try to access the Internet directly, and will search for proxy configuration in case the direct connection fails. If you have programs of this kind, they can reach the proxy by themselves.


The length of output of hashing algorithms are not depended on the input. Any input produces same length of output.

From a post in stackoverflow asked by z-boss, and answered by Bill Karwin;

  MD5 generates a 128-bit hash value. You can use CHAR(32) or BINARY(16)

  SHA-1 generates a 160-bit hash value. You can use CHAR(40) or
  BINARY(20)

  SHA-224 generates a 224-bit hash value. You can use CHAR(56) or
  BINARY(28)

  SHA-256 generates a 256-bit hash value. You can use CHAR(64) or
  BINARY(32)

  SHA-384 generates a 384-bit hash value. You can use CHAR(96) or
  BINARY(48)

  SHA-512 generates a 512-bit hash value. You can use CHAR(128) or
  BINARY(64)

  BCrypt generates an implementation-dependent 448-bit hash value. You
  might need CHAR(56), CHAR(60), CHAR(76), BINARY(56) or BINARY(60)

Full post is here: https://stackoverflow.com/questions/247304/what-data-type-to-use-for-hashed-password-field-and-what-length

In addition, do not forget to add salt to your passwords(BcryptNet handles salting automatically). Before doing your implementation , I recommend you to read the posts;

How to securely hash passwords?

https://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database


How do I implement a Microsoft Login into my own website?

Microsoft Login is not an accurate description of any type of "modern" authentication. You could be referring to Kerberos/SPNEGO, SAML 2.0 using ADFS or OAuth 2.0 using Azure AD, etc.

As you notice, there are plenty of options to choose from when integrating web applications through single sign-on with Active Directory ("Microsoft Login"). I can't provide an specific answer since I don't know which products are available and which is the current authentication status quo of your company.

I would recommend reaching out to other developers within the organization to verify the common authentication methods that are already used. If your company already has a SAML 2.0 compliant Identity Provider, implementing the Service Provider part in your application could be an elegant and secure solution.


A couple of redirects after clicking in a link, what are they after?

The first link uses a redirect webpage that is detected by many antivirus products as:

Sophos: Troj/Redir-O
Microsoft: Trojan:HTML/BlacoleRef.A
Kaspersky: Trojan.HTML.Redirector.an
AntiVir: HTML/FriendLoad.A

The text
 You are here because one of your friends
 have invited you.
 Page loading, please wait.... is the thing that is being detected so it was probably used  before in a malware or spam campaign to redirect to different websites.

An analysis of an older but similar redirector is here.

  [...] will redirect you to the following website that masquerades as a
  CNBC website article,
  For example:

  marketnewsonline10.com
  marketnewsonline11.com
  marketnewsnext7online.com

The site it redirect to, http://newsmarketgenonline10go.eu is detected by Websense ThreatSeeker as a phishing site.

Other similar domains used in the same campaign are also detected as phishing:

Phishtank:    Phishing site
Comodo Site Inspector:    Phishing site
Websense ThreatSeeker:    Phishing site

This looks to me like an abandoned phishing campaign.


If I use the require-sri-for CSP, will script and style loaded from my site remain accessible?

require-sri-for doesn't mention anything about exceptions or exemptions for same-origin subresources so I would assume you'd need to include the hash regardless of where the resource is being loaded from.
From MDN:

The HTTP Content-Security-Policy require-sri-for directive instructs the client to require the use of Subresource Integrity for scripts or styles on the page.

And subsection 3.3.3 in the SRI specification, regarding the require-sri-for CSP directive and request verification:

3.3.3. Apply algorithm to request
This directive’s pre-request check is as follows:
Given a request (request) and a policy (policy):

Let protected resource types be the result of executing §3.3.2 Parsing require-sri-for on this directive’s value.
If request’s destination is a ASCII case-insensitive match for at least one token in protected resource types, and request’s integrity metadata is the empty string, return "Blocked".

Note: This logic means that request with matched destination and missing integrity metadata will be blocked even if it is not currently possible to set it’s integrity metadata. Such requests are originated by, for example, importScripts(), CSS' @import, or script/style elements without crossorigin content attribute.

Return "Allowed".

Depending on your build process, it's fairly easy to generate hashes for your own content. There's a bunch of tools listed in the Mozilla Hacks article about SRI.


Urls opens themselves on my Android phone

This random URL pattern is something very common on C&C Malware. This funcion is called Domain Generation Algorithm, that commonly generate URLs like www.<gibberish>.com.

Things you could do to probe what apps on your Android Phone could be causing this problem:

Check what apps were not installed from Play Store. There is a great chance that those are the one to blame. Many reports from popular games like Pokémon GO or Super Mario Run are injected with Malware. Once those are installed, is difficult to audit what are they doing, unless you use the least privilege principle and deny all access to them(camera, gps, calls, sms..)
Depending on your Android version, you will have App Permissions at your disposal. This could be a pain, denying permissions to every app and allowing them when asked, but, its a method to try to probe if any rogue app is trying to use your GPS or Front facing camera for example, without you actually having that app on foreground(active app);
Reset to factory defaults. This could be an option, unless your phone is cursed by firmware malware.

I Think that you will lose more time trying to probe the malware(giving it more time to better entangle your device, and capture more data), than making a backup of your important stuff and reseting it. Maybe, even better than just reseting to factory defaults would be using your phone maker software to reflash a clean firmware through USB.


SSH Public Key Authentication vs Username/password for API Access

There are several differences.

First, by setting up your API server to accept username/password (as opposed to only allowing access via keys, which is increasingly a best practice to do) you potentially decrease its security in general, as, now, users with weak passwords on the system (or, worse, services that you install which may have hardcoded default passwords) will make it possible to breach your server.  Brute-force attacks are suddenly an option for those wanting to break into your system (which, if you run an SSH server on a public IP you are guaranteed to see almost immediately). Disabling ssh login via passwords and requiring login keys is as simple as setting: "PasswordAuthentication no" in your sshd_config and restarting the sshd service (or your server). I do this on every linux box I build as one of the first steps.  Plus, this encourages setting up a very long and random password, since (if you set up /etc/sudeoers properly) you will never actually use it for anything. :)

Second, with the ssh key option, you can easily set up the authorized_keys file in such a way that it will:

Only allow access from a specific IP; and
Only allow the accessing user/script to execute a certain command.

This way, even if someone compromises your client box, the stolen key can't be used to log into your server from anywhere else in the world, and, if you set it up properly, it can't even be used to login from your client for anything other than what you allowed. For example, I use this to set up accounts/keys that can do nothing except rsync with certain options from a certain folder. So, even if the key were stolen, the attacker gains nothing other than being able to execute the command that the client machine is executing itself anyway, and only from the client's IP, nowhere else. I.e., gaining the key has not allowed the attacker to compromise the API server. You might be able to restrict an account that's password-based to only execute a certain command or only login from a certain IP, but I've never seen this done and don't know how easy it is.

Third, when you want to give access to your API server to another person/system in the future, and you want to use passwords, you run into the key distribution problem (ironically enough). I.e., you have to have a secure channel to exchange the initial account password so that the user can log in.  With SSH keys, all they have to do is email you their public key (which isn't something needing security), and (as long as you trust the email is from them, which there are ways to ensure), and you can give them access.

So, I hope this has convinced you that there is value to using keys (and, really, you should not be using password-only access on anything; keys or 2FA for public services are the only way to go :-)).  Cheers.


Does the heartbleed vulnerability affect clients as severely?

Yes, clients are vulnerable to attack.

The initial security notices indicated that a malicious server can use the Heartbleed vulnerability to compromise an affected client. Sources below (all emphasis is mine).

Since then, proof of concept attacks have validated this position - it is utterly certain that clients running apps that use OpenSSL for TLS connections may be vulnerable.

heartbleed.com:

  ...When [Heartbleed] is
  exploited it leads to the leak of memory contents from the server to
  the client and from the client to the server.

Ubuntu Security Notice USN-2165-1:

  An attacker could use this issue to obtain up to 64k of memory
  contents from the client or server

RFC6520:

  5. Use Cases
  Each endpoint sends HeartbeatRequest messages...

OpenSSL Security Advisory 07 Apr 2014:

  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or
  server.

Client applications reported to be vulnerable (Credit to @Lekensteyn except where otherwise stated):

MariaDB 5.5.36
wget 1.15 (leaks memory of earlier connections and own state)
curl 7.36.0
git 1.9.1 (tested clone / push, leaks not much)
nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
links 2.8 (leaks contents of previous visits!)
All KDE applications using KIO (Dolphin, Konqueror).
Exim mailserver
OwnCloud Version Unknown | Source

Note that some of these programs do not use OpenSSL. For example, curl can be built with Mozilla NSS and Exim can be built with GnuTLS (as is done on Debian).

Other common clients:

Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.
OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", but others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says: "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"
Chrome (all platforms except Android): Probably unaffected (uses NSS)
Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2 should be unaffected, as it is compiled with heartbeats disabled. Source.
Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS


Can the xxhash seed be found given a large set of hashes?

A cryptographic hash has several properties (from Wikipedia) :

it is quick to compute the hash value for any given message
it is infeasible to generate a message from its hash value except by trying all possible messages
a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value
it is infeasible to find two different messages with the same hash value

A hash function like xxhash doesn't need those properties - it is intended for things like hashtables and instead looks for sheer speed and good distribution of values.

One note : by "it is quick to compute the hash value for any given message" for a cryptographic hash, they really mean it is PRACTICAL rather than quick.  One of the problems with MD5 (which was considered a cryptographic hash, but now is considered broken) is that it has reached the point where brute forcing short passwords is practical, because GPU based clusters can do ten billion tries a second or so. That isn't all that is broken about MD5 - there are some mathematical attacks on the hash as well, but it doesn't help. Bcrypt/scrypt/SSHA512 all are much, much slower, but still practical for normal usage.


I did this myself. By essentially replacing eval's with echo's I was able to peel away enough layers until I reached the ugly webshell underneath. Appears to be the FilesMan webshell. This blog post matches the code I'm seeing pretty well: http://blog.codeguard.com/malwaregone-threat-analysis-wso-filesman-backdoor/


If your neighbor is using your WiFi, the fundamental problem is that they have your password.

Change your router password to a strong password and make sure you use WPA2 authentication. Make sure you perform the router change from a wired connection and disable WAN side administrative access.

Spoofing your MAC address would be a poor choice for them because it would result in collision problems with your MAC, which would not work well for either of you.

MAC spoofing would only come into play if you have applied MAC access controls to your router, which is not a default setup.

Last but not least, duplicate MAC addresses can be difficult to detect, so I would suspect spoofing your MAC is unlikely. Again, it’s probably just your password.


Why do web services keep asking me about my phone number?

EDIT: As this is still the accepted answer, I've made a number of changes to the below text to clarify that, while the "why" is still "probably for multi-factor authentication", this method is not trustworthy.

A phone number enables an easy way to set up two-factor authentication for things like password resets or other sensitive actions. By calling you or sending a text message, the service can confirm that [access to] the phone [number] is a thing you have. An email account is really just a thing you know, the same as a password, because you can access it without anything other than a password (and the identifier - in this case, the address itself - but identifiers are generally considered public). Thus, a two-factor password reset flow might go something like this:

Click on "Forgot my password" at login.
Enter your email address, and the site sends you a password reset link.
Open the password reset link (which contains a secret token), thus proving that the password to your email account is something you know.
Service sends you a text message with a short secret code in it (possibly after making you confirm your phone number).
You enter the code from the message, thus proving that your phone is a thing you have.
Two-factor authentication being completed, you can now set a new password, log into the site, etc.

The advantage to the service provider is that they are now much less likely to have to spend customer service time and possible customer goodwill walking the line between "I can't remember my password" and "somebody hacked my account". That kind of thing can be a significant cost sink, and if the site contains anything sensitive then it may lead to reputational harm to the site if they aren't paranoid enough.

Unfortunately, hijacking mobile numbers is not that hard to do. Even leaving aside technical attacks (faked cell towers or spoofing the phone or passively sniffing the radio traffic to catch the SMS that gets sent), phone companies have demonstrated that they are not trustworthy when it comes to authenticating people correctly before issuing them a new SIM with your number. As such, SMS or call-based second factors should be considered a weak additional protection, and should definitely not be trusted for single-factor authentication.

As for what the provider can do with a number, well, worst case would probably be to give or sell it to robocallers, the telephone equivalent of spam. Calling a mobile number in such a manner is actually illegal in the USA (since we're about the only place in the world that the recipient pays for incoming calls, either via prepaid credit or minutes of usage, so commercial messages without an existing business relationship are forbidden) but they happen anyhow. Realistically, though, any but the sketchiest of sites is unlikely to do anything like this (feel free to check their privacy policy, though of course there's no guarantee it's not a lie).

Second-worst thing would be to use it to send you unsolicited calls or messages, but I don't think I've ever seen this happen (do check for a "use your contact information for marketing or promotions..." option and make sure it's not selected).

In theory, the phone number might be useful to identify you personally (through a directory service / social network / phone book / whatever) and it's a lot easier to create throw-away email addresses than throw-away phone numbers. It's unlikely, though. If you're the kind of person who uses a fake name and a single-use email address when signing up for something, then putting your real phone number in there is obviously a risk. Otherwise, it's probably pretty harmless.


Share root access without sharing password

I recommend that you do not permit direct login as root via ssh on any system. As mentioned in gowenfawr's comment above, it is better to have personal accounts for everyone who will be administering the system on all of the nodes, and give them access to sudo to root locally. They would not need a root password on any node for this; they would use their own password or other credentials.

This can be automated with distributed authentication tools such as LDAP and RADIUS, or with a client-server tool in which the client runs locally on each node, gathers the information from a central authorization system, and creates and maintains the individual user accounts on the systems.

Failing that, you may want to set up a dedicated (non-individual) account on each node whose purpose is to run a specific set of commands as root via sudo control, and have a means for the public keys of all the administrators on the central "jump server" distributed to the authorized_keys for this account on all nodes.

The key (pun intended) is to protect against misuse or interception of the private keys of the administrators on the central node by not allowing unrestricted access to the root account remotely, and instead relying on local privilege escalation (sudo).


Minimal usage in Windows 10 justify filtering all ports besides 22, 80, 443?

There's a couple of different components to the answer:

I think you have a misunderstanding of ingress vs egress and stateful firewalls.  Most stateful firewalls (IPTables configured with ufw, the Windows firewall) will allow any traffic related to an already established connection through the firewall.  They only filter on the initial connection setup.
Most workstations have no need for any ports to be open in their inbound firewall policies.  Inbound ports are only necessary when you expect other hosts to connect to a service you are hosting.
Limiting outbound ports to something like the set you have listed is a reasonable thing to do, but might result in other software not working as intended.  For example, bittorrent, voice/video chat, etc., often use other ports for communications.
Don't forget port 53 on both TCP and UDP.  DNS is rather important.  Or useful, at least.

As schroeder points out, there's the alternative of using application-based firewalling.  Then you can allow individual applications the choice to communicate or not.  (Your web browser, putty, etc.)  With this choice, you'll probably discover quite a few things that will need additional whitelisting as you go, such as updaters/installers, etc.


Yes, your VMs are just as susceptible to attacks as physical attacks, even from other VMs on the same network. There are several methods to isolate and protect your VMs from each other as stated here ESXi vCenter Security Doc. (see doc for more info here, lots of good ideas you can use):

Adding firewall protection to your virtual network by installing and configuring host-based firewalls on some or all of its virtual machines.
Keeping different virtual machine zones within a host on different network segments.

Use separate physical network adapters for virtual machine zones to ensure that the zones are isolated.
Set up virtual local area networks (VLANs) to help safeguard your network.


How can I prevent private data from being disclosed outside of my organization?

This encompasses many security and access control practices companies follow. Generally you'll need to do this at many levels at many places.
There are a lot of Data Loss Prevention software that can help you prevent information theft.
A quick comparison is here.

To quickly answer your question, these are the things you'd normally want to do:

Remove write access to all media on corporate workstations, which includes USB and optical drives
Audit emails, both personal and official for attachments. There are software that can help you do this.

You can even intercept personal emails (gmail, yahoo) by playing MITM. Yes, companies do that !

Devise sophisticated snort/sourcefire rules to flag and trigger alerts when anything you think that is proprietary leaves your network.
No ssh/shell access to internal machines from outside the corporate network (specially internet).
Ban outgoing ssh, ftp connections as well. Remember banning outgoing traffic to corresponding ports(22, 21) won't help (one can run her home ssh server on port 80).
Access control: have a solid privileging system in your organization where restricted resources are accessible only to a set of authorized people.

Again this is not comprehensive. Lot of specifics depend on your network/organization/policies.
Basically you should spend a lot of focus on minimizing the exposure of sensitive data to a extremely small set of people.

There are a lots of ways data can be infiltrated. Someone can just upload a couple pictures to her picasa album and effectively steal lots of code. No IDS/surveillance  will be able to stop that. But proper controls and checks at all places can definitely reduce such occurrences.


What precautions/training do companies have against social engineering strategies?

There are "script books" for this, either used in operator training or even kept on the operator's desk when they answer. They detail what you can say, what you must provide, and what the operator can do in any conceivable circumstance.

In this case the T-Mobile operator would ask for some kind of proof among those listed in their script book. The attacker either can supply it or he can't. I have seen such a script book for one of my country's providers, and if you asked, say, for a PIN reset or a new SIM, you'd be either directed to a point of sale where they would ask your ID, or requested to send them through fax or email.

As a routine precaution, at semi-regular intervals (I am not aware of this being done by telecom providers, but I saw it done in more sensitive customer care contexts) a fake customer would call with a two-handkerchief sob story, doing his/her damnedest to convince the operator to help him/her. If he/she succeeded, the next day the operator would have been called by management for an uncomfortable discussion on security rules.

This had two purposes: to be sure that the operators were proof against at least some attacks; and to harden them against said attacks, because even if they did not suspect it was a social engineering attack, they would still suspect it was the management testing them.

Personal story: I was in the habit, waaay back in the days, of sending employees emails with executable attachments that sounded a bullhorn WAV, displayed "SUCKER!" on screen, and sent me back confirmation of a "hit". One day, I overheard unseen a colleague asking, "I've just received an attachment called QJWFWKEK.EXE, what do I do?" - and while thinking "Oh no, he got a real one - and what a moron to ask what to do!", I heard his mate cry, "For Pete's sake do not click on it! Delete it immediately! It's surely one of those fucking traps Serni keeps sending us!"


How does the "post/redirect/get pattern" improve security?

It's mostly a usability issue and not a security issue.

POST-REDIRECT-GET (RPG) is there to stop the client from submitting the same form 2 times by error when he tries to reload the page for example.

Also, if the client try to navigate to a previous page that is a POST, the browser will often display a blank page which is a poor user experience. By adding the REDIRECT-GET, you won't get this blank page issue.

I don't think it's related in any way to the security of the application as it won't let you do something that you are not supposed to do if you only use POST.

Note

You seem to worry about Man-in-the-middle attack and request hijack, but if you have those kind of problems it's already game over RPG or not. So, if those things are the issue, I would suggest to use https.


How to know when a pen test is complete?

So this is actually a very interesting question for the industry in general.  The way I would suggest you handle it is

Have something in your contract that disclaims liability for vulnerabilities not noted during testing. Reason for this is, it's basically impossible to be sure that you've found every exploitable issue in a website, or any other system.  To pick one example, think of all the sites that were sitting vulnerable to shellshock for years and years, should all the pen test companies who touched one of those sites be liable for not telling their customers?
Have a methodology, saying what you will do. This should cover the general areas of testing that will be completed.  For websites, consider basing on something like the OWASP Top 10 as a starting point. This gives you some common ground with the customer on what you'll be looking at.
Make sure your company covers the basics with a checklist.  as @rapli says above document all the little things, but don't overblow the severity. Whilst it's important to make sure your test isn't just a checklist, using one can avoid embarassing mistakes where basic tests get missed.

The problem you might/will run into is unrealistic expectations from customers.  that one is a case by case to address.  If you get a customer that expects that their complex application will be completely reviewed in like 5 person-days of testing, well you should explain why that's not a practical concept :)


It's technically possible to infect firmware, but difficult. It happened in some attacks by state actors. edit: UEFI rootkits generally require privileged access to install.

Since whatever malware you got just broke your OS, rather than do something worse (spy on you or encrypt your files for ransom), it's extremely unlikely that it's been created by someone competent enough to attack firmware.

Assuming your firmware hasn't been compromised (more than 99% likely), you just need to format the drive and reinstall the OS, which you've done. A more paranoid option would be to reinitialize the disk to make sure the GPT is clean (one of the tools that does it is Secure Erase). However, Secure Boot is supposed to protect against exactly such GPT bootkits.

As for how to prevent this from repeating, just follow best security practices. Work under a non-admin account, open random files using Word's default read-only mode or not at all, keep some defensive software running.


Why TCP port 6666 and port 7777 open in a LTE router?

In most situations, I would recommend trying to remote into the system, and see if you can see what processes are listening on those ports.  That would give you the best idea of what is going on in the system (i.e. which processes are bound to those ports).

Since that does not appear to be an option for you, my next suggestion would be to monitor all traffic which is going into those ports using Wireshark or a similar protocol analyzer.  You might be able to determine what those ports are doing based on the traffic going to them, and may even be able to capture some login credentials.

Given the fact that this is an LTE router, and you may not be able to perform a capture on those ports, my last suggestion would be to see if you can download a copy of the router's firmware from the internet. You can then analyze the firmware with a tool like binwalk. This is not a very reliable method, since there is no guarantee that the firmware on your router will match what was downloaded, but if you can't find those ports open on the downloaded image, you know something is odd about the firmware running on your router.


There is no differences, as exploit is an alias to run:

Auxiliary Commands
==================

    Command       Description
    -------       -----------
    check         Check to see if a target is vulnerable
    exploit       This is an alias for the run command
    pry           Open a Pry session on the current module
    rcheck        Reloads the module and checks if the target is vulnerable
    recheck       This is an alias for the rcheck command
    reload        Reloads the auxiliary module
    rerun         Reloads and launches the auxiliary module
    rexploit      This is an alias for the rerun command
    run           Launches the auxiliary module

... and:

> help exploit
Usage: run [options]

Launches an auxiliary module.
...

like:
    rexploit is an alias for the rerun command.


Can I throw away a private key and use the public key like a hash function?

A very "easy" problem about (any) transport encryption of passwords:

Sending it in plaintext over HTTP, of course any sniffer can read it, and use it to login.
Sending plaintext over HTTPS (where all data is encrypted, not just the password alone) is already ok.
Sending encrypted password within HTTPS offers no benefit.
And encrypted passwords over HTTP (and the server expects it encrypted): There you still have the problem that a sniffer can read the encrypted password, send it to the server himself, and successfully log in.

So, tell me, why are you encrypting passwords during transfer?

About your combination of public keys, with RSA-OAEP etc. this just won't work (if you have never heard of OAEP, you should just know that plain RSA is not secure).

There are other problems, but these two alone make your scheme useless already.


If the attacker have control of your wifi router he/she just need to capture the traffic with tcpdump on the corresponding network device.


How can I test my web application for timing attacks?

Timing attacks, race condition (CWE-362) vulnerabilities are not very common for web-applications, these are primarily problems of more low-level languages. For example, in CVE-2006-5178,
race condition was due to incorrect implementation in PHP interpreter itself. But application relying on those functions goes vulnerable too.

It could be daunting to attempt to reproduce such vulnerability, due to timing issues and the needs of specific environment. With automated vulnerability scanners it is not feasible to conduct such test - even for human it is not easy to find such vulnerability.

To my opinion, developer just needs to keep in mind when the main process can be interrupted. Atomicity should be provided when the sequence of actions must not be interruptible. Mainly database actions are susceptible to such attacks. Even when DBMS supports transactions and provides means for safe synchronization, there can be more global actions that are under control of DBMS to make them atomic. Attention should be pointed also to situations where threads are used.

In the link to CWE-362, there are list of papers that are useful to read. Those would provide much more information than I have given here.


Why is the Key Derivation Function important?

"the only thing that is important to get in order to decrypt an encrypted file": I think this is where you go wrong in your reflection, if I can say so.

The only thing which is important is not for you to decrypt your encrypted file, but it is to prevent other to decrypt it by guessing your password.

Therefore, a good key derivation function will make it computationally hard and slow to derive a key from your password so relatively few different key candidates can be tested by an attacker over time. The answer you link mentions that GPG implements this by using a large number of iterations to derive the actual key from the password.

If the key derivation function does not take this precaution, then an attacker will be able to test a very high number of password candidates very quickly (the answer you link states "several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU)", at this speed one can expect to cover all 8 alphanumeric characters strings in easily less than an hour, so the password does not even need to be a guessable dictionary word to be crackable).


I think I have found a satisfactory answer (for me) from ISC directly (didn't seem to be able to find this easily on google though!)

https://kb.isc.org/docs/bind-best-practices-authoritative

  Do not combine authoritative and recursive nameserver functions --
  have each function performed by separate server sets. This advice
  primarily concerns separation of public-facing authoritative services
  from internal client-facing recursive services - administrators may,
  for convenience, choose to serve some internal-only zones
  authoritatively from their recursive servers, having determined that
  the benefit outweighs any risks associated with this policy.

  If you share recursive and authoritative functions in the one server,
  then if there is a problem that impacts authoritative servers only -
  for example, that causes all of your authoritative servers to fail -
  it will break your recursive service too.

I'll leave this here in case it helps anyone else, or if there is anything else others want to add:)


User can't navigate to webpage through the UI due to permissions, but are able to navigate to page by pasting the URL. How do I protect against this?

Do I need to verify the user for every single page?

Absolutely. Not only every page, but every request to a privileged resource, e.g POST request to update data, delete, view, etc, etc. It is not just about viewing the pages, it is about controlling who can do what on your system.

It sounds like your entire authentication and permissions system is broken in its current implementation. The steps to remedy this are too broad for this one answer. It would be worth a general search of this forum and the wider net to find solutions suitable for your framework (JSP, ASP.Net, PHP, etc.). Most frameworks have out-of-the-box functionality for solving this problem.

A good start would be this high level guide from OWASP: Operational Security: Administrative Interfaces.


Anyone can compromise the DNS request authority chain (true).

Not true on a global scale but true inside a network you kind of control. This might be a network with weak security (i.e. typical free hotspots). Or it might be a network where you own the router or similar. There are countries where this kind of control is done on a state wide scale.

  Anyone can generate a custom priv/pub key (true).

Yes, this is trivial.

  Anyone can request (purchase) a certificate on behalf on any domain name (true?)

Not really true. In theory you cannot do this. In practice you might be able to do this by hacking a CA or by exploiting bugs in the CA. Such things already happened too often.

In theory there could be a log file where the CA log all the certificates they issue so that anybody could check. In practice this certificate transparency log exists mostly for the EV certificates only, i.e. the expensive ones with the green bar. And I doubt that someone will (quickly) notice if some small unknown domain gets compromised.

  Is there any way to MitM like my friend said? Or what am I missing?

Lots of important domains are protected by certificate transparency (EV certificates) and/or by public key (pre-)pinning (HPKP). For smaller domains the situation is worse.

And depending on the environment where you work and live SSL interception might even be done on a more global scale. It is very common for work environments to monitor traffic for security reasons (malware can be delivered with https too!) and such monitoring can be done also at a state wide scale if the government has a tight control. Users need to install a proxy CA to make this monitoring possible but in companies this can usually be done automatically and state wide you either use the government sponsored browser or have to install this proxy CA yourself, because you want be able to access the sites without.

In summary: MITM is possible and is done in practice. But while there are criminal MITM attacks most MITM is the (more or less) legal for of SSL interception "for your own good" (they say). And for the legal interception they don't need these attacks.


How to force clients to connect to WiFi automatically?

You can't simply Force a client, but to trick him!

As long as the device's WiFi is running, it keeps sending probe requests, searching for your previous connected networks. Using some software like airodump-ng, you can easily sniff out those probes.
Then the attacker may create a similar evil twin using the BSSID and ESSID gathered from the previous probes.

So, as the device sees the pre-saved network up again, it re-connects thinking it is the legit network.

However, there is something to be aware of:
Only works with public networks. This does not work with secured networks unless you already know the security phrase.

Important note:
This attack also can be done to pre-saved networks with passphrase, if the passphrase is weak enough to be cracked. steps are:

Create the evil twin networks using the BSSID, ESSID AND the same auth type of the spoofed network "WPA, WPA2 or WEP"
The client will try to connect to the network providing the passphrase challenge
The authentication won't work obviously, but you can sniff the challenge
Using some cracking tool, you can crack the phrase
Re-create the network using the new passphrase

Now the client will connect to the spoofed network even if it has some security level, so it's always a good idea to use a strong phrases!


Is this a secure method for authenticating clients?

What are you trying to achieve ? In particular, why would you create a new RSA key pair ?

You use SSL; that's good. With SSL, the client has some strong guarantee that it talks to the right server, and that what the client will send will be readable only by that server. At that point, just send the user login and password through the tunnel. There is no need to fiddle with timestamps and additional public keys and hashing and whatsnot. SSL is enough.

On the server side, just store a password hash, as a second line of defence (you do not want someone who got a quick peek at the server's database to obtain a full list of valid passwords immediately). But this is on the server and irrelevant for the actual protocol. The protocol is: client connects to server with SSL, client sends login+password in the SSL tunnel, server verifies the password and is happy (or not).

If the SSL protection is not enough for you, then either the client or the server (or both) is under hostile control, and you have bigger worries, and there is nothing more you may do to fix that. Your games with extra keys and hashes and timestamp bring a lot of extra complexity and overhead, for no security benefit.


Should I delete SMS messages containing one-time passwords?

As usual, let's start by defining the threat model: you're worried about someone getting a hold of your phone and looking through your SMS history. But you're not worried about the SMSes being intercepted. That's a bit of an odd security model cause intercepting SMSes is really easy, and stealing your phone and getting through a strong password is relatively hard. But ok.

  Say if the authentication of the site use an insecure algorithm for the one-time password generation. Given enough history of the one-time passwords, someone who manages to retrieve the SMS stored on my phone could derive the next one-time password in the sequence.

Of course I can't guarantee that every site on the internet does OTP properly, but it's a pretty strictly defined standard. See wikipedia/Time-based_One-time_Password (and the more general wikipedia/HOTP). Since this is based on strong cryptographic hash functions, there is no risk of an attacker deriving future values from the past ones. Or if they can, then the hash function would be considered broken and they would retire it in favour of a better one.

It's also possible that a website isn't properly enforcing the "one-time" part of one-time-passwords, but I mean, that's a pretty basic part of implementing an OTP system.


Supplying a password to PBKDF2 in raw binary vs. base64?

Between

key = pbkdf2(binaryPassphrase)

and

key = pbkdf2(base64encode(binaryPassphrase))

there is no difference in amount of security provided. The base64 encoded passphrase is longer input, but it is based on exactly the same amount of entropy and thus offers no additional security.

The pbkdf2 function takes practically same time to execute with either input (unless binaryPassphrase is multiple kilobytes or more). The only significant difference will be that the resulting keys derived will be different.


Is storing sensitive data in files instead of a database safe?

The best measure to do this is to store such file on a directory outside the web root.

Basically, all of the solutions 'solve' the problem, in making the password file not available. Their differences stem on the kind of configuration error that needs to happen for it to break.

Surprisingly, such misconfigurations do happen from time to time, (e.g. when updating or reinstalling a system) and thee solutions simply vary on how robust they are to them. Also, sometimes these configurations are set in .htaccess files, but then a config changed at the server and they were not applied.

Breaks if the web server generated an Index list.
Fails if the piece configuring the web server not to serve .secret files was not added/applied, or if an editor left a backup file with an unprotected extension
Would fail if the PHP files were not being interpreted (mod_php not loaded?) or if the password was not changed from the default.
Would also fail if the PHP files were not being interpreted

Placing the file outside the web root (eg. /etc/php-app/hashed_passwords.txt) makes it harder that it gets downloaded by a malicious actor.

Obviously, nothing stops you from combining several of these methods (although at some point that would win you little).

Note: if using the .php route, you shall make sure that a malicious user cannot insert code into the generated files, leading to a code execution vulnerability. Generally this means you will die at the beginning (e.g. starting the file with <?php die(1);). You may also use __halt_compiler to ensure that no part of the rest of the file is interpreted by PHP.

The main difference I see on using files vs connecting to a database server (note you would face the same dilemma of how to name the file if you used SQlite) would be on its robustness for race conditions. Suppose that a user is performing a change password action at the same time that another one is signing up. A naive implementation using files would be vulnerable to a race condition where the recently created user would be lost when replacing the file with the new password hash, whereas a database would automatically care take of that (a naive implementation would be vulnerable to SQL injection, though).

Other differences would be at permissions, backups and scalability:

If the app connects to a database, the code itself could be read-only at the filesystem, whereas the files with information stored need write access there (and if you are using .php files, they need to be able to write into a file where code could be executed if written into, so a file-writing vulnerability would automatically become an execution vulnerability).
If there is already a system in place to backup the database server, that is easiest, rather than having to do a custom backup of a weirdly named file. On the other hand, using a file means that simply copying the directory results in a full backup, no need to dump the db separately.
If you may end up scaling horizontally, it is better to go with a normal database. Often simply making several nodes point to the same database make them all work  (you should share the sessions, too). If you used a file database, that means you would have to share that file (by nfs, perhaps?) and have it writable by the multiple nodes (with all the added complication of race conditions, just with more nodes and a less capable filesystem layer).

And obviously, running a database server imposes certain overhead. If there isn't already a need to be using one, and the server resources are constrained, it may be preferable to use files simply to be lighter.

As you see, mostly the reasons that would lead your decision of using a file vs a database server are not about security, since you could have an equivalently secure app in both cases.


How to verify the checksum of a downloaded file (pgp, sha, etc.)?

Usually this would start on the owners side displaying the checksum for the file that you wish to download. Which would look something like the following:

md5: ba411cafee2f0f702572369da0b765e2

sha256: 2e17b6c1df874c4ef3a295889ba8dd7170bc5620606be9b7c14192c1b3c567aa

Now depending on what operating system you are using, once you have downloaded the required file you can compute a hash of it. First navigate to the directory of the file you downloaded, than:

Windows

CertUtil -hashfile filename MD5 / CertUtil -hashfile filename SHA256

Linux

md5sum filename / sha256sum filename

MacOS

md5 filename / shasum -a 256 filename

The issue that comes with checking a hash from a website is that it doesn't determine that the file is safe to download, just that what you have downloaded is the correct file, byte for byte. If the website has been compromised then you could be shown the hash for a different file, which in turn could be malicious.


Client reconnects during deauthentication attack

It's hard to say exactly what you're seeing, but this is a possible scenario:

Client De-auths
Client sees extra network traffic and changes mode n -> g, or g-> b, etc.
De-auth packets are ignored by client as the client is now in a different mode.

See the end of the doc here: https://www.aircrack-ng.org/doku.php?id=deauthentication

It mentions the problems with deauth packets to devices in different modes. If you can check the logs on your AP, you could validate this was the case.


Securing a Node.js REST API for React.js webapp as well as a standalone API

Welcome to the site, Vipulp!

I am not certain if your requirements allow it (apologies if not), but I would recommend using an existing node.js library to do the heavy lifting for you. Something like passport http://www.passportjs.org/docs/ or the like.

This way you don't need to reinvent the wheel, and are less at risk of missing an edge case or including a bug.


Windows 2003 Enterprise infected by Conficker; post-infection problems continue

Your server has been infected with a virus. Stop trying to hunt down the problem and just nuke it from orbit. Do a full reinstall of your system and restore from a known safe backup point.


Does having 2 or more RFID-enabled cards in a wallet prevent all attacks?

Failure of reading two cards in the field is a result of what happens in anticollision loop. Basically, readers can decide how they handle that situation.

For some applications it makes sense to perform only collision detection (where it is important for the operation context that user consciously selects the card he wants to use in the operation, like when it's payment transaction) and require one card only in the field.

ISO14443 standard allows to resolve such situation and reader can select the card it wishes to talk to and perform the operation, even with all of them.

Answer to your other questions is then that two cards side by side do not counter any attacks. It's simply the usage that defines the necessity to present one.


Does PKCS 1.5 padding make it possible for an attacker to extract the private key or not? Is PKCS 1.5 safe to use in authentication context?

Is it safe to use PKCS 1.5 in this case?

I cannot answer "no" here. But it is recommended to avoid "safe in this case" for any practical purposes. E.g., why would you use RSA encryption if all you care for is protecting the private key (but not the confidentiality of the messages themselves)? Also, if BouncyCastle hasn't fixed that bug already - it's likely to get it fixed soon (have you reported it, by the way?).

  Is it really possible to extract the private key using a padding oracle, or does the padding oracle just allow arbitary message decryption?

No, RSA Padding Oracle just allows arbitrary message decryption (we are not talking about timing attacks, etc.). So the RSA private key is safe in the phone's HSM.

The CRYPTO'12 paper was about applying Padding Oracle to Key Wrapping - a key is "wrapped" (aka RSA-encrypted), passed to the token, and "unwrapped" there (aka decrypted and made ready for use in this token). It doesn't make sense to apply this attack to normal encryption/decryption, because if you have the device (your phone, your cryptographic token) and the PIN - you can tell the device to decrypt whatever ciphertext you got in one request, no need to pry it bit by bit.

Also, would you consider an authentication scheme based on signature rather than decryption?

Update

  The reason I selected a auth scheme based on decryption instead of signatures, is because signatures get huge, as long as the key.

For the RSA encryption the ciphertext is as big as the key (modulus), just like in RSA signature (and for the same reason - that's what padding is for). But I guess it doesn't matter, because it's passed to the phone as a QR scan...?

  But also the system needs to work without any network connectivity for the device, so I have based the system on encrypted QR codes, that decrypt to a simple OTP string, that is entered on server

Based on your comments, you mean that the phone itself may not be connected, i.e., it cannot react to what it QR-scanned. It just displays the result (presumably something fairly short that the user can type easily).

In the use case you describe, I guess it's OK. And your private key is not exposed anyway. Although I wonder how your public key is going to get from the phone to the server that would use it to encrypt that OTP for this specific client (so your phone would need some connectivity at some point in time).


What are some metrics to be used to evaluate SaaS security?

In a SaaS model, you will likely not be able to perform code audits. This is because as stated, it is Software as a Service. Not software where you would be able to download the software itself, let alone the source code for the software. That task would be done at the discretion of the software vendor, and or provider. Please see "5 Problems with SaaS Security"

So I will document issues I have with SaaS, and SaaS Security.

Access - Who is accessing this. Is it just my organization. Is it a
multi-tenant software. Would there be any overlap.
Auditing - How can I audit this at will. Where are the logs stored, how can I modify this to my business (data retention)
Security - while I may not be able to audit code, how can I test for the low hanging fruit (known known vulnerabilities, configuration issues, etc)

Security when it comes down to software you purchase is never your responsibility. When you buy a car, and the automaker tells you they went through (in the US at least) IIHS (Insurance Institute for Highway Safety) testing that established a baseline of safety, have you ever said: "I don't believe them, I need to crash my car for myself to make sure the airbag deploys." Many larger SaaS vendors have security measures, and testing in place. (Google, Microsoft, Salesforce, etc)

So let's put this into an alternative view now. You test the software, find vulnerabilities. So what. Now what. Do you fix them on your own? What makes you think a SaaS provider would allow you to randomly test their software "pre purchase." There has to be some level of trust, and while it can be said: "Trust but verify" in the business world, this is where Service Level Agreements, and Terms of Service agreements come into play to mitigate/transfer the risk.

Many SaaS providers do take security serious for example see Microsoft's stance on this:

  Office 365 and Microsoft Dynamics CRM Online internal monitoring
  includes automated compliance monitoring of infrastructure (e.g.,
  vulnerability scans, penetration testing and testing of process and
  people controls). The Office 365 and Microsoft Dynamics CRM Online
  third-party validation program includes independent audits that are
  conducted on an annual basis to provide verification of Office 365 and
  Microsoft Dynamics CRM Online's security posture.

What exactly is it you are trying to accomplish? Trying to be the security team for a vendor?


Is there a security benefit to requiring a login before and after a captcha test?

This could potentially be an additional protection measure against password-guessing botnets. As far as I can see, it is meant to confuse automated attackers even when they have a CAPTCHA farm, perhaps fooling them into detecting a rejected password attempt, although a correct password was given.

Due to this, it is likely designed to foil everyone except for a human who is highly confident that they have a correct password, which is to say, the authentic user.


How does machine A use the B.key.pub information in conjunction with the B.key information that is presumably presented when ssh'ing from B to A to authenticate that I'm a client allowed to connect?

SSH uses digital signatures. B uses the privatekey (for OpenSSH in B.key) to sign some data including the 'exchange hash' which covers all critical key-exchange parameters including nonces (which function as a challenge) and sends this signature along with the publickey in the AUTHREQ message (type 50). The privatekey is not 'presented' and indeed must never be sent or exposed to anyone else. A, the recipient, does two or three things depending how you count:

checks that the signature verifies for the 'exchange' data using the publickey; the details vary depending on the signature algorithm used, which OpenSSH calls the 'type' (i.e. type RSA uses the RSA algorithm or more exactly RSASSA-PKCS1v1_5; DSS uses the DSA algorithm; ECDSA uses the ECDSA algorithm; Ed25519 uses the Ed25519 algorithm which is an instantiation of the EdDSA algorithm). Since for a nonbroken signature scheme a valid signature can only be created using the privatekey, which should only be possessed by its owner, verifying the signature is considered proof the signature came from the key owner and noone else.

checks that the publickey is configured for the requested username (and the username itself is valid); for OpenSSH this is typically in the file ~/.ssh/authorized_keys but can be changed

OpenSSH, but not necessarily other implementations, also provides for some in-between cases. While a client publickey is not accepted at all if not present in authorized_keys or equivalent, and accepted if simply present, it can also be present in the file file with some option(s) specified for it and then it is accepted but only with conditions or limitations imposed by those option(s). See the man pages for details.

My gut feeling says that the A-host.key and A-host.key.pub come into it in reverse for mutual auth (i.e. client authenticating server as well as server authenticating client when the client initiates a connection, not just server authenticating client), but, where/when has machine B securely received any verifiable evidence to use as a basis for auth'ing A during this process?

Your first part is correct, except the 'mutual' usually focusses on the client side. For SSH, and also for SSL/TLS (which you didn't ask about), the server is essentially always authenticated using publickey cryptography. (Technically both protocols do have other options, but they are almost never used. SSL/TLS embeds the publickey in a certificate, while SSH normally does not, but that doesn't change the crypto significantly.) For both protocols it is technically optional whether and how to authenticate the client -- you can use publickey crypto, you can use something else, or you can not authenticate at all -- thus when we say 'mutual' auth it is usually to clarify or emphasize that the client is authenticated, since that's the only part that varies. In practice SSL/TLS is mostly used in situations, like the public web, where we do NO client auth at the communications level (many websites, e.g. Stack, allow anybody to at least connect but have logins at the application level for at least some content or functionality), while SSH is mostly used in situations where we do want client auth, and doing it at comms level is convenient, so we usually choose between SSH password and SSH publickey authentication of the client.
Yes, you (B) may not have known A's host key in advance. SSH was first developed as a replacement for the BSD 'r' programs (rsh, rcmd, rexec, etc) which were used mostly in what was then called a 'campus' environment and today we call an 'intranet' -- a portion of the network controlled by a single organization. In those environments you indeed could distribute the expected host key(s) out of band, especially for a fairly small and largely static set of servers. For example when you reported to work for a new job your supervisor or admin assistant might give you a PC, a bunch of CDs to install, and a pamphlet containing the names (or IP addresses) and host keys or fingerprints (see below) of the systems your job involved using. However, this often required some effort, so users who were busy, untrained/uncomfortable, or just lazy typically didn't use this check and just accepted any host key, which is (as you imply) insecure. This fairly soon evolved into a compromise called trust on first use where when you first connect you accept whatever key the host sends, but the client then remembers that key (for OpenSSH in ~/.ssh/known_hosts) and on subsequent connections accepts only that key. This helps some because an attacker can only succeed if they are present for, and identify, your first connection, though it is certainly not ideal.
If you want to do better, you might be able to, depending on details. See e.g. https://stackoverflow.com/questions/13791219/ssh-fingerprint-verification-for-amazon-aws-ec2-server-with-ecdsa and https://serverfault.com/questions/581367/amazon-ec2-instance-ssh-rsa-fingerprint -- but contrast (my) https://serverfault.com/questions/996828/how-can-i-confirm-ssh-fingerprint-when-connecting-to-a-new-amazon-ec2-instance-u . Note the fingerprint displayed to you by the ssh program -- and recorded in syslog etc -- is a hash of the actual publickey blob, which is sent in the protocol and stored in known_hosts; if you need to convert you can generally just use ssh-keygen -l but if necessary this can be done by hand and I've seen quite a few Qs or As on doing so, but I don't remember which Stacks; if you need that and can't find them I'll try to add.


In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe mainstream SSL clients implement; namely not announcing RC4 support, unless previous connection attempts with other cipher suites have failed).

One way to look at it is that RC4-protected SSL is way better than no SSL at all. Another way is that whatever you do on the client, the server cannot be abstracted away; you are entrusting the server with your confidential data. The choice of the cipher suite is the server's responsibility, and if the server does not apply appropriate cipher suites (from your point of view) then maybe you should not send the data at all to such a careless server...

Known weaknesses of AES-CBC (the BEAST attack) don't work anymore if your client (Web browser) is up-to-date (and it really should !). Known weaknesses of RC4 don't seem to work in a Web context (because weakness exploitation requires millions of connections, and that takes time -- moreover, the first few hundred bytes of each request contain HTTP headers which are mostly uninteresting to the attacker). So it can be said that: RC4 or not RC4, that is not the question. Whether you disable or enable RC4, this is very unlikely to be the biggest security vulnerability, or even a significant vulnerability.

However, it may make sense to disable RC4, or to disable AES-CBC, in order to comply with some inflexible regulations, or to increase some (very artificial) "security mark" that some auditors seem very fond of, for reasons which have more to do with psychology than cryptography.


Is Bcrypt a hashing algorithm or is my study material wrong?

It's not a good question. You're not wrong to call bcrypt a ‘hashing algorithm’, but they're not wrong that it is qualitatively different from the others—although it is curious that they single out bcrypt and not HMAC too.  We can group them into three categories:

bcrypt is meant to be a password hash, also known as a password-based key derivation function, whose purpose is to be expensive to compute so that even if it doesn't take many trials on average for an adversary to guess what the input was, there's a high cost to testing each guess.  Other examples include PBKDF2, scrypt, and Argon2, and Balloon hash.
MD5, RIPEMD, and SHA are meant to be collision-resistant hashes, whose purpose is to make it hard to find distinct messages that have the same hash.  As it happens, MD5, RIPEMD, SHA-0, and SHA-1 (though not SHA-2 or SHA-3) are all broken—collisions have been reported for all of them.  They're also designed to be preimage-resistant, so that it is hard to find a message having a prescribed hash, and second-preimage-resistant, so that it is hard to find a second message having the same hash as a prescribed message; none of them have had these properties broken.  Other examples—which, unlike MD5, RIPEMD, and SHA-0/SHA-1, are unbroken to this day—include BLAKE2b and SHAKE128.
HMAC is a technique for constructing pseudorandom function families (PRFs) or message authentication codes (MACs) out of certain hash functions like SHA-256; sometimes HMAC is loosely called a ‘keyed hash’, but that doesn't really make it clear what the security goal is, which is unforgeability as a MAC or pseudorandomness as a PRF: if the key is chosen uniformly at random, an adversary who doesn't know the key can't guess the MAC for any message, and can't distinguish the hash of any message from a uniform random bit string.

The word ‘hash’ alone in cryptography just means a function that scrambles its input, or the scrambled output.  There are other kinds of hash functions: the FNV-1 string hash function, sometimes used in hash tables; universal hash families like Poly1305, with guaranteed bounds on collision probabilities, sometimes used to make extremely cheap message authentication codes with high security; key derivation functions like HKDF, used to turn high-entropy but nonuniform bit strings like Diffie–Hellman shared secrets into uniform random bit strings; etc.  It's not wrong to call any of these ‘hashes’, but it may be helpful to use more specific terminology like collision-resistant hash or pseudorandom function family or universal hash family.


Is there a way,even commercial,to get the unencrypted packets in each of the 3 mediums above (Wifi, GSM, Roaming)?

The answer is yes, there is. If you install wireshark on your phone, you will see the packets you send "pre modem." You can think of "roaming" and "GSM" as being like ethernet over cable lines... it's converted to a whole different signal but it's still using TCP/IP on either side of the transmission.

As far as un-encrypted, you have to work out what encryption you have. If you just want to see the packets, go to an unencrypted website. bbc.com is still http on it's homepage. There are many more. If you want to unpack encryption, you can still do that with wireshark for most common (TLS/SSL).  https://support.citrix.com/article/CTX116557

Here are a list of tools for PCAP on mobile, many of which have all the decryption and MITM features you're looking for. https://techwiser.com/wireshark-alternatives-for-android/


Identify a security risk in a car-sharing system

If access to cars is not logged (entering and exiting), you can't say whether one of the users stole it or someone got in by "lockpicking".
If access to cars is not logged, you can't say whether the user, who booked the car, or one of the emergency service people stole the car.
What happens if user does not return the car in time with a legitimate reason, such as traffic jam, cops, etc. Will his access be revoked and he will be unable to return the car? Will he retain the access? Will it be logged? Also special consideration of how to log this with point 6.
Do you store last known GPS location? Do you monitor for outages and what is the response? Do you check the sanity of the data? There are GPS jamers out there.
How is data sent by car authenticated? Can an attacker spoof logs with/without access to the car?
Are access logs to the car nonrepudable, for example by signing the log entry by the smart card? How do you solve exiting the car, extensions of time and other data, where the smart-card may not be available anymore.
Who can monitor the location and use of the cars? For example, could other user spy on a user by checking that he has the car reserved and where the car is? When can the users see the position of the car, as I assume they would need to to know where the car they want to reserve is parked.
What happens if someone reserves a car and does not use it? How do you prevent denial of service by reservation of the cars?
Can someone with access to the car retrieve its crypto keys, or abuse them?


Why are private certificates not trusted?

Generally speaking, you are the one who should decide who you trust and who you do not trust. However, this is a tiresome process; in its infinite wisdom, Microsoft (or Mozilla or Google or...) found it fit to include a set of "default trusted roots" that are used by Internet Explorer (or Firefox or Chrome or...).

In the case of Microsoft, the process by which a given CA may enter the inner circle of "trusted by default on most Windows systems" is called the Windows Root Certificate Program. In a nutshell, Microsoft requires that the would-be root CA applies strict and specific security procedures, and has insurance, and legally guarantees that Microsoft will never be blamed (in a financial way) for any mishap. PKI is only 5% technology, and 95% procedures anyway.

If you do not want to follow the Microsoft (or Mozilla or Google or...) road, you are free to adjust your own set of trusted root CA. That's up to you. However, in any case, as long as you use Windows, you trust Microsoft, in the sense that if they want to betray you then they can easily do it, and you would be none the wiser.

If a root CA is controlled by an enemy, then that enemy can issue fake certificates, allowing it to impersonate Web sites. However, running a fake Web site is not easy if you want to do it discreetly; the client's browser will see the fake certificate, and the framing may thus become apparent. For instance, the site owner may connect to his own Web site, and notice that the certificate apparently used by the server is not the one that he configured. In fact, fake server certificates are crude and suitable for fast cons, active for a few hours; they are not a good method for continuous spying, as is the NSA official job. If the NSA wants to engage in wide-scale eavesdropping on people (and I assume they want to do that; that's what their budget is for), then a much more efficient and discreet method is to add some spying hook directly in the operating system. They just have to talk to Microsoft.


What should I use to encrypt data between a centralized server and multiple devices running NodeJS?

This original answer was to use HTTP/SSL/TLS to encrypt the information between the PHP server and NodeJS client and to use basic authentication in the HTTPS request.
However from the conversation in the comments to this answer the server and clients are already using HTTPS to secure the traffic between the server and the client.

Therefore as long as the NodeJS client trusts the SSL Certificate provided by the server, the communications between the client and server should be secure given all of the caveats of all of the answers to this Information Security question: How safe is SSL?

To be extra safe I found an example in NodeJS HTTPS API documentation that shows you how to have your HTTPS request validate that the server's SSL certificate has the correct SHA256 fingerprint and private key.

const tls = require('tls');
const https = require('https');
const crypto = require('crypto');

function sha256(s) {
  return crypto.createHash('sha256').update(s).digest('base64');
}
const options = {
  hostname: 'github.com',
  port: 443,
  path: '/',
  method: 'GET',
  checkServerIdentity: function(host, cert) {
    // Make sure the certificate is issued to the host we are connected to
    const err = tls.checkServerIdentity(host, cert);
    if (err) {
      return err;
    }

    // Pin the public key, similar to HPKP pin-sha25 pinning
    const pubkey256 = 'pL1+qb9HTMRZJmuC/bB/ZI9d302BYrrqiVuRyW+DGrU=';
    if (sha256(cert.pubkey) !== pubkey256) {
      const msg = 'Certificate verification error: ' +
        `The public key of '${cert.subject.CN}' ('${sha256(cert.pubkey)}') ` +
        `does not match our pinned public key ('${pubkey256}') `;
      return new Error(msg);
    }

    // Pin the exact certificate, rather then the pub key
    const cert256 = '25:FE:39:32:D9:63:8C:8A:FC:A1:9A:29:87:' +
      'D8:3E:4C:1D:98:DB:71:E4:1A:48:03:98:EA:22:6A:BD:8B:93:16';
    if (cert.fingerprint256 !== cert256) {
      const msg = 'Certificate verification error: ' +
      `The certificate of '${cert.subject.CN}' ('${cert.fingerprint256}') ` +
      `does not match our pinned fingerprint ('${cert256}')`;
      return new Error(msg);
    }

    // This loop is informational only.
    // Print the certificate and public key fingerprints of all certs in the
    // chain. Its common to pin the public key of the issuer on the public
    // internet, while pinning the public key of the service in sensitive
    // environments.
    do {
      console.log('Subject Common Name:', cert.subject.CN);
      console.log('  Certificate SHA256 fingerprint:', cert.fingerprint256);

      hash = crypto.createHash('sha256');
      console.log('  Public key ping-sha256:', sha256(cert.pubkey));

      lastprint256 = cert.fingerprint256;
      cert = cert.issuerCertificate;
    } while (cert.fingerprint256 !== lastprint256);

  },
};

options.agent = new https.Agent(options);
const req = https.request(options, (res) => {
  console.log('All OK. Server matched our pinned cert or public key');
  console.log('statusCode:', res.statusCode);
  // Print the HPKP values
  console.log('headers:', res.headers['public-key-pins']);

  res.on('data', (d) => {});
});

req.on('error', (e) => {
  console.error(e.message);
});
req.end();

Here's an example running this program.  The validations failed because the Github SSL certificate changed.  I added displaying the encountered values to the error messages to allow the script to be changed with the current values to validate testing.

pi@rpi1:~/tpf $ node check-cert.js
Certificate verification error: The public key of 'github.com' ('o5oa5F4LbZEfeZ0kXDgmaU2K3sIPYtbQpT3EQLJZquM=') does not match our pinned private key ('pL1+qb9HTMRZJmuC/bB/ZI9d302BYrrqiVuRyW+DGrU=')

Update script to use 'o5oa5F4LbZEfeZ0kXDgmaU2K3sIPYtbQpT3EQLJZquM=' for the private key.

pi@rpi1:~/tpf $ node check-cert.js
Certificate verification error: The certificate of 'github.com' ('31:11:50:0C:4A:66:01:2C:DA:E3:33:EC:3F:CA:1C:9D:DE:45:C9:54:44:0E:7E:E4:13:71:6B:FF:36:63:C0:74') does not match our pinned fingerprint ('25:FE:39:32:D9:63:8C:8A:FC:A1:9A:29:87:D8:3E:4C:1D:98:DB:71:E4:1A:48:03:98:EA:22:6A:BD:8B:93:16')

Update script to use the displayed fingerprint which allows the script to continue and display all of the certificates in the chain provided.

pi@rpi1:~/tpf $ node check-cert.js
Subject Common Name: github.com
  Certificate SHA256 fingerprint: 31:11:50:0C:4A:66:01:2C:DA:E3:33:EC:3F:CA:1C:9D:DE:45:C9:54:44:0E:7E:E4:13:71:6B:FF:36:63:C0:74
  Public key ping-sha256: o5oa5F4LbZEfeZ0kXDgmaU2K3sIPYtbQpT3EQLJZquM=
Subject Common Name: DigiCert SHA2 Extended Validation Server CA
  Certificate SHA256 fingerprint: 40:3E:06:2A:26:53:05:91:13:28:5B:AF:80:A0:D4:AE:42:2C:84:8C:9F:78:FA:D0:1F:C9:4B:C5:B8:7F:EF:1A
  Public key ping-sha256: RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho=
Subject Common Name: DigiCert High Assurance EV Root CA
  Certificate SHA256 fingerprint: 74:31:E5:F4:C3:C1:CE:46:90:77:4F:0B:61:E0:54:40:88:3B:A9:A0:1E:D0:0B:A6:AB:D7:80:6E:D3:B1:18:CF
  Public key ping-sha256: WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=
All OK. Server matched our pinned cert or public key
statusCode: 200
headers: undefined


Bank issued new credit card as a 'safety measure' but 16 digit acount number is the same

What are some reasons why the bank would have replaced the card without issuing a new account number?

Changing account numbers is probably a pain in the ass for them and their systems, and would likely make your life more difficult as well; without having a full aliasing system, statements, billing, etc. would all have to transfer over.  Knowing the quality of software in the financial world, it's unlikely this would be a smooth experience.

While your account number is considered sensitive information, it needs to be combined with the CVV, PIN, or EMV data to make purchases.  Apparently, the bank doesn't believe the likelihood of your card number being stolen and an attacker brute-forcing your new CVV and passing their fraud detection systems to cost them more than the support costs of forcing an account number change.  If we look at that as an equation:

(chance_number_is_stolen * chance_successful_brute_force * chance_pass_fraud) * dollars_lost_to_fraudent_card_usage <= dollars_lost_to_support

it could be that any of the numbers on the left side are smaller than you think, or the number on the right side is larger than you anticipate.

In the end, it almost always comes down to money.


ecryptfs - relationship between passphrase and sig-cache.txt

What stops you from mounting/decrypting the files with knowledge of
  just this key?

The sig-cache.txt is only a signature of the file encryption key.  This means that it is not used at all to decrypt the encrypted volume.  It is only used to verify that the encryption key stored has not been modified or changed.  This is to ensure that the correct key is being used for decryption before actually attempting to decrypt any data.  If only this signature is known it cannot be used to generate the file encryption key in any way.

The ArchLinux Wiki gives an example of how to add a passphrase, and you can see that caching a signature of an encryption key is optional.

However, if an attacker is at the point where they can see this file then it's possible that they are already in a position to request the encryption key from the kernel.  As root access would be necessary for both of these actions.


Are self-signed certificates actually more secure than CA signed certificates now?

There is a subtle point here. In the envisioned situation, there is one (or several) rogue CA who may emit fake certificates for man-in-the-middle attacks. The vulnerability here is not about a server who uses a (genuine) certificate from that rogue CA; it is about the client potentially accepting a certificate from that CA. To protect yourself (as a client) against the rogue CA, you must un-trust that CA (i.e. remove it from your "trusted roots" certificate store). This merely implies that servers that you still wish to talk to should use some other, distinct CA, for their certificates.

In a corporation, producing self-signed certificates and pushing them to all the clients really is a special case of maintaining your own PKI: the corporation produces one or several roots, which have to be installed in all the clients. This is doable; some corporations do just that. But for MitM as discussed here, nothing is gained until the "trusted roots" store of all clients is cleansed from all other, potentially evil CA.

Unfortunately, you cannot necessarily do that. If your operating system is Windows, then there are a lot of signatures used for various components, in particular for updates from Microsoft. You do want to install security fixes, don't you ? You can get away with removing most of the root CA from your "trusted roots", but not all, otherwise to many things will break in your OS.

The conceptual problem is that some OS (in particular Windows) use a centralized mechanism for certificate validation, in which there is one trust store which is deemed appropriate for everything which deals with certificate validation on the machine (in details, there is one "local machine" trust store, common to all users, and one extra trust store per user, but a user cannot "opt out" of the common local machine trust store). You may have better luck with other operating systems such as Linux, which traditionally don't use X.509 certificates for their internal needs, but OpenPGP keys, with a much more decentralized trust system.

The Firefox Web browser, though, uses its own SSL implementation and trust store, separated from that of the base OS. Moreover, Firefox supports profiles, meaning that a user can have several "personas" with Firefox, each with its own settings, including the set of trusted roots. Therefore, a corporation who fears for its data confidentiality could do the following: it could instruct its employees, when they deal with corporate servers, to always use Firefox, with a specific profile which contains only the corporation's own root (or set of self-signed certificates) as "trusted roots".

It is unclear whether the said employees would like it, but it is feasible.

Remember, though, that a powerful attacker is powerful. If that attacker may control "official CA" then it could push a fake update, purportedly signed by Microsoft, which installs a backdoor in every system. Or they could simply ask Microsoft to plant the backdoor themselves. In any case, you don't have much choice: by construction, you must trust the OS and the hardware for not playing foul games on you.


I have asked pretty much the same question for the same reasons and will follow the answers here.
In addition to your question, I would suggest:

I am using macchanger to randomly change the MAC address on each boot.
Using VPN on the mobile device and on the laptop. (ProtonVPN, with the Secure Connection Servers)

Using three browsers, each for different websites (one for banking, another for general browsing and another one for trading)

Restricting cookies and JavaScript, flash, images etc on browsers as much as possible. I Never store history. Deleting browsers cache on the laptop and phone daily.

My Linux is installed on a USB and its encrypted.

My phone has few apps, and I have disabled all google bloat.

I never use the same email twice.

I am still trying to figure out what mail app to use on the laptop, as I will be accessing my accounts a lot, and configuring all protocols and certificates is very important.


Mutual TLS authentication (mTLS) – what can happen if the clients Certification Authority (CA) gets compromised?

What would such certificate be able to achieve, specifically about MITM type attacks?

For Bob, the attacker is Alice. The attacker says he is Alice, and gives him Alice's certificate. He will ask Bob for his certificate, and Bob will give him.

A compromised CA means anything signed by that CA is compromised, and useless. Every single issued certificate could be compromised, and you cannot tell if they are legit or forged. A compromised CA is a devastating error. It can put a public CA out of business. A private CA compromise will lead to lots of all-nights for the support team, but a public CA almost surely will be out of business.

And why would Bob use a self signed certificate? Or both uses self signed certificates, and exchange them only once (in person, maybe), or let both use CA issued certificates. This mix does not look well.


Key size.  All Rijndale (aka. AES) cipher variants operate on the plaintext 128 bits at a time.
No.  Your 64 bits of key data would be expanded to a 128-bit key, either through zero-padding or through a key-derivation function.  It won't be as strong as if you'd provided 128 bits of key data, but that's a different matter.
No.  Your 256 bits of key data will be reduced to a 128-bit key, either through truncation or through a key-derivation function.  Since there's a 128-bit long key that produces the same encryption as your 256 bits of key data, you do not gain any security.