Canadian encryption key sizes I am looking after some legacy software that is compiled with VS2005 which uses .Net 2.0 Rijndael, which fails if the system locale is set to French Canadian. The plaintext is straight ASCII.

I have read that Canada's encryption key limits have been draconian in the past e.g. limited to 64 bit. Does anyone have information where I can get accurate current and historic information about crypto restrictions in Canada?

I can't think of a way to search for your first request. I am not aware of methods of finding software by its compiler.
As to your second question, these are the resources I've found:

The legislative situation in Canada in 2006 - A summary of legislation that was in place back in 2006.

Solicitor General’s Enforcement Standards for Lawful Interception of
Telecommunications from 2008 - A standard describing what the Canadian authorities require from telecommunications solutions.

An article from 2015 that discusses the state of encryption in Canada.

And in this book, chapter IX, page 266 - where he discusses the topic in depth.


What packet parameters should be checked to detect layer-7 DDoS attack? What packet parameters should be checked to detect layer-7 DDoS attack (http flood, slow http request etc.)? Do window size and packet timeline show enough information to detect attack traffic from legitimate traffic? What are the other parameters need to be verified?

could you supply more info.  Parameter's in what app/system?

The things you're talking about (packet features) are layer-3 (packet level) features.

These have nothing to do with whatever's happening at layer 7 (application) level - different things can be happening at the different layers with no relation, and an attack mostly working at layer 7 (like someone spamming, say, a search field in your website) won't necessarily have any defining features at layer3.  If it does, it could likely be easily changed on their side without changing the rest of the attack.


Is BASIC-Auth secure if done over HTTPS? I'm making a REST-API and it's straight forward to do BASIC auth login. Then let HTTPS secure the connection so the password is protected when the api is used.

Can this be considered secure?

There are a few issues with HTTP Basic Auth:

The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
The password is sent repeatedly, for each request. (Larger attack window)
The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.

So, as with anything it's important to look at the whole picture.

Does HTTPS protect the password in transit? Yes.

Is that enough? Usually, no. (I want to say, always no - but it really depends on what your site is and how secure it needs to be.)


Is combining salt from two places secure enough and what length I need to implement some hashing scheme for an open-source project. This is what I currently have and I'd like to hear whether this is secure enough -
The password is hashed using PBKDF2-SHA256 (which I prefer over bcrypt simply because OpenSSL supports it natively) with 2048 iterations.
The salt is actually a concatenation of two strings - the first one is unique and stored in the DB along with the password in plaintext. The second one is shared and stored in plaintext in the program's configuration file. My logic is that this will prevent brute forcing passwords if an attacker gains access to the DB but not to the server's filesystem.
Is this secure? Also how long should each part of the two salt strings be? 16+16 bytes? 32+32 bytes?
Thank you.

That second part of the salt you are talking about actually has its own name - it's called a pepper. And as long as the real salt itself is always unique for each password, adding a pepper doesn't decrease security in any way (it arguably increases it in some scenarios).
Regarding the length of the salt, 16 random bytes* each will be more than enough. Since 16 random bytes is 128 bits of entropy, you can be sure there is practically no chance of your salt ever repeating for more than one password.

*Note that 16 random bytes means 16 random bytes of binary data, not a 16 character string. See Steffen Ullrich's comment


CECPQ1 key exchange functionality CECPQ1 (combined elliptic Curve and Post-Quantum Cryptography Key Exchange) is a new key exhange developed by google, which combine X25519 with NewHope (elliptic Curve KE + Post-quantum KE).

Google has implemented CECPQ1 in boringSSL But there isn't a documentation or clarified explanation, how it works.

Looking at the code, I think, there are two key exchanges - X25519 and NewHope. Results of those exchanges are concatenated (here)
Then this concatenation is fed into KDF and used as session key.

So even if NewHope is broken whole scheme is secure, because X25519 is secure. Attacker must break both NewHope and x25519 to break a scheme.

Can someone confirm that? Or give me more details about CECPQ1?
Like which KDF, it uses? what are the inputs and their sizes? Perhaps if there are any good articles or pdf, that describe well CECPQ1.

According to the code you've linked to X25519 gives the first 32 bytes and NewHope gives the next 32 byte of the pre-master secret. This is also what Wikipedia says about this topic.

  Like which KDF, it uses?

The process of deriving the master secret from the pre-master secret is the same as for the other and more traditional key exchange algorithms and is clearly defined in the TLS 1.2 standard in section 8.1. Computing the Master Secret.


USN Journal leaks information on exFAT-hosted files (in VeraCrypt containers) I'm using a secondary drive to store encrypted files, in VeraCrypt file containers.
Unfortunately, even if the external drive is formatted as exFAT, Windows leaks information on files inside mounted VeraCrypt containers.

The highlighted file has been created inside the external drive-hosted container.
Thus, how can I prevent this without entirely turning off the USN Journaling (if it's even possible...)?

Windows has many default functions that are aimed at common use and support but can become problematic in a privacy/security context.
Not only your example in Journaling, but many other functions may be a concern as well. For example, external drive connections, such as Thumb Drives, often save drive identities and top level directory filenames in shellbags encoded into the registry. This content can persist long after the device is removed.
Once encrypted volumes are unlocked and mounted, all the standard Windows functions apply, including malware scanning, with copy/export if unknown executable, of the contents.
Simply plugging a thumb drive into a Windows machine will result in a hidden directory with a GUID (Globally Unique IDentifier) being written to the drive. To be fair, Mac's do this as well.
Along related privacy/security lines, encrypted PKzip files maintain a clear text list of all of the filenames in the archive. Note that 7zip does not do this.
In short, if you feel you need a higher level of privacy/security, you may want to re-evaluate your choice of operating systems.


Is there a security vulnerability in setting a public DNS entry to a private IP Address? I recently set up a wireguard server-network configuration with a home server and client devices. I have one main domain that I hope to route everything through via subdomains (in this example, abc.example.com, def.example.com, etc.). I hope to use nginx to do this routing.
Is is possible/secure/recommended to register a private IP address (specifically of my home server within the wireguard network, i.e. 10.27.0.1/24) in a public DNS (e.g. google DNS), so that if you run ping abc.example.com you would get back 10.27.0.1? I found a few questions that answer a question that are close to this one (this one covers private IP for public DNS for MX records, this one talks about having A records without much mention of VPN), and the overall picture I get from these links is that it is possible, but not technically perfect since a hacker gets a small piece of info about your local network (wireguard network is 10.27.0.1/24...isn't this relatively a moot point given it's behind wireguard, assuming I have all of the usual safety checks in place (no remote ssh (root or otherwise) unless on wireguard network, fail2ban, no password authentication for ssh, etc.)?
This IP (10.27.0.1) would be only accessible through the wireguard network, so I don't think it would expose the services to the internet. I want to do this so that I don't have to setup local DNS entries on each device, as I don't believe this is possible on a phone, and it would be ideal to make one change [i.e. set the DNS entry to 10.27.0.1] and then have each device just running a simple DNS query for abc.example.com. This would also have the added benefit of only opening the wireguard port, and keeping the firewall closed for 80 + 443.
A corollary of this question is how best do you manage certs/ssl if this is possible? I managed to get certbot working by temporarily exposing port 80 on my server to acquire the certs for abc.example.com, and then closing 80 to only access the webserver via wireguard through the wireguard port + nginx. I can already see one downside to this method - having to manually open port 80 everytime certbot wants to get new certificates (I believe by default this is every 60 days). I understand that wireguard is approximately as secure as SSL/HTTPS, but for my personal OCD I would prefer to have the connection secured through https on top of wireguard. I'm somewhat iffy on the details of managing certs for wildcards, but could I do it with my main example.com (that is pointing to a internet facing site) and have it propagate to the subdomains, allowing it to be renewed through that? (this question seems to indicate so)
My goal long term is to expand this into a network that includes family/close friends as a type of 'intranet' for sharing photos and using other self-hosted services.
My nginx config file (abc.conf) looks something like this:
server {

  server_name abc.example.com;
  # DNS Entry of abc.example.com is 10.27.0.1, which is the local IP for the wireguard network
  # SHOULD NOT be accessible outside of wireguard network

  location / {
      proxy_pass http://127.0.0.1:8000; #Redirects to local service on port 8000
  }

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot

    // SSL Certs provided by certbot [removed manually]
    // .
    // .
    // .

}

You can point a domain name to a private IP address.  As a random example, the company I work for has a domain name local.example.com that points to 127.0.0.1.  Not that the details matter much, but it uses this for providing MFA to command line tools - the local application will launch a browser window with our SSO/2FA provider, and the return URL for the login process is local.example.com, which (as mentioned) points to 127.0.0.1.  Before starting this the command line tool temporarily starts up a web server that is only accessible locally (i.e. at 127.0.0.1), and so when the web browser redirects to local.example.com it is redirecting to a web server accessible only on the local machine, and the command line tool uses the web server to extract the necessary access tokens from the SSO provider.
What you're proposing to do is pretty much the same thing.  While I've never attempted your particular use case, I see no reason why it shouldn't work.  I don't believe there are any particular security concerns related to this.
As for how to automate your certificates with certbot, you could do it without opening up your service to the outside world, although it depends on the capabilities of the DNS host.  There are two key points:

The certbot command line tool has options that allow you to inject your own custom scripts into the renewal process
certbot can also prove ownership for issuing certificates by having you create DNS entries for the domain, without needing to connect to a webservice.

Therefore, if your DNS host supports it (the larger ones do), you could imagine attempting this flow:

Adjust certbot to use DNS validation.  In essence, it will request that you create DNS records on your domain with certain values
Use the API of your DNS provider to automatically create these entries
Ask certbot to validate the records.  It will then check for the DNS entries (and happily wait reasonable amounts of time for DNS propagation)
Once the DNS propagates and is verified, certbot will give you your certs

Note that this process is not necessarily as involved as it sounds.  Certbot already has plugins available for many DNS hosts, and you may find near-complete examples of this process online.
The other option would be to run a private DNS server on your local network, and update your network configuration (or the client machines) to point to it.


What policies maximize employee buy-in to security? Security awareness training is a bane to most employees.

A favorite anecdote I have is a group of employees figuring out how to quickly complete their online security awareness training from discovering all the answers in the raw HTML code.

What are good motivating policies to encourage employees to help play good defense?

Social norms. If employees see the managers taking security seriously, it sets a cultural expectation that to get ahead in this company, I must need to take security seriously.


What is a "proof of concept" file to report security issues? Last month I reported a security issue to Adobe through an email encrypted with PGP. I recieved the comfirmation email, but no response past that. I checked the "Alert us" page and it said that you have to send a proof of concept file. In my email, I just said what was wrong and how to get to the exploit. Did I report it the wrong way?

A PoC, or Proof of Concept provides a work example of the vulnerability being exploited. PoCs are provided to give concrete examples of, well, the concept. For example, I can say I have XSS on a web application, I can point to the parameter that is passed in the URL, but the PoC provides a work example of the XSS.

This is important for a few reasons. One, it provides credence to the security claims. Two, it provides those developers who have to find and fix the problem a test case so that they can track down the problem and validate the fix. Three, it's a good use of everybody's time, yours and theirs, to have a PoC.

One thing to keep in mind about PoCs is that they are not full-blown exploits, but an example of what can be done. In the XSS above, a PoC would be alert(document.domain) to show I have control over the DOM. In buffer overflows, a PoC would be getting EIP to point to 41414141.


Official trusted certificated entities I am learning about root certificates entities and I have a few questions about that. As far as I know my browser trust in a root certificates entities and I can find the list in "configuration" > "manage certificates" > "etc":

Can I contrast this list with an official list? I found this about Chrome trusted certificates entities but for example business like Simantec or Let's Encrypt dont appear and are certificates trusted by my browser. What is the reason for that?

The link you provided is not a list of trusted root CAs, but a list of trusted Certificate Transparency logs.

Actual lists of CAs for browsers can be found here. Note that chrome does not have its own list, but uses Windows root certificate store.


Good ways to prevent spammers from registering Possible Duplicate:
  Is there a true alternative to using CAPTCHA images?

Since everyone hates captchas  what are good alternatives? I'm looking to prevent the automated creation of accounts on a website but I'm also concerned about people. If the registration is too easy there would be nothing stopping people from creating accounts haphazardly but at the same time the registration process should be easy. What to do?

The simplest way is to add a hidden input to your form, and refuse to submit the form is that input is filled.

Another efficient way to do this is to generate a token cookie, store its value inside a hidden input, and compare both of form submission. Since most spambot can't handle JS, it won't work for them.


Detect referer check on redirect I have a section of my web site that I only want reachable from another portion of my web site. I know that referer spoofing is trivially easy. But, if all requests from an incorrect referrer are met with 303 redirects to an index page, is there any way for the client to determine that the referrer is the criteria on which they are being denied, or even that there is anything for them to be denied from?

In other words, could this be sufficient protection from bots or individuals without a specific target in mind? I realize this qualifies as security through obscurity, but in this case I'm not expecting targeted attacks, and I don't see how you would discover it from outside.

If it makes any difference, the redirect is being sent by nginx.

Referer restrictions are common enough that it's one of the first things an attacker will guess when trying to figure out why they entered one URL and got a different one, especially if they know the URL is supposed to work (say, because a friend sent them the link).

No, there is no way to know that an incorrect referer is the cause of the redirect, but it's easy to guess.


Making a offline GNUPG2-key - should I make Master-key S&E or S only? I want to make an offline-key in GNUPG2 - ie. a "Master-key" to which I'll add one or more sub-keys for daily use, before storing the whole thing on an USB.  I will then remove the secret part of the Master, thus having a very limited key on my computer - while still being able to use the sub-keys.

1) Is it better (safer... less confusing...) to make the Master-key Sign (and Certify) only - eg. by using "RSA (sign only)"... or must/should I make it both Sign (and Certify) and Encrypt - eg. RSA and RSA ?  Is Sign&C-Only more secure or doesn't it matter?

2) I'll definitively add an Encryption sub-key - but should/must I add a Sign sub-key too?  ...Or could I just use the (full!) Master-key too sign stuff?  (It would be a bother perhaps, but lets say I very rarely signed my files/mails...)

Is it better (safer... less confusing...) to make the Master-key Sign (and Certify) only - eg. by using "RSA (sign only)"... or must/should I make it both Sign (and Certify) and Encrypt - eg. RSA and RSA ? Is Sign&C-Only more secure or doesn't it matter?

You only need to create a master signing key. The purpose of the master signing key is nothing more than to sign other keypairs which you use as your subkeys. Because of this, there is nothing you will ever need to encrypt using your master key. Security-wise, it doesn't matter if you create a master encryption key because you'll never use it, but it's unnecessary and kind of sloppy.

  I'll definitively add an Encryption sub-key - but should/must I add a Sign sub-key too? ...Or could I just use the (full!) Master-key too sign stuff? (It would be a bother perhaps, but lets say I very rarely signed my files/mails...)

You do need to add a signing subkey as well, not just one for encryption! The purpose of keeping a master key offline is to avoid using it excessively in situations where it might get stolen. Signing everything with your master signing key completely defeats the purpose of keeping it offline, even if you sign things only rarely. The only time you should ever use (or even access) your master key is when you are generating new subkeys and need to sign them. As such, you need to generate a keypair with both encryption and signing subkeys, and sign that using the master key.

Note that there are secure smartcards you can get which can store your master key in an encrypted form and sign subkeys without you ever needing to put the secret key on your computer, just by plugging in the device. I suggest you look into one of those to help with managing your keys.


What are the security benefits or risks of HTTP/2? Since HTTP/2 is starting to get adopted by more and more sites everyday. Are there any security benefits or known risks regarding HTTP/2?

RFC 7540 Section 10 is a security consideration section that documents a number of security considerations when implementing and/or using HTTP/2. Briefly:

  10.1.  Server Authority
  10.2.  Cross-Protocol Attacks
  10.3.  Intermediary Encapsulation Attacks
  10.4. Cacheability of Pushed Responses
  10.5. Denial-of-Service Considerations
  10.5.1. Limits on Header Block Size
  10.5.2. CONNECT Issues
  10.6. Use of Compression
  10.7. Use of Padding
  10.8. Privacy Considerations

Most of the regular security considerations for HTTP/1 are also still valid, as HTTP/2 has the same application level semantic as HTTP/1.


Why doesn't SSH use a better algorithm for encrypting keys? According to the answers in this question, SSH still uses a very basic algorithm for encrypting keys with a passphrase, which can be attacked at a rate of billions tries per second using dedicated hardware.

Better password protection schemes have been known for a while. Given how popular SSH is and how critical it is to the security of many organizations, I'm wondering why nobody seems to care about this problem?

This is a difficult question to answer, since there's no technical reason why this is true, so you have to speculate why the developers haven't chosen to address the problem.

There's a couple of possibilities, but mainly it's one of compatibility.  SSH is 20 years old now, and has had a stable format for key storage for a long time.  If you suddenly changed that and made brute force attacks far more difficult, you'd break compatibility.  Everyone hates breaking backwards compatibility, so you'd better have a good reason to do it when you do.

Also, consider that the ssh key format is around 20 years old now.  That's 20 years of Moore's law.  In 1995 a high end computer was a pentium 133.  In 2015 we have multi core processors running at 1.8 ghz.

If you look at code cracking speeds of 1995 vs 2015 for RC5, you'll see 246,000 crypts/sec for a Pentium 133 in 1995, vs  6.1 billion for a modern Athlon multi-core processor.  That's 25,000 times faster.  So you can see why when the standards were created 20 years ago brute forcing passwords wasn't as much of a concern.  Obviously it is now, but backwards compatibility makes the switch not as easy to simply create it.

The other reason is that people consider private keys to be something that attackers don't have access too, and can be kept "safe".  If discovered, they can be replaced.  That's probably more of a bias towards believing that keys can be kept safe, and discovered if stolen, despite many break-ins being discovered long after they happened.

Ultimately there's no good technical reason why a better key derivation algorithm couldn't be adopted, it's more likely that nobody has made a stink about it in the SSH world.  That's normally how long lived standards get changed.

TL;DR Increased brute force speed in the past 20 years has made passwords require more and more entropy.  Using better techniques to generate passwords from can mitigate the vastly faster CPUs we now have, but the need for backwards compatibility has delayed moving towards better password deviation techniques.


How and in what context CSR works? I'm trying to understand scenario under which CSR (certificate signing request) can be useful. Please help me understand the concept and use.

  Mutual authentication

In client side authentication, where a client generates a CSR to be signed by server trusted root CA. The result be a client public certificate, which can be used by server to authenticate client by encrypting its session key using client public key.

  MITM i.e SSL proxy

The goal, it to view all outbound SSL traffic going to external resources e.g twitter , facebook etc. Have the SSL-appliance on-board CA authority generate public-private key pair, generate CSR request and have it signed by a trusted root authority e.g verisign. So, when client request to access a ssl website, the ssl proxy passes the SSL proxy server certificate which be accepted by user local browser since its signed by local CA, From SSL to target server, we will use CSR approved public certificate to encrypt session key for use by target sever.

I know the above description just describe a very vague high level overview of the process. I just wanted to understand the high level concept involved.

A CSR allows a user to get a certificate authority (CA) to give them a signed certificate, without the CA actually knowing the user's private key. An X.509 cert has a few major pieces: the subject (who the cert is for), the cert's validity period, the cert's allowed uses, the subject's public key, and the issuer's signature (that is, a signature generated using the issue's private key, where the issuer is generally a CA). A CSR has most of that info, except it lacks the issuer cert (because it's generated by the user - who is usually the subject - and sent to the issuer, so it can't have the issuer's signature on it yet). The CA signs the CSR, turning it from a certificate signing request into a signed certificate.

The neat thing is, in order to do this, the issuer never has to see the subject's private key, just the public one (which is, of course, public). The user needs to have a corresponding private key for the public key they submit, or they wouldn't be able to use the returned certificate for anything, but the issuer (that is to say, the CA) doesn't have to know what that private key is.

This is a better alternative to the simple, naïve approach, which would be the issuer generating the public-private key pair themselves, then building a cert with that public key, signing it, and sending both the cert and the private key to the user. The problems with doing that:

The CA would know your private key, at least until they forgot/erased it. Ideally, nobody else should ever know your private key.
The private key would need to be transmitted very securely (so that a third party couldn't intercept it); this is hard. Better to just never transmit it at all.
The user may want to generate the key a particular way, for example using a random number generator that they trust to be particularly good, rather than relying on the CA to produce an acceptable quality of key. (You have to expect that others will trust the CA's master key - otherwise their signature on your cert is meaningless - but you shouldn't have to trust them to actually generate your key properly.)
The user may want to re-use an existing public key, for example to keep old signatures valid if an existing certificate would expire but the key is believed to still be safe. Using a CSR, you can basically get a certificate re-issued with new validity period, allowed uses (OIDs), etc. even if you don't update the key.

CSRs are what make it possible to avoid all of these problems.


What devices support the permanent addition of an ARP table entry? What tools are available to manage this? I would like to improve wireless security and certain other on-net security scenarios with a permanent ARP table entry.  The idea being that someone on the same subnet or WiFi network will have a more difficult time spoofing my access point.

What clients support / don't support the feature of a permanent ARP entry?

How can I centralize the configuration, deployment and updates of this configuration?

"Static" ARP entries is the more commonly used term than "Permanent"; you should know this if you're Googling and the like.

Static ARP entries do provide protection against ARP poisoning / spoofing.  However, someone in a position to perform ARP spoofing can also perform MAC spoofing to achieve close to the same effect, and overcome the obstacle that a static ARP entry presents.  This reduces the relative value of putting this protection into place.

Under both Windows and Unix, static arp entries are configured using the command line tool 'arp' which is often called from a script, as @chris points out.  You will not find an easy distributed management mechanism like, say, Group Policy to do it for you.  Unless you've already got a tool in place for centralized configuration (puppet, cfengine, BladeLogic) you're stuck with manual work, another reason this protection isn't as attractive as one might like.

In my opinion, static ARP entries are a low-level security step which has limited advantages, whose management is troublesome, and whose over-riding of the way a dynamic network works will turn around and bite you in the MAC at some point.  There are better places to spend your time and energy.


Is browser side encryption realistically secure? I have a web app I'm hoping to write where a selection of files are zipped and encrypted in the browser before being uploaded to my server. I have a prototype of the system and it's working great. I want to do it in the browser with NO server involvement when handling the unencrypted files for privacy sake.

The general process is:

The user selects local files on their computer
Zip those files together
Generate a key
Encrypt the zip with key
Upload encrypted zip to server (this is verifiably the first network usage after page load)

My goal is to know as little as possible about the uploaded package. Zipping means I don't know how many files there are and because the keys are all managed client side there is absolutely no way I should be able to decrypt the package. My service is all about storage so I never need to transmit the key anywhere. The key is available to the user for them to personally manage.

I realize that using javascript security allows my clients to manipulate values in order to cripple security but because they're only capable of modifying code that impacts them a user can only weaken the security on packages they upload. I'm assuming a user actively going out of their way to shoot themselves in the foot is not a problem I need to attempt to prevent.

MITM seems like a possibility. Eve could manipulate the requested JS files to remove encryption and an unencrypted package could be retrieved by Eve during the upload but I don't think this presents any new problem over a system where the package is sent to my server and then encrypted. HTTPS and a well educated user can help prevent a MITM from succeeding as well. "Well educated user" might be a pipe dream, but I can do my part to attempt to educate my users before the process starts.

The last and so far worst issue that's come to mind is the possibility of a malicious browser extension. It could manipulate the JS to remove encryption but the upload would still be secure using a forced HTTPS connection (the server can reject non-secure uploads). Since I read in files using Javascript's FileReader API, a malicious extension could intercept the unencrypted blob and upload it to a third party. How could I possibly defend against something like that? I know my site and servers haven't been breached but this is still a huge loss to my clients. Can anything be done about this?

If the connection with the server is 100% HTTPS enforced then what kind of attacks could target a system like this? Are there issues I haven't thought of that I need to prepare for? What can I do to ensure security as well as privacy?

What you are proposing is the same architecture that is used in online password managers like Lastpass and online Bitcoin wallets like Blockchain. You have named the two big threats: Javascript tampering and a compromised computer.

You deal with the threat of Javascript tampering by securing the server and convincing the users that your Javascript is secure.

Regarding malicious browser extensions or other malicious code on the computer, you can't do much about that. You have to leave it up to your users to ensure that their computer is secure.


Should HSTS header be sent on an error response? We need to configure our loadbalancer to send the HSTS header and we are debating whether or not to send the header on HTTP 4xx/5xx responses. Our main concern is application layer DDos attacks. We don't want to do the extra work of inserting the header in case an attacker starts targetting us with HTTP 404 or some other error response code. What is the right way to do this?

It would be wise to always force the HTTP Strict Transport Security (HSTS) header because the risk of not encrypting may be worse.

In this particular case it's a direct tradeoff between confidentiality and availability. For most but not all businesses confidentiality is more important.

If your business values the confidentiality more than availability then force HSTS if availability is more important then don't.

HSTS is also especially useful if your development teams are prone to poor security configurations on the servers behind the load balancer. HSTS allows an organization to enforce https which in general is a very good thing.

Note: In general there's also a hidden benefit to doing this on the load-balancer rather than at the webserver layer. If the load-balancer is responding with the HSTS header it's actually reducing some of the load off the systems behind it and reducing the round-trip page loading of the site to the https page. This reduces the load on the webserver a small amount and for some attacks this actually INCREASES the workload on the attacker.

For reference:
https://tools.ietf.org/html/rfc6797


Security of JVM for Server Using type- and memory-safe languages like Java and Scala for server applications gave me the confidence of having a basic level of security (e.g. compared to C). Now with the recent wave of Oracle Java vulnerabilities I noticed that most of them apply for applets in web-browsers and only a minority of them apply to servers. However, is JVM in general (still) a good choice for high secure server applications? Are other JVMs (e.g. from IBM) more secure than Oracle's for this purpose?

I'm not asking on applets, web browser, desktops but am only interested in server's security.

Java is fine for servers. The security issues with Java are actually issues with the Java applet model, in which your JVM (in your browser) is meant to run potentially hostile code (i.e. code "from the Web") and yet somehow prevent that hostile code from doing bad thing. The applet model is a bit like running the applet code in a virtual machine, except that the isolation layer is done with the language itself and with safeguards in the standard library. It turns out that trying to do a sandbox that way is very hard, because you have to include explicit controls in every potentially dangerous library class and method, and there are thousands of these. All the Java vulnerabilities which have hit the news in the last years are about that: some standard library code which did not filter calls with enough robustness, in case the caller is an hostile applet.

None of this applies to Java on a server. On a server, that's your code, presumed non-hostile, and with full access to the standard library. Running Java code on your server is no worse (for security) than running C or C++ code; actually it is arguably better because the inherent protections of the Java language (garbage-collector based memory management, strong types and array bounds checks) make it more robust with regards to some categories of bugs like buffer overflows. Namely, consequences of a buffer overflow are more constrained (the buffer is not actually overflowed; an exception is thrown instead), and the GC allows for much easier handling of character strings, something which is a fertile source of buffer overflows when writing C code.

The same reasoning applies to .NET and its various languages (C#, VB...).


Secure WebApp authentication I know there are many questions about hashing passwords on the client side out there, but none of them, which I found, address my use case.

My app will be end-to-end-encrypted and it is not an option to send the actual user password to my server. I have to hash the password on client side.

After hours of research I decided to use PBKDF2 with SHA256, but I am confused. It seems that PBKDF2 needs a salt.

I want to use the implementations from crypto-js, because I did not find other implementations for PBKDF2.

How should I generate the salt for PBKDF2? The resulting hash has to be the same for every run, because it will be the users password from the application servers perspective.

Could you additionally provide some reference code or project, where this is being done?

(The hashing is not intended to prevent MITM, but to prevent my application from knowing the password at any moment.)

Thanks in advance.

Context (as suggested by @Daisetsu)

This should be an application where small teams can store credentials, for example for network switches. All data should be end-to-end encrypted, so that companies can trust the application and even hacking the application server does not give sensitive information.

Because some users might set the same password for authentication and encryption their private keys (which I think every user will do), my server normally would be able to decrypt the private keys as the user logs in. To prevent this, it has to be hashed by the client.

The Javascript cannot be trusted, but I could make a zip containing all files and you could run the angular app locally against my REST API ;)

As I mentioned in the comment, you can't trust javascript served by the server.  The idea of keeping the client side downloaded on their computers is interesting, although that doesn't really solve the issue.  The server can still include javascript as part of a response unless you are insanely careful.  In this case I really wouldn't go with javascript.  There's just too many ways it could go wrong.

My recommendation in this case would be to use a browser plugin, or some other client side application which could be compiled and signed since you're dealing with sensitive credentials.  Is there any reason you couldn't just go with a service like lastpass?  Why reinvent the wheel.

EDIT:

How to implement crypto-js PBKDF2 with salt https://stackoverflow.com/questions/22875419/cryptojs-how-to-generate-aes-passphrase

You also mentioned that you think the users will reuse their passwords in both your system login and their private keys.  After the user submits their keys/certs to the system, you may want to look into auditing their uploaded creds by using the password they supplied to unlock the cert/private keys.


How much safer is it really to replace the default account with a new account? When getting a new appliance, be it a firewall or or the like, how much safer is it really to replace the default admin account/username with a differently-named account but with same privilege level?

In my mind, the only scenario in which this is of any benefit is making the replacement account a complex username?

Otherwise, replacing "Admin" with "ourcompany_admin" or the like simply buys you only a small amount of extra time if brute-forced?

By creating a new administration account (and disabling the default administration account) or renaming the default administration account, an attacker would need to first figure out the name of the administration account to be able to begin brute-forcing the account.

Being generous to the question, take exploit code from the recent CVE-2016-6210 from OpenSSHD as an example: the attacker needs to have guesses for what the usernames could be to see if the user is real or not. In reality (since that was a vulnerability in the OpenSSHD), authentication mechanisms usually don't provide a way to determine if a user is real or not -- the attempted logon either authenticates and allows you in or the attempted logon fails.

Changing the default administrator username adds to security through obscurity (many people don't subscribe to the concept). This really only helps with brute-forcing attempts, because once an attacker is able to exploit the authentication mechanism -- using things like code injection, etc -- the attacker is able to bypass the need for a real username.


Expose web service in a secure manner Requirement

I have a web service I need to expose on the DMZ for external communication. The web service communicates directly with a critical database that sits on an internal net.

Current solution

This is currently solved by having a service exposed in the DMZ, the endpoint is secured using a cert and it's using https. As a request is received the service places in on a in-memory queue structure. An internal service is then responsible for keeping an outgoing TCP channel open that looks for messages on the external queue and making sure that the external service posts those to the internal database using the now open outgoing TCP-channel.
This is seen as more securely as it doesn't require the firewall to open for incoming traffic, only outgoing from the internal service.

What's the optimal solution?

My question is however if it is more secure and then why? Couldn't just the firewall be configured to restrict incoming traffic from only the server in the DMZ and make it basically as secure?

What's the de facto solution for these kind of scenarios?

Normally, you'd build a solution with an edge gateway, whereby the dangerous zone (WAN) hits your gateway, and that gateway forwards traffic through to the DMZ. This is best achieved with a physical hardware solution.

There are multiple ways of doing this, but my preferred method is to have a dedicated edge gateway that sits outside the DMZ, which then VPNs into the DMZ. The VPN endpoint inside the DMZ can be configured to limit the traffic coming through. The edge gateway essentially acts as a transparent proxy, passing requests through to the target server inside the DMZ. You can achieve this with most load balancing products, either as dedicated appliances or virtualised solutions.

This has the following benefits:

The WAN-facing device is outside the DMZ.
Everything going in and out of the DMZ is encrypted, authenticated, and integrity checked.
The edge gateway can provide inline NIDS / NIPS and stateful firewall, thus allowing you to block bad traffic before it even enters the DMZ.
You have multiple layers of network security control: the edge gateway's firewall and forwarding rules, the VPN endpoint's security settings, and the firewall on the web service box.
You can detect and block outbound connections (e.g. for mitigating reverse shell) on multiple layers of the network.
Compromising the gateway doesn't immediately put the attacker in a privileged position within the DMZ, since they're limited to what the VPN allows.


Securing REST API without HTTPS I'm developing a REST API but I am unable to use HTTPS without using self-signed certificates. I understand that that might be acceptable for some, but I don't want security messages popping up on client browsers.

The information being passed on the network is not sensitive, so I don't care about eavesdropping, but I want to make sure that only authorized clients are able to make requests and prevent replay attacks. Here's my idea:

A user is registered with the web application running the service. They want to register an API client, but they are not a developer, so they download a supplied client application (in this instance, an IC Card reader they will use with a computer that can communicate data read from the scanned cards to the web service over the API).

Step One: The API client application generates a key pair (e.g. OpenSSL) and sends the public key to the server (this can be a manual upload step when the user registers the client with the server). The server stores the public key in the database associated with the user and a description of the client (e.g. “IC Card Reader on PC01”).

Why do I want to use a key pair (like SSH)? I feel that a shared secret is vulnerable to eavesdropping as it has to be transferred over the network at least once. While this could be prevented by manually entering the key on the server's terminal rather than transporting it over the network, one design goal of the system is to allow users other than myself to register clients and get an API access token using the web interface for the application. Under this circumstance, an eavesdropper could intercept a shared secret key, while a keypair generated by the client would prevent that.

Step Two: When making a request the client first gets a nonce from the server (which stores it in a list or database of nonces and issued timestamps) and then makes the request including the nonce while signing the request with their private key. The server verifies that the message is authentic (was signed by the client and no one else) before executing the request.

My goal with this approach is to ensure that only valid clients are accessing the API, while also preventing replay attacks. An attacker should be able to see the contents of the messages (not really sensitive), but should be unable to modify them. The client doesn't really care whether the data coming from the server is authentic (because in this case the client is changing the state of the server, not the other way around).

Does this approach meet these design goals?
And does it prevent
against man-in-the-middle attacks (assuming the  original
registration of the client was with the real server and not an
attacker's fake one)?

My goal with this approach is to ensure that only valid clients are accessing the API, while also preventing replay attacks.

Use an ever-increasing nonce value.

  An attacker should be able to see the contents of the messages (not really sensitive), but should be unable to modify them.

Have an API key and secret.

Your requests contain the key in plaintext.

They also include a 'hash' value. This hash value is a hash (eg, sha256) of the concatenation of the API secret, your ever-increasing nonce value, and the data of the request itself. The server generates its own hash, and compares it to the one your client sent.

An attacker can read your API request, but since he doesn't have your API secret, he won't be able to craft a new 'hash' value and send his own arbitrary data. He also won't be able to replay old API calls because of your nonce value.


SSL verification of host name of https server I recently found that a library I am using (specifically Apache HTTPClient) when is configured to verify the hostname of the remote server against the certificate's CN it just seems to be doing a string comparison.
I.e. if the certificate has been issued to an IP and the user types a name instead e.g. https://secureserver/
but the IP<->secureserver (maps e.g. configured in windows host file) the verification fails complaining that

javax.net.ssl.SSLException: hostname in certificate didn't match:
    <secureserver> != <10.4.5.1>

Is this the way usually implemented in all libraries? I.e. am I wrong to have expected that a reverse lookup for secureserver to 10.4.5.1. that is the CN of the certificate should have occured?

Thanks

Yes, I believe you were wrong to expect that the certificate name validation process would do any name resolution, reverse resolution, or other mapping for you.  The matching that takes place is pretty much a literal thing performed at the application layer (sorry, bad label.  I mean the SSL library code called by the application when I say "application layer"; in OSI this would probably be Session or Presentation layer, but it's all part of the application executable).

I don't believe you'll find a java library handler to add in the name mapping you're looking for, because the SSL/TLS protocol really is about matching the literal names (and then making sure the cryptographic and certification authority aspects are in place).

I believe you can use the subjectAltName tag to generate a certificate which will validly match multiple names, but that's sort of the opposite approach from what you're looking at.


mprotect at kernel level What would happen if a kernel-level process sets some of its memory
pages as PROT_NONE with mprotect and another kernel-level process
tries to read one of these protected pages?
What is the equivalent of mprotect in windows? What are the main differences?

It depends on what you mean by "kernel process".

In Linux, each process has its own address space, which is embodied by the MMU and its configuration table. Roughly speaking, at any one time, the MMU is configured to find information about pages (where each page from the address space is in RAM, if it is present at all, and the access rights) in tables located at some address in physical RAM (details vary depending on the architecture, but in 32-bit x86 the CR3 register is used for that). When the CPU switches from one process to another, it changes that configuration (i.e. before granting control to any process, the CPU loads the CR3 register with the right value for that process). mprotect() is the API provided by the kernel to applications (along with mmap()) to modify these tables. It is important to note that the mapping is many-to-one: each page in the address space is mapped to a physical page (or to "none"), but several pages in the address space can point to the same physical page, with access rights which need to be equal.

This means that if a process uses mprotect(), then it modifies its own set of MMU tables, and the other processes are unaffected. If a process alters the access rights to PROT_NONE for a page it sees, and some other process also sees the same physical page in its own address space (through some shared memory setup), then the second process can still access the page.

Note that when a process does a system call, the CPU jumps into the kernel space and obtains kernel-level privileges, but the MMU is not affected (well, in fact it can be, depending on the architecture and kernel version; normally, each page is mapped twice, with one mapping accessible only with kernel privileges, so that the kernel may write into RAM which is, from the point of view of the process, absent or read-only; however, things can become a bit more complex on 32-bit x86 because the double-mapping implies a restriction to at most 2 GB of address space per process, and recent kernels have some tricks to go to 4 GB per process, basically by switching MMU mappings when entering the kernel; let's not confuse the situation any further with such details). So the code for the system call executes with the mapping as the calling process sees it (albeit with kernel privileges).

Kernel threads, sometimes known as kernel processes, are something different. These are processes without RAM. They run with kernel-level privileges and occupy a slot in the scheduler, but they don't have an address space of their own. Being threads, they are occasionally granted the CPU (that's the point). However, since they don't have an address space, they don't incur a MMU table switch when they are activated, which is a blessing because MMU table switches are expensive (because of TLB flushes). So kernel threads basically run in the address space of whatever normal process was last running.

If a kernel thread does a mprotect() on a page, assuming that this works at all (the Linux kernel may have safeguards here, I haven't tried), then it will modify the current address space, the one of the unlucky process who ran last, and which process is that cannot be reliably predicted. Whether this impacts another kernel process depends on whether that other process will use the same address space or not, something which can change at each context switch, hundreds of times per second.

Moreover, kernel threads run with kernel privileges, which means that they can do more than normal applications. They tend to be able to read PROT_NONE pages, provided that they do so through the right address (there again, it depends on the architecture and kernel version, but kernel threads will normally be able to see all pages with full access rights for them).

Summary: if it is allowed at all by the kernel, it seems most unwise to fiddle with userland RAM from kernel threads.


Azure Key Vault vs Azure Environment Variables - Which is the right way? I've read a lot on the new Azure Key Vault feature and it does have some valid use cases. However in the case of a simple web app I don't see the benefit of using environment variables which can be configured in the portal.
If a hacker has access to your azure portal then he has access to your key vault configuration. What is the added value?

I'd love to hear your thoughts.

However in the case of a simple web app I don't see the benefit of using environment variables which can be configured in the portal.

I have not used Azure Key Vault, but it appears that the client application never actually sees the master key:

  When a SaaS application needs to perform cryptographic operations by
  using their customers’ keys, Key Vault does this on behalf of the
  application. The application does not see the customers’ keys.

If the application is compromised then in both scenarios the attacker can decrypt whatever they want. However, if the application (and therefore the attacker) never has direct access to the keys then once the attacker loses access they can no longer decrypt any further data. This protects future data, and data which the attacker wasn't able to decrypt before losing access from being compromised.

If the master key was simply in an environment variable and the attacker compromised it, then even if you completely revoked their access they could continue to decrypt data they originally stole.

An additional benefit is that presumably every decryption operation is logged, so you can more easily audit the scope of the data which was compromised. However, if the attacker had direct access to the key then they could decrypt it offline and you'd never know what was and wasn't compromised.


What's the PROPER way to validate a signature timestamp? the purpose of adding trusted timestamps to signatures is so that they can be considered valid long beyond the validity of the signing certificate.
However, this is not so easy, since TSA's signing certificate has an exipration date too or may be revoked and already issued timestamps may become invalid.
My question thus is, what's the text-book way of validating trusted timestamps?
My understanding of the process is this:
1. Verify that the token has been issued for the data in question and that the issuing certificate of the token was valid and trusted at that time the token was issued.
2. Verify that by the current time, none of the certificates in the trust chain have been revoked, OR that they have been revoked with a reasonCode extension present and the reasonCode is one of unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5) (according to https://www.ietf.org/rfc/rfc3161.txt)

But both of these steps seem to have some considerable problems in regards to CRLs:
For the first step, one would need to have a historical CRL record (valid at the time of timestamping) for each certificate in the trust (this in turn means that for every timestamp one should also store current CRLs, otherwise how would one validate the timestamp in the future?).
For the second step, one would need for each certificate in the chain a CRL which is valid NOW. However, that in turn would require that the CRL revocation points keep publishing updated CRLs for each certificate for all eternity. But by the time the timestamp is being validated the CRL distribution points may not be updated anymore for a long time already (especially if the certificate just expired and never got revoked).
So, let's say in 20 years someone wants to validate a timestamp token and the CRL distribution point url of the signing certificate (or any certificate in the trust chain) would not be maintained anymore - how could the person validate the timestamp?

AFAIK, the goal of adding a trusted timestamp is not to extend the validity of the signed document, but just to prove that is was signed at a precise time.
It matters when anteriority is a thing. For example when two research teams want to publish an article on the same subject, it can be interesting to have evidence of which one established/discovered the thing first. Here a signed document with a trusted timestamp could be such an evidence.
Without the trusted timestamp, it is too easy to set the clock of local machine several months back, sign a document and reset the clock to the current time.


Python's http.server library "basic security checks" According to:

https://docs.python.org/3/library/http.server.html

  Warning http.server is not recommended for production. It only implements basic security checks.

It doesn't state what security vulnerabilities the server is exposed to. I'm a sysadmin and have a dev team that wants to push this to production (My understanding is that they are using that while extending http.server.SimpleHTTPRequestHandler) and a CIO that is giving them the green light. I have no idea what risks there are involved because the documentation doesn't elaborate on details. Can somebody enlighten me as to what security vulnerabilities this product has?

The problem isn't that there are known security vulnerabilities.

The problem is that there is not really an effort to address less common but critical vulnerabilities.

For example, many web servers will display error messages.  Until quite recently, Apache Httpd would include some of the request data in the error pages, which allowed cross-site scripting in default configurations of mod_proxy (CVE-2019-10092), with no way for the application developers to mitigate this threat against the site users.

The major web servers, such as Apache Httpd, Nginx, IIS, and Lighttpd each have hundreds of active contributors (or in IIS's case, a large corporate structure behind it), dozens of core developers who understand security best practices, and a team dedicated specifically to reviewing code for potential vulnerabilities.  As you can tell by browsing the CVEs of any of those projects, there are still things that people catch after versions are released.

The developers who write HTTP servers for programming languages are small sub-projects, developing tools to support the main product: The language.  There might be a dozen people who have contributed code to that tool, and one or two core developers on that project.

They do not have the resources available to search for vulnerabilities, so while there aren't any known vulnerabilities (or at the very least, it is very bad form here to point out known vulnerabilities that are likely to remain unaddressed), there are most certainly vulnerabilities in it, simply due to the complex nature of HTTP servers.

Some of these vulnerabilities might be extremely critical, such as allowing an attacker to have complete control over your server, including executing arbitrary code with a privileged account.  Such a vulnerability might not exist, but without a thorough code review—and with the large, red-boxed warning at the top of Python's documentation page—it is plausible that such a vulnerability might exist.

In your specific case, the CIO signed off on it.

It is the CIO's responsibility to ensure that risk assessments are done. As the sysadmin, it's your job to execute the company's officers' instructions, and your responsibility to ensure that the officers have the information they need to be able to make informed decisions.

Because of the boundary in responsibilities, the pushback that I would do is ask to see the risk assessment.  If the risk assessment doesn't include a very high probability (due to automated tools quickly finding the vulnerable server in hours) that the server gets infected with malware and used as a Command and Control repeater node for a bot farm, offer to help them make a realistic risk assessment.


How safe are password managers like LastPass? I use LastPass to store and use my passwords, so I do not have duplicate passwords even if I have to register four to five different accounts a day, and the passwords are long.

How safe are password manager services like LastPass? Don't they create a single point of failure? They are very attractive services for hackers. How can I trust the people behind these services and their security mechanisms?
I imagine that a third party (government, company, etc.) would be very easy to 'bribe' and get all of my passwords.

Are there any other solutions that offer similar services with similar ease of use?

We should distinguish between offline password managers (like Password Safe) and online password managers (like LastPass).

Offline password managers carry relatively little risk. It is true that the saved passwords are a single point of failure. But then, your computer is a single point of failure too. The most likely cause of a breach is getting malware on your computer. Without a password manager, malware can quietly sit and capture all the passwords you use. With a password manager, it's slightly worse, because once the malware has captured the master password, it gets all your passwords. But then, who cares about the ones you never use? It is theoretically possible that the password manager could be trojaned, or have a back door - but this is true with any software. I feel comfortable trusting widely used password managers, like Password Safe.

Online password managers have the significant benefit that your passwords are available on anyone's computer, but they also carry somewhat more risk. Partly that the online database could be breached (whether by hacking, court order, malicious insider, etc.) Also because LastPass integrates with browsers, it has a larger attack surface, so there could be technical vulnerabilities (which are unlikely with a standalone app like Password Safe).

Now, for most people these risks are acceptable, and I would suggest that the approach of using a password manager like LastPass for most of your passwords is better than using the same password everywhere - which seems to be the main alternative. But I wouldn't store every password in there; make an effort to memorize your most important ones, like online banking.

I know someone who won't use Password Safe and instead has a physical notebook with his passwords in obfuscated form. This notebook is obviously much safer against malware... whether it's at greater risk of loss/theft is an interesting question.


XSS in HTTP Version value exploitable? I have a HTTP request which has the first line like this one:

GET / HTTP/1.1

The value HTTP/1.1 gets reflected unfiltered/unencoded back and is vulnerable to XSS, but is there any way to exploit that, except by social engineering the victim to manually change the version value in their browser config?

No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability turns out to be rather useless. Yet another example is XSS via the user agent. Similarly - unless it's a persistent XSS flaw, just printing back a modified user-agent string will most likely not be exploitable.

Beyond reflected XSS there are obviously other vulnerabilities to look out for. The response might be cached somewhere, enabling you to turn it into a persistent XSS flaw. Or the value might be stored unfiltered in some backend logging system.


Does Mozilla Thunderbird leak any personally identifying data? I know that Windows Live Mail leaks your computer name.

Does Thunderbird have any leaks like this?
If so, to prevent them?

Edit: I mean email headers.

Are there any other privacy issues with Thunderbird?

Mozilla Thunderbird has several fingerprints within the RFC 822 content.  This includes the User-Agent, Message-ID, and Content-Type headers as well as how it choses to render HTML, and this is not necessarily a complete list.
There isn't much variation between Thunderbird versions, so I'm guessing your OS and actual Thunderbird version are only visible through the User-Agent header.
User-Agent and X-Mailer headers
Here is a sample Thunderbird User-Agent header:
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

To disable that, follow these steps:

Go to Preferences → Advanced
Enter the Config Editor (lower right button, click "I'll be careful, I promise!" if prompted)
Right-click and create a New 〉String called general.useragent.override
Leave the string's value blank (hit OK)

This preference is for renaming the User Agent string, but Thunderbird will recognize a blank string as an instruction to not include the header.  Do not forge another common user agent here; some anti-spam systems will notice the forgery and flag your mail as spam.
X-Mailer is another header used to reveal the sending software and its version.  It is rarely used in conjunction with User-Agent.  Thunderbird, for example, doesn't create an X-Mailer while Windows Live Mail does. Live Mail doesn't create a User-Agent header while Thunderbird does.
Received headers
RFC 821 requires every relay that a message passes through to add a Received header.  These typically reveal the sending host's self-reported name (HELO/EHLO), its IP address, its reverse DNS (rDNS), the receiving host's SMTP software, ID for that message as it sits in the queue, hostname, and local date.  (There's sometimes more information in there too, like authentication notes and original recipients (before alias expansion).)
When an end-user mail client (formally called a "Mail User Agent" or "MUA") connects to its outbound SMTP server, it must participate in this scheme as well.  That means a system name needs to be used in the EHLO.  Different clients have different ways of selecting this.  Thunderbird uses your LAN IP address in brackets, Windows Live Mail includes your system's NetBIOS name (the same name used by Windows File Sharing), and other clients can use other techniques, including rDNS.  Mozilla's choice of using the LAN IP is, in my opinion, the least revealing of the available options.
Others
The Message-ID and Content-Type headers each generate "random" seeming unique strings (the message ID value and the MIME boundary string). These strings have certain patterns that can be used to determine the email client even without a User-Agent or X-Mailer header.
Aspects of other headers or even the HTML code may also reveal that you're using Thunderbird, but such techniques are unlikely to reveal your OS or Thunderbird version and they're unlikely to be as diagnostic than your Message-ID and Content-Type headers, which are in turn less diagnostic than X-Mailer or User-Agent strings.
Thunderbird extensions
There are also a few extensions that will provide more information than you may want to reveal.  Enigmail (a PGP add-on) is one of these.  See this How to Sanitize Thunderbird and Enigmail blog post for instructions. (That post is also where I learned how to suppress the User-Agent header).  For my setup, the Enigmail ad and version were already removed (and the correct omission settings were labeled as default), so this may already be fixed by default in Enigmail.
Do note that when you cryptographically sign something, you are rather explicitly (and verifiably) stating who you are (at least by tying your key to the message) in addition to your email address in the From header.


What's the practical limit for rainbow-table based bruteforce? Say we have a hash of a password. The password can be considered to be made of of totally random characters and has a fixed length of N. The hash is SHA1(password+salt), where the salt is of length M.

How large must M+N be in order to resist a rainbow-table based bruteforce attack?

Scenario #1: Consider the attacker to have access to state-of-the art computational resources and storage space, e.g a government.
Scenario #2: Consider the attacker to have more limited resources, ($10K if we want to be more specific) to spend on equipment or cloud-based services.

Related question: How much is the complexity reduced if the total length (M+N) are known to the attacker?

Let's say they randomly chose alphanumeric (A-Za-z0-9 no symbols) for both salt and password; e.g., the sample space is (62)^M possible salts and (62)^N passwords.

Say they have a million GPUs in a farm at their disposal that can each generate a billion hashes a second (assuming a simple MD5 or SHA type hashes - bcrypt or PBKDF based hashes are much slower).  So for a given salt, they can crack a 8 character password in 0.2 seconds (200 000 GPU-seconds), a 10 character password in 14 minutes (26 GPU-years), a 12-character password in 37 days (100 000 GPU-years), a 16-character in  password in 1.5 million years (1.5 trillion GPU years).

Or another way to think about it; a typical GPU to crank out a billion hashes a second uses ~200 W.  So if electricity costs you $0.10 per kWHr and neglecting start up costs, a GPU-hour costs $0.02.  So an 8-character password costs ~$1, 10-character $4600, 12-character $18 million, 16 character - $260 trillion (the world's money supply is on the order of $10 trillion).  (And this neglects the cost of buying/maintaining a million GPUs -- just electricity).

As for a rainbow table  -- at some point it has to be constructed.  So you want a complete rainbow table for all 4 character prefixes; and want to cover all passwords up to 8 characters (e.g., total of 12 char password) it will take 100 000 GPU years (37 days of a million GPUs) and cost about $18 million in electric bill.

Basically when M+N > ~12 for random alphanumerics it starts to become unfeasible (e.g., is unfeasible at M+N = 16).

EDIT: New summary table, where I list password length and type (e.g., 8 A-Za-z0-9 means 8 character uppercase + lowercase + numeric password).
Also included is a google application-specific password (16 random lowercase letters) though obviously google type password typically would have to be attacked online (not like an offline hash attacked by a GPU farm).

  PW Length  | # of PW | PW Entropy |       GPU-time | Electricity Cost at $0.10/kW-hr
-------------------------------------------------------------------------------------------
 8 A-Za-z0-9 | 2x10^14 | 47.6 bits  |       60 hours |                  $1
10 A-Za-z0-9 | 8x10^17 | 59.5 bits  |       26 years |              $4 600
12 A-Za-z0-9 | 3x10^21 | 71.4 bits  |   100 000 years|         $18 000 000 ($18 million)
14 A-Za-z0-9 | 1x10^25 | 83.4 bits  | 390 million yrs|     $69 000 000 000 ($69 billion)
16 A-Za-z0-9 | 5x10^28 | 95.2 bits  |1500 billion yrs|$260 000 000 000 000 ($260 trillion)
-------------------------------------------------------------------------------------------
16 a-z       | 4x10^22 | 75.2 bits  | 1.4 million yrs|        $242 000 000 ($242 million)


Allowing the execution of arbitrary code in python Let's say the user has installed a python interpreter on their machine/browser, for example, using something like https://github.com/iodide-project/pyodide. I understand not allowing someone to enter in arbitrary code when they don't own the resources, for example doing something like:
exec('while 1: os.fork()')

However, if the user is executing the code on their own machine, is there anything wrong with allowing them to run arbitrary evals and execs, and just telling them "Please use at your own risk"? The use case is we give the user an environment to work with a spreadsheet, and they can enter in formulas using python, and we just 'pass-through' the entered string (in the spreadsheet cell) to their python environment.

If its on their machine then that eliminates a major attack vector but doesnt necessarily eliminate all of them. I would want to make sure that it is indeed them typing in the formula. There are all different types of scenarios to think about here. What if somebody sends them a spreadsheet and they open it up? Will it execute? What if some social engineering is done and somebody cuts and pastes something without knowledge? How educated are your users? What if someone types rm -rf /? Will they lose all of their data? None of these may be applicable but you get the idea. This would really require you to look at the system as a whole and determine what type of things could possibly go wrong and if its worth the risk. My instinct says there is probably a much safer to do what you are trying to do but without seeing the exact design it would be hard to say.


Are photos on Facebook servers stored with the geotagging metadata in their EXIF headers? If i download photo from Facebook, will i be able to read its geotagging metadata, or Facebook just parse the uploaded photo, record all EXIF headers into the database (to show the camera model somewhere or to provide them to law enforcement agencies, for example), and then removes them for security reasons?

Most big websites do filter out EXIF and geocache data. If you were to take a picture on your phone with geocache on, and then upload it to a ftp server it would still have the EXIF and geocache data. I'm almost positive facebook keeps a original copy of the photo and then just redistributes a copy of it onto their website with different headers etc. At the end of the day, you will not be able to get the data from a facebook photo.


Mobile Phone security - help finding security/privacy review/discussion I'm in the market for a new phone, and was wondering which modles/operating systems are the best to protect privacy/security.  I don't use social media, so won't have Facebook/Twitter,etc. I am fairly diligent about keeping my info. private (i.e. for my browser, I have adblock, ghostery, do not track me ,etc.) and especially with cell phones, which can track me in basically 3D space, I want to find a secure phone that I can keep pretty "info secure".

I was just wondering if anyone has any tips/information on security for Android phones.  I have heard of the Blackphone, but that might be overkill.  Ideally, the phone would send 0 information about myself to a first or third party, without my knowledge.  Is Blackberry's security good? I loved my Pearl when it was out years ago and I'm still open to them (I'm not huge on apps, games, etc.).  Also my concern with Android is that since it's a Google company, Google may sneak some data out all the time (my location/GPS coordinates, websites viewed, cookies, apps installed, etc).  Is there any way to just use Android OS but break any connection to Google?

Thanks for any suggestions/advice!  Or, if there are some websites I can browse (so far I get general reviews from like C-net or something not necessarily discussing privacy/security), I'm all ears!

edit: I'm not looking for "The Samsung Galaxy s10000 is the best".  I'm just looking for discussion/reviews of privacy and security that aren't just "superficial" (mainly reviews I see discuss security but only on a surface level, nothing like how the phone tracks/updates/etc.)

This may not survive as it's a bit off topic for the site, but yeah there's some non-Google Android based options.

The best known is likely Cyanogen Mod.  This can be retro-fitted to a wide variety of Android devices and removes a lot of the direct ties to Google.

Another option to look at is Sailfish OS which whilst it's not Android, has a focus on providing compatibility with Android apps.

On the app. store side there's F-Droid which provides a catalogue of Open Source Android applications.


RDP vs. VNC when looking them from security side Regarding:

https://unix.stackexchange.com/questions/12924/ssh-tunnel-with-vnc

Which one would be better, if we look it @security side?
I heard that RDP is very very poor when it comes to security.

RDP has some issues, but these are broadly mitigated by getting the config right. Wicked Clown demonstrated a wonderful privilege escalation attack from restricted user to admin in less than 5 minutes at the recent B Sides London security conference which relied on a common misconfiguration - paper here. TLS can provide a strongly authenticated tunnel - which will help.

An alternative could be VNC - which also has potential issues, however using an SSH tunnel for this gives you a much better position with respect to security as you can use strong mutual authentication.

The key point to look at is what your key risks are - if you are worried about an attacker pretending to be a user, SSH or TLS with certificates gives you the authentication and encrypted tunnel part of the puzzle, is a good idea, however you still have the risk of an attacker stealing the mobile device:-)


OpenSSL EVP aes_256_cbc Initialization Vector Size I'm looking at the crypto library examples (programmed in c) provided for OpenSSL EVP on OpenSSL Wiki.

Their example for a 128 bit Initialization Vector is as follows:

/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"01234567890123456";

0-9 -> 10 chars
0-6 -> 7 chars
Total: 17 chars

Each char is 1 byte(8 bits) on my system. Hence the IV is 8*17 = 136 bits. Why are they saying that the total IV size is 128 bits? Is this an off-by-1 error or am I missing something?

Moved from the question to an answer.

  Stephen
  was
  correct.
  This was very simple to check, I just changed the IV to be the correct
  length and the ciphertext remained the same. Hence, the extra byte is
  not used in the algorithm and somebody miscounted.

  Default IV:

/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"01234567890123456";

  Output:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc.......@.}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D

  New IV:

/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"0123456789012345";

  Run make again to build the program.

  Output:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc.......@.}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D


Is it a security risk to run master process of nginx as root? I'm using nginx (Port 8888) as a reverse proxy for my web server running over 8080. In the traditional way, nginx master process runs as root and spawns the child processes with user www-data. Is it recommended to run the master process as non-root as well to harden the security of my machine?

Both nginx and reverse proxy are running on same ubuntu machine.

It depends.
One reason to run nginx as root is to make it possible to listen on ports below 1024 i.e. port 80 (http) and port 443 (https). This is not needed in your case. Another reason is to make it possible for nginx to read sensitive files like certificate private keys on startup without having these file readable in case a child process gets compromised.

Thus, one the one side you have the risk that something is at least initially running as root. On the other side you have the risk of exposing sensitive files to the non-root part of nginx, i.e. the part which does the main work and were the main code complexity is. Which of these risks is more relevant depends on your actual use case, i.e. are there sensitive files like private keys involved in your configuration, do you explicitly need to give some not fully trusted user root to start nginx etc.


Help to secure my connection to my company VPN (Cisco AnyConnect)! I've been searching about VPN for more than an hour, and all the answers I found on this site or others are either confusing or contradicting.

My issue is that I usually access my company VPN through Cisco AnyConnect Secure Mobility client from my home computer. A colleague told me that they can "monitor" my home computer when the Cisco client is connected.

Some in the community say that a VPN is a 2-way connection: if you can access anything on your work computer then they can access anything on your home computer. HOW? I thought that I am the client and they are the server (the Cisco software is called client after all..). And if this is true, in what capacity they can access my computer? Screen grabs? Full drives access? Full admin privilege on my computer? Network traffic?

Some say that if they got split-tunneling then they can access your computer. How can I know if split-tunneling is activated?

In case they can access my computer, HOW can I stop them? How can I protect my important files/folders/drives?

Please, try to simplify the networking-specific explanations as possible.

"Monitor" can mean many things.
Monitor Your Traffic
If the client is not controlled by the employer, they can only monitor your traffic across the VPN on their side and not your file system/desktop.
2-way communication does not mean that they suddenly can log into your machine. It means that the traffic from the employer network might also reach your home machine through the VPN connection, depending on how it is configured.
No, split tunneling does not mean that they can access your machine.
Monitor Your System
However, other types of remote management clients do allow them to view your system, file system, and other things. It's important to know the difference.
For that particular client, it offers a DNS product called Umbrella, that could allow your employer to see sites you visit. It also has an optional plugin that does allow for full visibility on your device. You would have to know what services/options are enabled on the client.
General Advice
You need to work with your IT team, and possibly your HR and DPO, to understand exactly what you are being asked to install on your personal devices.
In general, employer-provided and controlled clients should not be installed on private machines. You can get clients from vendors (like from Cisco itself) that are not controlled by the employer. That would bypass all your concerns about your employers seeing too much.


Is it safe to write the salt AND/OR the IV at the beggining of an encrypted file? I want to encrypt a file with AES in CBC mode (maybe another mode is better for file encryption...I don't know, but suggestions are welcome!).

What I usually do is that I first write a few random data (256 bits, just to muddy the waters), then my salt and my IV (which are both uuid4...or generated from a secure PRNG) at the beginning of the encrypted file, and then, the encrypted blocks.

I wonder if that solution is less secure than an other? Anyway, I really don't know how I could do otherwise!

Salts and IV are not the same thing; salts are for password hashing, IV are for starting up some encryption modes. Neither is meant to be secret, though; otherwise we would call them "keys". It is safe to put the IV and/or salt in file headers.

Your adding of "a few random data (256 bits, just to muddy the waters)" is the computer equivalent of sacrificing a chicken to propitiate the gods. If it takes such rituals to make you feel good, then why not; but believing that it changes anything to your actual security would be somewhat naive.

CBC mode requires a random, unpredictable IV; it is a hard requirement. Using an UUID is dangerous in several ways:

Only the "v4" UUID uses a PRNG.
Nobody guarantees that the PRNG used for UUID v4 is cryptographically strong.
Even if it is strong, there still are six fixed bits in the UUID (the ones which say "this is a v4 UUID"); only 122 bits are random.

CBC is not the best mode in class anymore; we found better. In particular:

CBC has strict requirements on IV generation (Chosen-Plaintext Attacks have been shown to be specially effective against poor IV generation).
CBC needs padding, and padding handling has been shown to be delicate (decryption can turn into a "padding oracle" if done improperly).
CBC does not ensure integrity. Usually, when you need to encrypt (for confidentiality), you also need to reliably detect hostile alterations. For that, you need a MAC. Assembling a MAC and encryption is tricky.

Newer modes solve these issues, by tolerating a simple IV (a non-repeating counter is enough), by not needing padding, and by having an integrated MAC where the integration has been done adequately. See in particular GCM and EAX.


What methods could be used to host on an infected machine? Assuming the following:

a computer is compromised and connected to a network where a simple wireless router or modem is the only form of firewall security
all incoming connections are blocked by the router.

Is there any way the attacker would be able to host services (receiving incoming connections) on that machine without direct access to the router?

Are there any work arounds I might be forgetting?

Yes, one of you main concerns will be to disable UPnP (Universal Plug 'n Play).

UPnP could allow a malicious program to bypass the firewall entirely, allowing other computers to directly contact a network service hosted on the compromised machine.

UPnP assumes local programs are trustworthy and allows them to forward ports. If malware not being able to forward ports is important to you,
you’ll want to disable it.


Win server 2003 sp2 'local' Privilege escalation via thin client Just asking if there is any known exploit that allows a client connected a win server 2003 sp2 x64 via SunRay thin-client to infiltrate (or preform a local privilege escalation on) the server. The thin  clients currently have limited privileges, no cd/usb input and neither the server nor the clients have any internet access.

Windows Server 2003 SP2 is out of MSFT's support lifecycle.  Microsoft requires your server to be at SP3 in order to be eligible for security and other hotfixes.

Mainstream support for Win 2003 SP3 ended 7/13/2010.
Extended support ends 7/14/2015.

Your server is vulnerable all the security patches that SP3 fixed.  Of course your deployment mitigates this somewhat.
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=windows+server+2003+&Filter=FilterNO
If the SunRay thin client issues an RDP call to your server, and the ethernet cable to the thin client is disconnected and placed into a laptop (etc), then the RDP could be exploited.  There are several known issues with unpatched RDP.
There are also MITM issues with Win2003 RDP if the attacker saw an administrator log in from another machine.


When and Why does Chrome display malware detection warning? Google Chrome contains malware detection feature. When user visits some site, browser may display warning that site contains malware.

What does it mean that site contains malware? Does it mean that site contains link to download malware or that site tries to bypass browser's security mechanisms?

How does Chrome detect that site contains malware?

This is Google SafeBrowsing. Google keeps a blacklist database of what sites are known or suspected of hosting malware and provides APIs for browsers to check the list.

  Safe Browsing is a service provided by Google that enables applications to check URLs against Google's constantly updated lists of suspected phishing and malware pages.


FIPS 140-2 Compliance vs Validation & Products vs. Modules vs. Ciphers Some vendors appear to advertise their products as using "FIPS 140-2 compliant algorithms & ciphers". However, some of these products cannot be found on the NIST website that lists validated cryptographic modules. What does this really mean for customers who wish to use the product?

Is a product's use of standardized, "FIPS 140-2 compliant algorithms & ciphers" sufficient to meet the requirements of a government organization or contractor? Or does a product actually have to be validated by NIST in order to meet government data protection requirements?

I think the answer comes straightforward from this quoted paragraph (Module Validation Lists) -I emphasize the important thing in bold:

  A product or implementation does not meet the FIPS 140-1 or FIPS
  140-2 applicability requirements by simply implementing an Approved
  security function and acquiring algorithm validation certificates.
  Only modules tested and validated to FIPS 140-1 or FIPS 140-2 meet the
  applicability requirements for cryptographic modules to protect
  sensitive information.

As for:

  What does this really mean for customers who wish to use the product?

NIST advises:

  Users in Federal Government organizations are advised to refer to the
  FIPS 140-1 and FIPS 140-2 validation list

Validation list.


Scrubbing data from a dead tablet I have a broken android tablet (waterlogged) that is completely dead. I want to give it to a friend who wants to try to fix it, but I'm concerned with my data in the tablet. I don't have the tool nor the time to learn to disassemble the tablet to take the storage drive.

Is there any way to scrub my data from a dead tablet without destroying it?

You have a risk/cost - benefit problem here, with basically three factors:

How much you trust the person manipulating the tablet
The cost of the tablet
The potential damage of the data that was stored there being accessed.

Only you can decide the course of action that is most appropriate for your case and personal preferences.

Now, there are a few things you may do to lower the risk of potentially private data being accessed:

You can request a remote wipe of the device. If the tablet is made functional again (and able to connect to the internet), it will receive the command and wipe itself.
You can invalidate the tokens and even change the password for the accounts which are setup in the device (note this can be incompatible with the previous point). Thus, it won't be able to gather new data (eg. start receiving your new emails) and, depending on the app, may even not show data which was previously downloaded.
Obviously, you don't want to give him the passwords for the device. This may by itself be enough to avoid him accessing your data.
You invite your friend to come to your home and attempt together to fix the tablet.


Digitally signed scripts as a way to thwart XSS As a blanket approach to dealing with XSS attacks, rather than having to remember to escape user-generated code, is there a way to instruct the browser not to execute any script or script-function which isn't signed with a particular public key (embedded in the top of every page, but not necessarily authenticated.  This is only meant for dealing with XSS, not man-in-the-middle)?  Then you could just sign all the "real" scripts

This would be a real hit to performance. Imagine you have a ton of embedded functions within your HTML page. Each would need to be signed seperately. Furthermore your server side code needs to be able to access your keystore to sign the code as often pages are generated dynamically. This would mean a substantial overhead to be dealt with.

Also note that JavaScript executing user input, which contains JavaScript will be hard to handle.

For instance let's say you have XSS on a user parameter which is embedded back into the page by a JavaScript function, your server will actually sign it before sending as it will not know that that part of the code isn't legitimate... and then we are back at the old problem of input/output validation.

Anyway most of this can be fixed with CSP anyway.


Is using HMAC to transmit a password OK? I'm writing a small webapp and I don't want to transmit login passwords as cleartext. As I don't have SSL available I've written a one-time challenge system which sends a random string with the login form which is then used to hash the password using HMAC-SHA256 on the client-side. I use the random challenge string as the message and the user's password as the secret key for HMAC.

I know that self-made solutions are generally a bad idea, so I wanted to ask if I'm making a mistake here.

Edit: There seems to be a misunderstanding, I'm not asking about password storage or challenge/repsonse systems, but about HMAC and password transmission. To clarify a little: My first version was HMAC(msg=password, key=challenge), because I thought, well, the message I want to transmit to the server is the user's password. But later I noticed that the challenge string is not exactly a secret key, so I switched it, but that got me thinking if I maybe do something entirely wrong and I thought I better ask about it.

Besides being a self-invented scheme, I see at least the following problems with your proposal:

There is no binding with the actual data. When you authenticate a user, you do not want to really authenticate "the user" only; you want to authenticate a session, i.e. make sure that what will follow on the link will be guaranteed to be from that user, and what you will send on the link will be seen only by the intended user. An active attacker can hijack the connection, and even a passive eavesdropper can spy on whatever you will send afterwards.
The scheme is vulnerable to offline dictionary attacks. Passwords are weak because they fit in human brains, and human brains are not overly good at remembering long passwords (and human users lack patience to type long passwords). It is a losing battle: computers regularly gain more power, but not humans. Trying out potential passwords tends to be a successful attack, and observing your scheme yields enough information to try passwords (the attacker just has to compute a single HMAC per guessed password, and see if it matches what was observed). Such attacks can be mitigated to a great extent by employing a slow derivation process (e.g. bcrypt) but a single HMAC will just not be enough. It is still a bad idea to even allow for an offline dictionary attack.
The server will have to store some information which is enough for a user to authenticate. This means that an attacker gaining temporary read access to the server's storage (e.g. a database dump through some SQL injection) may obtain passwords (or password-equivalent data) allowing him to impersonate users at very little cost. Better password schemes store on the server enough data to verify a password, but no more.

Making a proper, secure, authenticated medium for data transfer is not an easy task. If you really need to reimplement something yourself instead of using some SSL/TLS library, then do yourself a favor and implement a standard protocol for that, e.g. SSL/TLS. If you have qualms about certificate, consider TLS with SRP (no certificate at all, mutual client-server password-based authentication, not vulnerable to offline dictionary attacks).

Edit: about your clarification in your own edit: using the secret data (the password) as the key in HMAC, and the publicly known data (the challenge) as the data in HMAC, is theoretically much better than the reverse (HMAC was designed for the key to be secret); in practice, given the structure of HMAC, it would probably not much change security. Yet my points exposed above still apply.


Why, after a certain character limit, are larger passwords labeled as "weak" on some sites? On many sites we see an indicator if our password is weak, or strong, to give us a good indication to go with that password, or not.

I've been noticing on some sites, that after x amount of characters my "100% Strong" password, will turn to 0% weak, just with 1 character "over the limit."  This is something that I've seen on multiple sites throughout the years, but on some this isn't an issue at all.

My questions are.

is there a reason why too many characters is a bad thing, even if it's a completely random password?
Why they are labeled weak after x amount of characters, even when they were very strong before that x character?

This question also ties into my other question here Are there any security advantages to forcing a password-character limit on reset, but allowing unlimited character in password-login? but wanted to separate them, as they are really 2 separate questions.

Password strength meters are notoriously weak:

  New research from Concordia exposes the weakness of password strength
  meters and shows consumers should remain skeptical when the bar turns
  green.

In general, adding a character to a password will not make it weaker. There are only specific situations where this isn't true. For example, MyPasswor is probably a stronger password than MyPassword. That doesn't mean that adding a character always makes it stronger. For example, bcrypt has a maximum length of 56 bytes. (Note that that is bytes, not characters.) Characters added beyond that length are simply ignored when the password is stored.

As a general rule, just create random passwords using a trusted password generator or diceware, and don't worry about the silly strength meters.