How safe are employee laptops in China against International corporate espionage?

I recently took a business trip to China. Our IT department told me I could not take my normal machine, and instead gave me a loaner.

That may not have helped you at all. The reason I'm saying this is because you connected that laptop to the corporate network after you brought it back to your country.

  This loaner had MS Outlook and was linked to my normal company e-mail account. I logged into the corporate network using the same VPN and token (Mobile Pass on my iPhone) that I would have used had I taken my normal machine. I should note that I did take my normal iPhone, not a loaner.

You shouldn't ever reconnect that computer to your corporate network. You need a clear separation of concerns.

International Corporate Espionage and You

Do you have a company that does important business in China? You may have been hacked on arrival. Unfortunately, since you also connected to the corporate email and other accounts, you may have had all of your email addresses and contacts exfil'd.

Why would they need that information? For phishing attacks, for information on clients, contacts, et al.

Unfortunately, most of the hotel internet service that I've encountered have had significant problems with their login portals, such as drive-by-download exploits in Javascript, Flash, and Java. If you had any of those enabled, and your machine was vulnerable, then it's quite possible you're infected without realizing it.

I've personally come across hotel WiFi that "doesn't work," which requires "IT staff" in the hotels who will personally come in and set up your  connection properties (IPv4, IPv6, DNS, et al) to connect through a malicious server. Sometimes they even try to download files on my laptop while "fixing" it.

Firmware attacks are possible

  The primary difference from the normal machine seems to be that upon my return, the loaner would be reimaged, and presumably used as a loaner on the next trip someone took.

Unfortunately, this won't help against firmware-based attacks. It can be as simple as inserting a BadUSB device when you're away. Walk in, insert, wait for confirmation of flashed hardware, leave. If you're working for a government contractor, or have important company secrets to protect, I wouldn't even trust a re-imaged drive.

Full disk encryption doesn't protect you against flashed firmware, or even hidden device implants. They can simply turn on the laptop, insert a piece of media that contains malware, flash your bios without even touching the drive, and then install bios-based malware.

But firmware attacks aren't absolutely necessary

Did you leave the laptop alone in the hotel while you went shopping, or when to an important meeting? It may have been broken into physically while you weren't there.

One good way to defend against this is by ensuring that your hard drive was encrypted, and then shutting it off when you're gone. But this isn't perfect either; they can physically implant things in your laptop faster than you think. You could also try placing few warranty/void seals on the laptop edges before visiting China. If they're broken, assume the hardware is compromised.

Again, keep in mind that full-disk encryption won't save you from hardware-based attacks. If they copied your hard drive contents and then installed a hardware-based keylogger, then they could retrieve your hard-drive contents easily.

What about my phone? Is it safe?

Since you mentioned your phone in your post, I thought I'd add this little tidbit. It's possible to replace your phone's charging equipment with a malicious doppelganger while you're gone, or even while you're asleep.

If you spend enough time in hotels, you may run even into hotel employees who actually enter your hotel while you're asleep. Even if you've bolted the doors and locked them.

Should I connect to my normal corporate network while in China?

  I was never asked not to place the loaner on the company network on my return, and I never tried so I do not know if it would connect to the network or not. There were also no restrictions on moving files from the loaner onto my normal machine. I also used my normal logins on the loaner (user id, passwords, etc.).

I would suggest that your IT Security staff spends a bit more time learning about foreign attackers. Using your normal logins is pretty much a huge no-no in China, or in any other high-risk area.

Are there any security benefits of your laptop policy?

  My question is: does this loaner laptop policy provide significant security benefit over taking the user's normal machine?

Nope. The reason is that you ended up connecting to your corporate network's VPN. I took a lot of disposable tech to China, and it ended up getting hacked every single time. I reformatted afterwards, and the infection persisted. Had I connected that to an important network where I had read/write access to critical things, I'd be in for a world of trouble.

If you want an Advanced Persistent Threat spreading everywhere, go for it. Personally, I want all the infections so I can reverse-engineer them! :-) However, considering your company likely has secrets to protect, I would not trust this laptop policy.

In fact, what you're describing - the way you used the computer - sounds like a goldmine to a skilled hacker, or even a script kiddie who can automate the attack. What would you do at this point if you considered your data breached? It could just be the early stages of a breach, getting the data ready for a phishing attack, or you might've had more important information available potential attackers.

But what about the corporate VPN?

Keep in mind, as I've stated several times, if you connected to your company through the corporate VPN, and someone in China or elsewhere infected your machine, then anything you're allowed to do on that corporate network is also accessible to them. Are you allowed to create/read/write critical files and folders? So could they.

Again, whatever you're allowed to do on your corporate network, so can they if they control your computer. This could be done silently without you realizing it, even while you're on the system.


Blueborne - Attack Scenario Clarification

Linux uses Bluz to implement the bluetooth stack which integrate bluetooth in universal socket communication.
So you can communicate with bluetooth device using traditional socket mechanism.
More details here: https://people.csail.mit.edu/albert/bluez-intro/x559.html


Can results from DAST (Dynamic Application Security Testing) tools be false positive?

DAST can absolutely have false positives. It depends on the tool that you are using, but there are some that can give you hundreds of false positives.

For example, a tool might check for SQL injection by inserting a single-quote and checking for an SQL error message, but an error message being present does not necessarily mean that there is an SQL injection vulnerability.

Just as with SAST, you should verify that there is actually a vulnerability before you schedule dev time to fix it.


The choice of in-house or external CA will depend on a number of factors

Can you dictate a new root CA to be added to all the clients who will need to use these certificates?  If there's a large number of clients and you don't control them, then you're likely to be better getting certificates isued by a CA who are already trusted by those clients
How many certificates do you need?  If you need a large number of certs, then they might lead you to use an internal CA as an external one will likely charge per certificate, and this could become expensive.

Probably the main concern is, can your organization effectively manage a CA?  PKI/CA management requires quite a lot of care and attention to do well.  Whilst it's possible to setup OpenSSL and create a CA with a few commands, effectively running a CA has operational problems to consider.  The main one is effective and secure management of certificates and their lifecycle.

As one example, you need to maintain the absolute security of the root key.  Loss of this (either loss of the data or compromise of it) could lead to you having to re-issue all the certificates in question, which if you're looking at embedded devices, could be painful, depending on how easy it is to apply updates to these systems.


The information in the two cited RFC's seems slightly contradictory regarding the NULL after algorithm.

The overall definition of the structure claims the parameters attribute is optional, however in the appendix regarding the rsaEncryption algorithm specifically there is this:

-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

And similarly specific hashing algorithms:

-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
--
md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

It seems a little silly to define a field as optional but later mandate its presence and value. Perhaps there are other algorithms where the field may be omitted, but these algorithms specifically require it?

The standard does seem to get confusing in the EMSA-PKCS1-v1_5 section where it talks about optional parameters with some algorithms:

-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted. However, an implementation MUST also accept
-- AlgorithmIdentifier values where the parameters are NULL.

But the example immediately following this text includes the null:

sha1    HashAlgorithm ::= {
    algorithm   id-sha1,
    parameters  SHA1Parameters : NULL  -- included for compatibility
                                       -- with existing implementations
}

All the ASN.1 examples I looked at in the documentation appear to include the mandatory optional null. Based on the behavior of both openssl (creation) and Mozilla PKIX (validation: https://hg.mozilla.org/mozilla-central/rev/08032b8280c6) the nulls-after-algorithm appears to be the generally accepted interpretation of the documentation, even though its required presence could be argued based on the original structure definition and the null does not appear to add value.

Update: I came across a posting on the OpenSSL mailing list https://mta.openssl.org/pipermail/openssl-dev/2015-January/000441.html that actually discusses this same issue, and the interpretation logic seems to be summed up (with some history) as follows:

... declaring that in this particular case (optional parameters of
AlgorithmIdentifier) NULL is equivalent to (the same as) absent. In fact,
RFC 5754 (page 4) states that the correct encoding is omitting the empty
list altogether, but some uses defined their encoding as NULL, and it’s OK.
It reveals some history of this duality:

The two alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax.  Later, the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory.  Because of this
history, some implementations encode parameters as a NULL element
while others omit them entirely.


It's complicated.  What I'll present below is a dramatically simplified version of the details.  (Because the real details are contained in hundreds of pages of RFCs.)  There are essentially 3 cryptographic steps to a TLS connection:

Authentication
Key Exchange
Encrypted Communications for the application

Authentication usually involves the server identifying itself to a client by presenting a certificate.  This certificate validates that you are talking to a legitimate server: it has the hostname of the server embedded in, the expiration date, and is signed by a legitimate certificate authority.  Additionally, it contains a public key -- possession of the matching private key is evidence that the certificate "belongs to you."  Most often, this is an RSA keypair, though it's also possible to use DSA or ECDSA, or even another Public Key system (but on the open Internet, it's almost always 2048 or 4096 bit RSA).  This is what gives clients certificate warnings (wrong hostname, bad CA, expired, etc.).  This is the part that you generate a key for, and it needs to match your cipher specification.

Secondly is key exchange.  If you're not looking for perfect forward secrecy, this can be as simple as the client encrypting a piece of data using the server's public key from its certificate.  The server then decrypts this, and both sides use it to generate the connection key.  On the other hand, if you want perfect forward secrecy (i.e., stealing the RSA key isn't enough to decrypt every previous connection) you use some variant of Diffie-Hellman key exchange: basically, a technique for arriving at a shared secret securely.  Without an active man in the middle, a 3rd party can't get the shared key, and the authentication step ensured you don't have an active man in the middle.  This DH step can be Diffie Hellman over an integer group (DHE) or over an elliptic curve (ECDHE).  Whether you use RSA, DHE, or ECDHE for the key exchange, you now have a secret key shared between the client and server that nobody else should have.

Finally, you get the actual encrypted communication.  Asymmetric crypo like RSA and DH are too slow for ongoing communications of large volumes, so we use symmetric crypto systems (like AES) for this.  This uses the shared key exchanged in the previous step to communicate.  Each packet is signed as well, either with an HMAC (so you might see SHA256 as part of your cipher specification) or a tag like GMAC from GCM (for AES-GCM).  Additionally, AES (and other ciphers) can be run in several modes: GCM, CTR, CBC, etc.

Some examples:

ECDHE-RSA-AES128-SHA256 means to use Elliptic Curve Diffie-Hellman for key exchange, RSA for authentication, and AES128 with SHA256 signing of messages.  (CBC mode is used, though not explicitly included.)

ECDHE-ECDSA-AES128-GCM-SHA256 is Elliptic Curve Diffie-Hellman for key exchange, Elliptic Curve DSA for authentication, AES 128 for crypto (GCM for signing packets, SHA256 for signing other data.)

AECDH-RC4-SHA is Anonymous Elliptic Curve Diffie Hellman for key exchange, no authentication (hence anonymous), RC4 for encryption, and SHA-1 for packet authentication.  (Please don't use this.  All of it is broken by modern standards.  It's an example.)


How do I secure my home Wi-Fi network in light of KRACK?

The answer is generally to patch, but in this case, a patch is not yet available for many devices.

While researching a particular device, the site basically said to update the firmware if the patch is available.  Otherwise (from NETGEAR's site):

  Until a firmware fix is available for your product, NETGEAR recommends that you follow these workaround procedures:
  For Wireless Routers in Bridge Mode: disable Bridge Mode or power off the bridge router.

I am not sure how broadly this workaround will apply.


How do I decide my specialization in cyber security?

Only you can decide your fate. Follow what makes you happy, where your passion is, and as you evolve through your career that drive will change multiple times making you a better candidate to employers. Network with others, goto conferences, and keep on learning!


A brief from Nmap website:

  -sn (No port scan)
  This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host discovery probes. This is often known as a “ping scan”, but you can also request that traceroute and NSE host scripts be run. This is by default one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.

So, the full command will be: nmap -sn 192.168.1.0/24 and if you're sure about some target, you can use -Pn (No ping scan).

For more info, check Nmap host discovery page.


How can I authenticate securely to an internal website from an iPad without an strong password?

Client certificates are your best bet - they allow the iPad to prove its identity without transmitting the confidential part (the private key). Even if the network is tapped, HTTPS is somehow broken or the destination server is compromised, the attacker won't be able to steal the key. It is also seamless and you don't even see the authentication - it all happens in the background during the TLS negotiation.

Smart cards would be a good idea to further protect the private key (if the iPad is compromised the key could still leak) but iOS has no support for them currently.

You can add two-factor authentication on top of that using TOTP for added security if your threat model requires it.

Biometrics add little security as they can't be changed if compromised (and given that we leave our fingerprints everywhere, it's good to assume they are indeed compromised), not to mention quite hard to pull off on iOS as there is no built-in support for it (Touch ID can only be used by apps, not websites, and only authenticates the user to the iPad - there would be no way of sending the fingerprint data to the server for verification).


Does HTTP Digest Auth provide any increased security in this scenario?

Yes, this adds some defense in depth, assuming the digest auth (or even Basic auth) is done by the webserver.  This would require requests to be authenticated before even hitting your application, meaning an attacker would be unable to exploit any vulnerabilities that might exist in the admin login.

That being said, is the security margin added by this sufficient to warrant the inconvenience to legitimate users?  Depends on your threat model & comfort in the security of your application.


What does this sudo -l output mean and can this be priv. escalated?

(scriptmanager : scriptmanager) NOPASSWD: ALL

means that you can run any command as scriptmanager, and optionally set your group to scriptmanager when doing so.
You won't need to provide a password when doing so.
The scriptmanager user (or group) may or may not have the privileges you ultimately want.


Can I VPN a phone's connection to my home network, and then apply my home firewall to my phones network connections?

Supposing both your VPN (server and client) support your desired configuration than absolutely what you're asking is technically feasible.

You'll need to configure traffic (on the server side) from clients to flow to the Internet and your client will need to tunnel all traffic and disallow local (local network where the client is) traffic to reach your client.

For more specific guidance you'll, of course, need to provide details.


I can send an email from your email account without your permission. How is this possible?

Email is an insecure protocol. It was designed to be open before the internet was commercialised.

Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) that help secure email. SPF specifies the IP addresses that are authorised to send mail on behalf of the domain. DKIM proves the email was sent by the owner using signatures.

The receiving email server has to check SPF and DKIM, and based on that can take actions such as discarding, bouncing, or marking emails as spam.


Can you force your PC or device to use only DNSSec-verified lookup results?

Can one actually configure an end-user client PC or device to force it to accept & use only DNS lookup results that are cryptographically-verified under DNSSec?

I don't think it is possible to do directly. What you might could do is to setup a DNS server which throws away any response which is not signed with DNSSec. Then you could setup your local network so that it uses this DNS server. This DNS server could even be run on the same host. I'm not aware of any existing server which can be configured to do this. But it should not be too hard to write such a server for personal use (i.e. no need to scale a lot).

But, since most of the servers on the internet are not using DNSSec yet you will effectively cut yourself this way from most of the internet. Nice for an experiment, but usually not useful in practice.

  or is DNSSec some purely external thing were a client is expected to "just trust" the end-output of some DNS server?"

DNSSec is usually not really integrated into the systems. That means applications on current Windows, Mac or Linux systems are usually not aware if the address they got for a host was retrieved using DNSSec or unprotected DNS. Even if the system resolver would know this, the current API's in the libraries and programming languages mostly do not expose this information to the application or it is unclear how much this information from the API can be trusted itself. For some interesting reading about the complexity of the issue see Support for DNSSEC in the GNU C Library.


How to find out if our files are digital watermarked?

TL;DR: It may not necessarily be possible.

Long explanation: Most digital watermarks are visible, as they're not intended to be hidden. For example, an image watermark may be overlaid on top of the original image. Another common watermark is as a metadata for file formats that supports metadata attachment.

But it's also possible to place a hidden, in-band watermark that is statistically indistinguishable from regular image, but can be checked by someone who knows how. For example, the distributor may alter the least significant bit of each pixel channels in an image so they form a unique signature that identifies the distributor or the original licensee.

Unless you have the original, unaltered version of the image, it may be impossible to detect the watermark made in such way. It may also be possible to detect the watermark by comparing the image against other licensed copy of the image.

Similar techniques exist for audio and video files, and some document format.


If you only need this for testing and debugging, why do you need it to be secure? You should not be debugging live systems while they are in a potentially hostile environment where a secure protocol would be needed. Considering the fact that even the very lightest secure protocol would eat up a significant portion of system memory, it would be silly to allocate such a high amount of resources for just debugging and testing. What you should do instead is only test your devices when you have physical control over them, ideally over a physical network link.

32 kB of RAM is really pushing it. Even Dropbear cannot run on a system that limited. Even doing TLS will be difficult, as WolfSSL may barely fit. The WolfSSL SSH library requires a minimum of 33 kB. It's likely that you'll need to develop this yourself, which should not be too difficult if you are using FreeRTOS. There is likely nothing that you can simply drop in to a 32 kB system.

If you are using Contiki as an RTOS, you may be able to use this TLS/DTLS implementation. It requires slightly more memory than 32 kB, but you should be able to strip it down sufficiently if you are familiar with embedded programming and optimization and don't need all the features.

When you begin to use systems this constrained, each individual system will have different priorities. As a result, no one creates a one-size-fits-all library for something as complicated as a secure remote access protocol. You are generally expected to be able to implement it yourself to fit your exact needs, either from scratch or by forking an extremely lightweight library. If you are not likely able to do this, you may have to rethink either your hardware and switch to something other than FreeRTOS, or your threat model (and communicate with the system over a secure medium).


How to get an "A" on Qualys SSL Labs with Apache 2.2?

Apache 2.2.26 added support for ephemeral Elliptic curve Diffie–Hellman (ECDHE). This is likely what is preventing your ability to get an A on on the test. Some Internet Explorer browsers will prefer non-forward secrecy cipher suites when ECDHE is not available. This can also depends on if you prefer the server cipher order and other factors.


User Binding Request with credentials in Lync Dump

IIRC, you need to enable MESSAGE-INTEGRITY mode for it to be secure. MESSAGE-INTEGRITY needs to enabled and supported on your STUN/TURN server.

Take a look at Microsoft's TURN/STUN RFC http://tools.ietf.org/html/rfc5766

Without MESSAGE-INTEGRITY, depending on the level of access of the attacker, a relfection attack might possible.

Disclaimer: It's been a while since I've dealt with Windows


Why aren't applications sandboxed in Windows?

Oh, but they are, good sir! Sandboxing is not a new concept and has been around since the 1980s; however, as you have probably gathered, the limits of those types of sandboxing have been pushed to the point from a security point of view they look inadequate.

About sandboxing and the permissions model

Let me explain. When your computer boots, it starts up in 16-bit real mode for compatibility reasons (i.e. so you can still run DOS). To cut to the chase, you basically switch to 32-bit protected mode or 64-bit long mode, which are slightly different, but also reasonably similar. At this point your x86-based CPU is in supervisor mode and must set up and handle things like page faults and sysenter or software interrupts so you can do system calls. Skip a few million lines of code to launch all your hardware devices and tada, your first process runs.

Your process, as you may know, is created knowing nothing about the underlying system memory - it sees virtual memory. It is also created running in normal mode (called ring 3) which means it can't do things like set interrupt handlers or alter page flags. In short, it can't see other processes' existence (it "believes" it has full run of the computer) except by asking the operating system.

So, your average every day process is sandboxed, after a fashion. Now, all processes* must ask the operating system to do things, including Administrator ones. What decides whether they can is... the operating system.

Currently, this is mostly done via user permissions. Processes inherit the context of the user they are running as; so a process run as an Administrator user can do anything because the Windows kernel will check its permissions, find out it is an administrator and say "yes, ok" (with exceptions; user mode processes can't technically do certain things but they can load kernel mode processes (e.g. drivers) that can). Likewise, on Linux, root is assumed to be able to do anything.

So the current model (and now I finally get to your question) says that processes inherit and can do exactly what your user can do.

Now this might be a reasonable assumption, except that you might want to have a sensitive word document on your disk and run a web browser. As a result of the fact that your web browser can do anything you the user can do, the fact that you can read the document using word means the web browser could, if it wanted to, as well and there exists no provisions to prevent this.

There are designs for more invasive, more sandboxed permissions systems for operating systems, such as MAC. These systems all propose variants of the idea that each process is additionally constrained in what it can do; so your web browser is allowed only to access the network, temporary storage and the downloads folder. I asked for reasons for their lack of uptake here and the general consensus appears to be complexity is a major factor. People understand the current model well, even if that understanding is simply "I run as Administrator to prevent all the annoying dialogs". MAC systems are inherently complicated; you need knowledge of what a process should be able to do to constrain it.

The much maligned much hated security-failure Windows Vista actually introduced, amongst a slew of other excellent security features and a rebuild of certain OS components, Mandatory Integrity Controls. These go some way to building MAC-type components into Windows.

So, tl;dr for the general question: MAC is hard to understand and complicated to implement.

About those API calls

Now, onto scary API calls:

VirtualProtectEx: Changes the protection on a region of committed pages in the virtual address space of a specified process
WriteProcessMemory: Writes data to an area of memory in a specified process. The entire area to be written to must be accessible or the operation fails.

Take a note of the notes on the bottom of the latter one:

  Any process that has a handle with PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process to be written to can call the function. Typically but not always, the process with address space that is being written to is being debugged.

These all-caps values are constants which represent Windows permissions - you can only call that function if you have or can obtain those permissions on a process. On the former function, note:

  The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.

The full set of process rights is discussed here. Now, most crucial of all to note is that you need SeDebugPrivilege. The details of this are best explained on the Old New Thing:

  By default, users can debug only processes that they own. In order to debug processes owned by other users, you have to possess the SeDebugPrivilege privilege. But don't grant this privilege casually, because once you do, you gave away farm.

So yes, it is possible for you as a user to call these functions and debug processes, but only ones you already own. As the permissions model allows any process you have to do anything your user (including processes you have running) can do, this is expected. Debugging your own processes is a reasonable activity, although yes, it could be used for ill - this ability is the crux of the issue with the current model.

Now, onto GetKeyboardState:

  An application can call this function to retrieve the current status of all the virtual keys. The status changes as a thread removes keyboard messages from its message queue.

All windows processes running GUIs have a message queue of events that have happened to them. What this says is that you can retrieve the keyboard state of your process after you have read an event. However, note that:

  The status does not change as keyboard messages are posted to the thread's message queue, nor does it change as keyboard messages are posted to or retrieved from message queues of other threads. (Exception: Threads that are connected through AttachThreadInput share the same keyboard state.)

So, yes, you can use AttachThreadInput to hook other processes inputs. There is a workaround for this - see How does Windows Secure Desktop Mode Work?. Essentially, Windows supports multiple desktops and by using these you make it impossible to AttachThreadInput onto them.

tl;dr these functions combined with the current security model do represent a risk and a limitation of the current model, especially to the data and processes of the current user; however, there are levels of security protection in place for your system as a whole provided you are not running as an Administrator user!


Two takes on PHP two way encryption - which one is preferable?

The two encryptions are equivalent. You can add a wrapper to use one approach as a drop-in replacement of the other:

/**
* Uses the one-parameter method as if it was the 2-parameter one.
*/
function buhlencrypt($keya, $data) {
   global $key;
   $key = $keya;
   return encrypt($data);
}

/**
* Uses the two-parameter method as if it was the one-parameter.
*/
function weidencrypt($data) {
   global $key;
   return encrypt($key, $data);
}

The "predictability" of MD5 adds a negligible level if 'insecurity' - 99.99999% of users will have their data hacked because they chose a trivial password or wrote it down in their address book or left it on a yellow sticky note under the keyboard. A professional attack will hack the server and gather all the passwords rather than bruteforcing a MD5 (see below, in answer to question 4).

  1.1: I've noticed that the encrypted result always ends in two equal signs ('=='). Why? - Using bin2hex() and hex2bin() in encrypt() and decrypt() instead of base64_encode()/base64_decode() respectively does not yield these results.

Base64 encoding works by replacing groups of three binary bytes (3 x 8 = 24 bits) with four ASCII-6 characters (4 x 6 = 24 bits). This means that the input text must have a length multiple of three and the output will always have a length multiple of four.

To ensure this, Base64 adds a special padding to its output to signify whether there are one or two "ignoreable" characters. And since Rijndael produces an output that is multiple of 16, the last 16-block is always padded to length 18.

  1.2: Will using bin2hex()/hex2bin() have any consequence on the outcome (other than length)?

None whatsoever.

  1.3: There seems to be some discussion whether or not to call a trim-function on the return result when decrypting

That is because Rijndael also uses a fixed size block, so if you were to encrypt 17 bytes, it would be divided in two 16-byte blocks, giving 32 bytes of which the last 15 are padding. Since Rijndael makes no provision to indicate pad stripping (e.g. it does not store the length of the cleartext), the output will have a zeroed padding that may need removal. In some contexts this may not be necessary since a zero-padding might be ignored no matter what.

  4: Bonus question!: I'm not incredibly brainy on server security aspects, but obviously gaining access to the PHP files would expose the key, which as a direct result, would render the encryption useless, assuming the attacker also has access to the DB. Is there any way to obscure the key?

If you do that symmetrically, then access to the PHP files will also allow removing the obscuration. Verify what level of access might one have once in possession of the PHP files. If his access is near to complete, it makes little sense to obfuscate the key.

However, you can do this, albeit in a roundabout way.

Add to your User model three properties (i.e. two column tables) called UserKey, RootKey and RootKeyOK. Each user gets a triplet.

When an user registers, you generate a random IV, and encrypt it using the user's password, storing it in UserKey. You also store it in the clear in RootKey, and set RootKeyOK to FALSE.

When the user changes the password, you use the old password to decrypt the UserKey and reencrypt it with the new password. You needn't touch the RootKeys at all.

Whenever the admin logs in, it browses the user database for keys not OK; for each of them it encrypts the RootKey with the Admin's password, and sets RootKeyOK to TRUE. This can be done automatically.

Now in your database you have:

HashedPassword --- unusable to an attacker since it's a hash.
UserKey        --- unusable since it's encrypted
RootKey        --- usable, IF still in the clear, but for this user's data only

When the user is logged in and you need to encrypt something only he (and the admin) can read, use his password (he's logged in, so it's in memory) to decrypt the userKey, and use the userKey to encrypt the data.

Of course, if you need to encrypt something when neither the user nor the admin are logged in, this approach won't work - you will have to store it unencrypted with a flag that tells it needs be encrypted, and do it as soon as either the user or the admin log in. While you can do this transparently to both, in truth the data may remain in the clear for long periods on the server, vulnerable to database capture (from remote break-in to hard disk burglary).


Sure you can, all you need to do is query all your switches for the mac-address table. From there you can see to which physical switch the user is connected to, all you need to do then is follow the TP-cable to the machine.

Wireless is a bit more complicated as you can only be sure about the access point the user is connected. If you aren't dealing with malicious users (who often spoof mac addresses) you can try to see if the user is using a particular chipset (based on the MAC address you can identify the chip vendor). From here you can establish what type of device it most likely is (it's not foolproof though).


Benefits of only allowing one password reset per day?

Only the owner of this service can tell what is their motivation.
One of motivations may be following. Some systems track the most recent passwords and don't allow the most recent passwords be reused very soon. For instance if user wants to reset password and reuse one of the 10 recent passwords, system would not allow this.
Some users would reset password 10 times within short time, let say within 5 minutes, their "favorite" password will not be in the list of the most recent 10 passwords, thus the system will allow to use that password again.
Thus, if the system policy forces users to regularly change their passwords, e.g. every 90 days, effectively some users can ignore this policy by multiple password resetting and eventually setting password back to their preferred value.
If users are allowed to reset password once a day only (or other relatively small number of times per day), they will not be able to reuse their preferred password very soon and will have to wait relatively long, e.g. 10 days, until the system "forgets" their preferred password and they can reuse it again. This can discourage many users from using this trick.


What is the proper way to escape bad data from link in javascript against xss

No, this is not the correct approach, and you are currently vulnerable to XSS via this payload:

http://example.com/yourscript.php/');alert('1

Attack

As seen above, an attack would be setting $actuallinkk to:

1');alert('1

Which results in:

<a href="javascript:reportUser('1&apos;&rpar;&semi;alert&lpar;&apos;1&act=inviteadmin')">

Now, this looks save enough, but it isn't. As the input is inside a HTML attribute context, the HTML parser will look at it and dereference the entities. It will then pass the result on to the JavaScript interpreter, at which point the code looks like this:

reportUser('123');alert('1&act=inviteadmin')

This will be executed, including the injected payload.

Defense

The above example shows why it is important to take the context into account when defending against XSS.

Inside a JavaScript context, you do not want to HTML encode, but instead escape all special characters with their hex values (see OWASP).


Why is OAuth 2.0 being used for mobile devices, and not OpenID?

OAuth and OpenID have different purposes. OpenID revolves around the concept of proving "who you are" and hence is useful in the scenarios where you use one login to log in to multiple sites. However, OpenID doesn't talk about authorization for taking certain actions or accessing certain data of Site1 while you're on Site2. For example, you're on FaceBook and want to import your contacts from GMail, OpenID won't help you, but OAuth will (you will use OAuth to authorize FaceBook application to fetch contacts from your GMail account). Furthermore, the level of access authorization is also controlled via OAuth (for example, some applications/websites can request for access to your Twitter Direct Messages, while others only request access to Post tweets on your behalf).

Since majority of Mobile device access situations are about accessing data or posting data to a service, you would find OAuth being mentioned appropriately in the context. If you find a situation where the application only requires a login (proving your identity), but does not require access to your account's data, then OpenID is equally applicable.

For further reading, I would recommend this blog post: OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing


Secure channel without identifying information

There are two parts to the security of an SSL/SSH channel: identity and security-against-eavesdropping.

If you want to not leak "identifying information," then you have no way to establish identity....... because that information is literally not there.

You can, however, establish communications secure from prying eyes by using a random key for every conversation. However, you won't be able to verify it's who you think it is, so you open yourself up to a MITM attack.

You COULD do something clever where you have a pre-shared secret and each side issues the other a challenge to sign a random, non-repeating identifier (like a guid). If both sides return the correctly-signed value, then both sides know they have previously shaken hands. I don't know if there's any standard like this anywhere.


Trusted execution environment vs dual microcontroller

This question is essentially comparing a full real microcontroller dedicated to executing trusted code and only trusted code vs. a "virtual" microcontroller, i.e. a trusted execution environment within an existing microcontroller.

A microcontroller with TEE essentially executes trusted and untrusted code on the same hardware and only provides a soft separation between trusted and untrusted code. Given that trusted and untrusted code share the same resources it is more likely to successfully execute side channel attacks based on timing or caching behavior (i.e. attacks like Meltdown or Spectre) then with a full hardware separation.

Other than that both setups can be messed up. The problem is usually that trusted and untrusted code somehow need to interact and it might be that the trusted code is handling data from the untrusted side without properly treating the data as fully untrusted. Software can and usually will have bugs and this is true for trusted code too. Another problem is how to make sure that only trusted code gets loaded into the trusted part of the system, especially considering that once trusted code might no longer be trusted since bugs in it were found.

Of course, having a single microcontroller with TEE has also advantages. These boil down to the advantages virtualization usually offers: less hardware needed and therefore cheaper to build, easier to integrate and less power needed.


What are the dangers of exposing weakly protected user accounts bound with a fake shell over ssh?

this fake shell does not have any security vulnerability by itself

... is usually the wrong assumption. I played with this idea some time ago, but I didn't find any reason why to do such a thing.

It might be interesting as a research of hackers/bots behaviour, but for that you have already existing solutions, that should be more appropriate and probably more secure and give you more data. Also if you want to play with honeypot and observe hackers, there are few assumptions you miss:

root is the most common target. Attacking on different users gives the attackers less possibilities to exploit. Giving up this account (either securing it well or disabling the login) you loose a lot of possible data.
Even simple passwords might be hard to guess in combination with common user names. If your use case is above (watching hackers/bots), than you might get really few data from such setup since most of the scans fail.

And few bits to your question:

your accounts might be exposed to different services, where they might be misused, for example SMTP to send SPAM through your server
the security of the shell as mentioned in the start once more and access from it to any resources (files, network, system calls, ...)


How many keys are used in this specific TLS 1.2 connection?

There are at least three keys:

X.509 public key: known to all parties who can connect and to the server: used to identify the server and as part of initial key exchange (first half of assymmetric key pair).
X.509 private key: known only to the server: used to prove that the server is entitled to represent itself as the subject of the public key (second half of assymmetric key pair)
session key: known to both the server and the single client of the connection: a symmetric key negotiated via key exchange and replaced based on cipher suite configuration. Used to encrypt data sent over the TLS connection

The session key can be replaced seamlessly during the session in certain configurations.  This can be used to provide PFS (perfect forward secrecy) in cipher suites that support it.

There is no inherent bound on the number of session keys that can be used for a single connection.

In some configurations one or more X.509 CA intermediate public keys (chain) are also in the signing chain of the server's public key.  These are known to all parties who connect to any server signed by the same chain and to the server.  The server must provide these keys during TLS handshake. In all configurations of a CA validated TLS connection the chain will be signed at the root by a root CA which your client software is configured to trust inherently.

If you are including CA certs there are at least four keys and possibly more if intermediate CA certs are used.


What this example shows is that class instances in Java are mutable: the contents of an instance can change during the lifetime of the instance. This can be surprising for people who have done too much Haskell but is otherwise a quite basic characteristic of Java, which is shared by many programming languages, including C, C++, Javascript, C#, Forth, Pascal...

Immutable instances are convenient for programming, in particular when several developers must collaborate. In Java, the String class is the canonical example of immutable instances: each String instance represents a given string which cannot be changed(*). When you want to modify a string, you call a method such as substring() which does not really modify the string; instead, it creates and return a new String instance, leaving the original string untouched. When you have immutable instances, you can keep them and share them with less precautions.

For instance, suppose that you have a class which represents an authenticated user:

public class AuthenticatedUser {

    private String name;

    public String getName()
    {
        return name;
    }
}

Such an instance keeps the name of the authenticated user in an internal field. The getName() method returns that name -- it can return the same instance that it keeps internally, because String instances are immutable: the caller will not be able to modify it anyway. So no need to build a copy, the public getName() can give the real string right away.

Mutable instances, by contrast, require more care and, often, a lot of copying. Failing to do that can result in subtle bugs, and security vulnerabilities are nothing else then bugs which have come to the attention of an ill-intentioned individual.

Java is a language which has some useful features for making immutable objects:
 - Its strong types forbid operations which do not follow the type systems (as opposed to, say, C, where everything is just a bunch of bytes and can be accessed as such).
 - Methods and fields can be tagged with a visibility such as the private above.
 - Java includes a garbage collector which is the necessary complement for sharing immutable instances across method calls (without automatic memory management, such sharing must include rules for who is responsible for releasing memory, and this rarely works well).

So the point your are describing is not a "Java vulnerability". Rather, it is a common source of bugs (some of which being vulnerabilities) which can be avoided thanks to the tools that Java provides. It would be more appropriate to call it a "C vulnerability, that you need not live with if you develop in Java".

(*) That's not entirely true: string instances can be modified through reflection -- albeit not reliably and in a standard way. Reflective access to private fields is a special permission which unsigned Java applet do not have, so do not worry about this.


What is a secure method to send pdf files with private information?

The easiest solution is to employ both zip encryption and also password protecting the PDF file. I'm quite partial to services like onetimesecret for sharing the actual passwords, but calling them with the actual passwords would work as well. The point is to make it easy for HR to access your documents but not thrown out in the open like you want. GPG encryption is of course much safer and the recommended method, but in this case you don't control the other end and they'd be less open to using this sort of solution.


There are a few things wrong with this construction.

You didn't define which encryption algorithm you're using. If you were to use a block cipher mode with padding, such as CBC, your design would be potentially vulnerable to a padding oracle attack, since your server must decrypt the encrypted expiration_time value before validating the authenticity record against the plaintext. You should apply authenticity checks against the ciphertext wherever possible.

It's also not clear how the delimiters work between fields. You should define how each individual field is separately produced to avoid any confusion on the decoding process.

While not critical, it's also bad practice to have a single shared key for both encryption/decryption and authenticity (HMAC). You should always aim to have independent keys for these.

All in all this is an overly complex design.

A simpler way is to just store the expiry time as a session variable, like this in PHP:

session_start();
$_SESSION['expiry'] = time() + 60 * 60 * 24; // now +24 hours

And then in each request:

session_start();
if (!isset($_SESSION['expiry']) || !is_int($_SESSION['expiry']))
{
    // expiry time has been unset or corrupted somewhere, log and fail
}
if ($_SESSION['expiry'] < time())
{
    // session expired, do whatever you need to do about this
}

This saves the complex cryptographic scheme and the client-side access to the token.


How to track down and remove Mac malware that is calling out?

ps l [pid] will list, among other things, the "parent process ID" (PPID) of the process. (If the parent process has exited, though, that information is lost and PPID will be 1.) ps eww [pid] will list its environment variables, which may give a hint where it came from.

Are you sure this is malware and not an unexpected behavior of something you're doing on purpose? Does it happen even if you aren't running Terminal.app?


Is testing for all executables without considering any files in the system is enough for deducing whether the system is infected with malware?

There are many, many things that are not "executables" in the usual sense but could still carry / deliver malware. Here are just a few:

Any kind of script, ranging from a batch file (.bat) on Windows to an NPM module.
Any shortcut (.lnk) or desktop (.desktop) file.
File formats with built-in programmability that can interact with the OS, such as MS Office documents that support macros (.doc / .docm / .xlsm / etc.).
Any library file (.dll / .so), which contains executable code but is not itself executable as a program (no main method).
Literally any file, regardless of extension, that contains an executable and has the execute permission (if invoked directly, such as from a shell).
Any archive file (.zip / .tar / etc.) that contains one of the above.

That's without even considering exploits, such as URIs that compromise a handler program, PDFs or HTML with JS that can break out of the sandbox, file-sharing programs with path traversal bugs that could be used to deliver malicious files to places you don't expect them, listening sockets (servers) that can't handle malicious packets, or so on. Then there's risks such as a malicious (or compromised) OS, malicious firmware, malicious hardware, and so on.

Again, this list is just the stuff off the top of my head and is NOT comprehensive. There is literally no way to say that a machine is 100% secure, and even if you had a magical virus scanner with 100% accuracy, and could scan literally every file on the disk (not just the executables), it still wouldn't be enough.


My app requires passwords be checked *locally* - how can I avoid security issues?

I think you have two choices:

Perform proper password security and send down hashes for the local system to verify
Use a "PIN" rather than a password to minimize harm if credentials are stolen.

To recap what you are asking, the obvious issue is that having to send down the credentials in some form increases the risks of credentials being stolen.  With password reuse a never-ending problem, passing people's passwords around for local validation is a danger to your users more than anything else.

Encryption doesn't really help a ton (or maybe depending on your security concerns) because regardless of what hoops you make the app jump through, the app still has to be able to verify the passwords offline, which means that there is a way to get back the plain text passwords.

Hashing

Probably the most secure way to use actual passwords is to just follow standard protocol and use a secure password hashing algorithm.  Obviously you therefore don't want a fast aglorithm, but I can't imagine the phone will be so much slower at hashing as to cause painful UI problems.  Obviously you'll have to reproduce your hashing algorithm on your phone - presumably that won't be too much of a problem for standard hashing algorithms.

The hashing provides a basic layer of protection against the passwords getting stolen in transit or from the phone.  Obviously though it won't protect weak passwords against brute forcing.  However, if these passwords aren't connected to user details otherwise (for instance email addresses), then that is less of an issue - every password I ever used could be splashed publicly across the internet but it wouldn't matter if my email address isn't connected to them.  If you can make sure that the passwords are not connected in any way to any personal information, then there is less of a concern.

PINs

The other option would be to use a PIN, as you mention, and make it definitively a PIN - numbers only.  This will keep people from reusing their password.  However, it won't keep people from reusing their ATM PIN number, so I would still keep these credentials far from any personal information.

In short, if all you have is a password or PIN then it is no longer really a password - it is just a unique identifier assigned to a user.  This is much less dangerous to have stolen (or at least, only dangerous to your app and what that unique ID allows a malicious user to do).  Therefore the best option is really just to make sure that these local passwords are never connected (or connectable) to actual user information.


What can an attacker do if he knew my database credentials?

Assuming that

You're 100% sure that your database server only accepts local connections.
You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed.
You're 100% sure that the application that uses the database is otherwise secure.
You're 100% sure that those credentials aren't used for anything else directly or indirectly related to the system.

Then, there's no problem in them being exposed.

Of course, as you can see, those are very big assumptions. If you're willing to take the bet, then go ahead and allow the credentials to be exposed. If not (I wouldn't), then work as best as you can on your security, and keep those credentials secret.


According to the E-book A survey of complex object technologies for digital libraries, DigiBox seems to be a container format that can contain different file types (although it was mostly used for PDFs). The basic concepts here are:

The file is encrypted in a way that it's relatively difficult to read without special software (i.e you can't just read these PDFs with any PDF reader, it has to be "DigiBox complient reader software")
The special software then goes to some lengths to prevent you from saving a copy of the file in a non DigiBox format, although you're right - it's not really feasible to protect the contents from being dumped out of memory by a seasoned professional.

  For example, if I had some sort of Word document that is protected. Can't I click save-as? Or does some DRM solutions work with Word to stop this?

You're right - the software that you're using to read the file needs to be complicit in the enforcement of DRM.

I think the main point here is not to make it impossible to break the DRM on the file, but to make it so difficult that the average (read: not technically skilled) person would rather just pay for it.


Your assumptions of how TLS works are mostly correct, i.e. the basic ideas are correct but some details (like how the pre-master-secret is generated) are wrong.

  ... in case of a site that uses https how do we know if it uses dh or ephemeral dh? And when to use dh or ephemeral dh in a https site?

Which authentication, type of key exchange, symmetric encryption and MAC is used is specified by the cipher. The client offers some ciphers and the server selects one of the offered ciphers. The ciphers which use ephemeral DH are the ones with DHE or ECDHE in their name, for example TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The ciphers which use non-ephemeral DH are the ones with only DH or ECDH in the name, like TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384.

Non-ephemeral DH requires that the static DH parameters (see TLS/SSL's usage of Non-Ephemeral DH vs DHE) are inside the certificate. This kind of certificate and therefore the kind of key exchange is very uncommon. If you check current browsers in SSLLabs client test you will see that none of these even offers DH/ECDH ciphers to the server but only DHE/ECDHE.


Installing Development Tools on Production Server? Security Risk?

In addition to @Karrax's correct answer, regarding increased attack surface, possible exploits, and easier attack environment for a potential hacker, I wanted to point out one more issue that should be obvious, but is often painfully not.

These are development tools. On a production server.
I infer from that, that not only do the developers have access to the production server, they apparently intend on developing on it.
This by itself has a whole bunch of risks associated with it, namely:

Unauthorized access to production data
No Least Privilege possible
No Segregation of Duties (SoD)
Highly probably there are lots of old, test, and unused code files
Highly probably there are lots of old, test, and unused configuration files - e.g. with a .bak filetype, allowing any user to download and steal passwords etc
No security testing before deployment
Easy to pop in hidden backdoors, because of the previous
Obviously, there is no SDL (security development lifecycle) in place
And more.

My point is that the problem isn't just installing the development tools, its the bigger problem is the process and environment around it that would cause such a plan in the first place.


Are SOCKS5 credentials safe during authentication on proxy server

Neither traffic nor credentials are encrypted in the SOCKS5 protocol. From RFC 1929:

  This document describes a subnegotiation that provides authentication services to the SOCKS protocol. Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where "sniffing" is possible and practical.


Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

For example, using TrueCrypt can't protect you from a determined attacker who has installed a hardware key logger and is reading everything you type.


Will quantum computers render AES obsolete?

Quantum computing will change the encryption game, but it is not yet clear how much it will change.  It's not clear because we are not yet certain what sorts of problems quantum computers can solve.  As mentioned, RSA is dramatically weakened by quantum computing because the factoring of primes can be done in polynomial time using Shor's Algorithm.  However, not all cryptographic routines are known to be as weak vs. quantum computing.

You may have heard of P (polynomial time), NP (nondeterministic polynomial time -- problems that given the right answer can be checked in polynomial time), and NP-Complete (the hardest NP problems).  Prime factorization of large composite numbers is known to be an NP problem and is thought by many to not be P problem.  That means a conventional computer would most likely¹ need super-polynomial time (at best sub-exponential time like GNFS) to do the factorization and RSA encryption depends on this.  NP-complete is a slightly more demanding class of problem.  Any instance of an NP problem can be reduced to an instance of an NP-complete problem. (This is true even if the NP problem is another NP-complete problem.) This means if you ever found a polynomial time solution for an NP-complete problem, you would have a polynomial time solution for every NP problem.  If you did so using a classical computer, you would have proven P = NP.

Quantum computers have their own complexity class.  BQP is the class of problems that can be [statistically] solved by a quantum computer in polynomial time.  It is known that factorization is in BQP, because we have Shor's algorithm.  What is yet unknown is whether BQP contains NP-complete or not.  It is currently theorized that it does not, meaning there are NP-complete problems that still take exponential time, even with a quantum computer, but the mathematicians are still crunching away at that theory.

Integer factorization sits in an interesting middle ground.  We know it is part of BQP (because we found Shor's algorithm).  We also know that it is a problem within NP (it is NP because the factorization can be proven in polynomial time just by multiplying the numbers back together).  What we don't yet know is whether it is P, NP-but-not-P, or NP-complete.  Nobody has been able to prove it one way or another.  It could actually be a P problem, solvable with a classical computer in polynomial time, making it very weak for encryption purposes.  It could be a NP-complete problem, which given that we know it is in BQP, would imply that quantum computers can solve any NP problem in polynomial time, which would be a major blow to cryptography in general.

Many upcoming encryption algorithms are starting to use other problems besides prime factorization as their root.  In particular, a set of problems based on lattices are thought to be particularly hard to break using quantum computers.  If all NP problems are part of BQP, this won't help any, but we're still figuring that detail out to this day.

As it turns out, AES is not affected by Shor's algorithm.  Grover's algorithm allows brute-forcing an n-bit key in O(2n/2) time instead of the O(2n) time required by classical computers.  Therefore, an 128-bit AES key could be brute forced in O(264) time by a sufficiently powerful quantum computer that can do Grover's algorithm with 128+ qubits for 2^64 time.

¹ The wise and challenging commenters below are picking away at the imprecision in my wording.  Technically it is not known whether NP problems requires exponential time or not.  It is possible that the NP class of problems and the P class of problems are the same.  However, most mathematicians believe it is much more likely that P != NP, simply because so far it doesn't look like it.  If we want to talk in betting terms, just look at how much you could make answering the question.  if you prove P and NP are distinct, you can earn the Clay prize of a million dollars, and maybe get a cushy job offer for being so smart.  If you prove they are the same, I would expect the NSA to be willing to pay quite a lot more for you to be silent about your discovery, and instead hand over your papers to their mathematicians.

If you are very interested in the topic of quantum computing and encryption, I highly recommend reading up on the different complexity classes such as P and NP.  They're worth your time.


Password Management within an Organisation

Although I've seen many implementations of solutions to this problem, I believe that the most complete, if not perhaps the most convenient, was a Git repository restricted to super users only containing encrypted text files of passwords by environment. Managing the password rotation on the devices, mixed servers and dedicated devices such as modems, was handled separately.

This solution greatly simplified the distribution of new passwords as a simple update needed to be performed by users to receive the latest revision of the passwords as well as providing a traceable history of previous passwords for record keeping.

As I recall the files were GPG encrypted, but there are numerous solutions and viable approaches to handling the files themselves.

The obvious downside to this approach is that, especially when passwords have changed, you are decrypting one or more files searching for the required password(s). Of course, as with anything, the more frequently you use a password the more likely you are to memorize it and, depending on the device(s) in question, access may be an infrequent event which is not greatly hindered by having to go through a somewhat more lengthy process to gain the appropriate password.

If you are also interested in strategies and/or scripts for generating and/or changing passwords on servers and/or other devices I would be glad to share those that I employ as well.

--

I would be glad to.

I will assume that you are familiar with file encryption, PGP or otherwise. If this is erroneous please feel free to ask and I will be happy to provide some examples.

Setting up a Git repository is relatively straightforward and will display similarities to most any content management solution with which you may be experienced. One note with Git: it is, by design, fully open and, as such, will require additional steps to restrict access to specific files or repositories. This can be accomplished relatively simply by leveraging file system acl's (just one possible solution). That being said, I would certainly recommend that you use a solution with which you are comfortable and familiar, especially if alternate content management solutions are already in use at your organization.

The file(s) will, by definition, represent a password database correlating device identifier(s), such as hostname, to passwords and, potentially, to user names. For example: router-1.internetdomainwebsite.com administrator soopersekretpasswerd. Ideally you will never store the file unencrypted, however, following this strategy does make retrieving passwords relatively inconvenient. For this reason I recommend scripting an accessor to work within your encryption framework, perhaps taking an identifier as a search term and writing only the requested password to a file for one-time use by the requester.

Any device that supports password changes can be scripted. Since most devices support changing passwords from a CLI, I would recommend taking a look at the Expect language and/or its libraries for Perl, Python, or the language of your choice. I personally use a script that accepts the desired username, accepts the current password, accepts and verifies the desired password, then changes and verifies the change on all hosts passed or provided when prompted. Its fairly bare-bones Perl with Expect.


Mutual Authentication - client authentication to the server via IP / FQDN?

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

Yes, this can be done. For the server certificate the client verifies not only the certificate chain of the servers certificate but also checks the subject against the hostname of the URL. With client certificates the server should do similar checks, i.e. check the subject of the certificate against the expected subject.

But the question remains what the expected subject should be. In case of a VPN this might be the IP address of the client or the FQDN as determined by a forward confirmed reverse DNS lookup. Or the server could have a specific configuration which  subject to expect from each VPN endpoint. Or if this is only a VPN to connect a single client to the company the client certificate might contain the email or the account name of the user.

Thus in summary: yes, this can be done but there is not a single true way. Instead how the subject should be done depends on how the product will be used and different products offer different ways of checking the subject of the certificate.


Assess risk with or without exising countermeasures

You have to consider the objective of you risk analysis. You want to assess the threats and know if these constitute a risk to your assets. So (TL;DR:) yes you should include current measures.

To do the risk analysis, if we based ourselves onto ISO27k models, you will define a risk formula, assess your vulnerability and exposure to the treats, then get a level of risk through computation of this formula. If this level is higher than your acceptance level, you have to act on it.

It does not matter whether you include current measure in or not. Without the countermeasure, it should raise the level above that threshold and force you to add additional information about countermeasure you place to reduce the risk. However, it's probably better to already take in account the existing measures and have the resulting risk factor already ok (don't add to your work).

The effectiveness of the countermeasure is a totally different aspect of the risk management, and it should appear quantitatively in other documents of your risk management system. Should they fail to be efficient, you would have to re-evaluate the risks and change them.

"the risk of a connection" is not a real risk element btw. "Data theft" or "User impersonation" are threats to your business. These threats can arises because of the vulnerability of the connection (among other thing). This vulnerability has a specific occurrence probability and a given impact if successful on your business. The goal of the risk analysis is by identifying vulnerabilities, related threats, impacts and plausibility of an attack success, if you suffer a great cost or not. If yes, you have to to something about it.

To conclude, I see no real benefit to not take into account the already in place countermeasures for the risk analysis. If you are worried about efficiency, you should refer to the indicators of your ISMS.


How protective should we be of an SSL client certificate?

Generally speaking, a client certificate is used to provide authentication (as opposed to encryption).  You need to ensure that the private key and passphrase (if any) are protected.  If someone gets them, then they can authenticate to the database using that certificate credential.  If your application instead required a password to access the database, then the equivalent would be someone else knowing that password.

Without knowing what app documentation you're looking at, I'll go out on a limb and say that the "client certificate" means the private key and signed certificate; the signed certificate includes as a matter of course the public key.  It's the private key that you really need to protect.


Is rootkit detection by comparison of file, process and connection lists a good practice?

It's a good method of detection, to repeat:

Memory check for hidden processes
Network traffic check
Filesystem check

The above solution is flexible, scalable and secure, however it's not your average scripting if large scale is involved, for which this is best suitable solution. But this doesn't mean it would not work on smaller scales, however effort might be too high. Possible implementation could be done in the following way:

Memory checks built-in Virtualization Host
Network traffic monitoring on the network layer (e.g. netflow)
Filesystem checks on the network storage layer

Now the problem is, since it's quite custom job, you won't be able to really rely on the results before sufficient time and money are spent on the development of such solution, so it works, but on large scale, e.g. a lot of servers, let's say, 10.000 of them or more, that would make sense. Also if these servers run various things and are not the same kind of server. However, there can be done some trade-offs, you might want to evaluate some software to do some of it, and then it may be easier to do, see below.

If you want to try by yourself, try setting up Netflow (sflow) monitoring and with just this, you can successfully detect malicious traffic when it happens. Using ready-made software would be more efficient. So for example, you can select patters for packets to raise alarm. A lot of unusual traffic can be successfully detected not only related to hacking and that helps a lot. It's cheap, easy, multi-purpose and effective. The only thing is you need to invent proper patters (e.g. which packets you want to capture), these could be basically anything unusual but permitted, e.g. outgoing tcp connections, which upon initial detection can be whitelisted if not malicious.
Another easy way would be to run tcpdump, then netstat and run comparison. But this is less useful, it would only detect hidden network connections, and if you search internet, you might find some helpful scripts already.

Regarding filesystems, you can also use normal script to check for the consistency of the binaries (for example, using standard rpm or dpkg commands), and also check consistency of config files. Such script can be run from external host which connects over ssh, uploads the generated script (e.g. with latest checksums calculated from git repo were are configs), run the check and return result. Rundeck may be software to help you with this. Running command from external host assures you it is being run at all in first place, and it's simple and efficient method in the end.

Regarding RAM, this is the most difficult part, and you may skip this part for the moment because it's more advanced. Dumping and analyzing RAM is far from anything easy.

Also look for chkrootkit and rkhunter scripts and similar. There's free antivirus Clamav and paid solutions like Kaspersky. These do check for known backdoors, however, in average corporate / hosting environment there's 50 / 50 chance if it's custom patched sshd with secret key or a known backdoor.

And don't forget at assuring whatever kernel is not patched or there's no malicious module, but that's a different subject. I would try researching it and using same script to check both kernel and hidden processes. There might be some scripts doing that on the internet already.

In summary, Netflow (or Sflow, it's the very same thing) will help you a lot not only with security but with the network as well. It has nothing to do with servers, it works the way, that switch sends every n-th packet to the netflow receiver whre it is checked against predefined patterns and accounted for stats. It should provide you reports as well. Filesystem checks are easy to do with rpm and dpkg, and the rest can be checked from git or with build server. Note that package managers are using crystallographic signatures so you do not need to use LiveCD. Finally, check out the kernel and hidden processes and you are sorted. And before deploying software, scan it with "Kaspersky".

Take time, develop a plan, and slowly bit by bit it's not hard to make it all.


On Windows, how to restrict access to a folder, sub folder and files to only some applications (not users)

Applications on Windows Operating Systems run in the context of the user executing it and therefore inherit the ACL of that user.

When looked at abstractly your program is doing nothing more than Word (winword.exe) or Excel (excel.exe) is doing with .doc or .xls files. You shouldn't need to restrict access of the data to only the application, risk reduction comes though:

limiting the users who have access to the data (ACL's, aka file permissions, ideally though a group)
limiting the operations a user can do (e.g. application installation to prevent malware)
application whitelisting
anti-malware protection
auditing for data integrity


What would be the application-level equivalent of dynamic communication secrets?

The second article (Safaka et al) describes a protocol which is based on a roughly similar to the Cachin-Maurer protocol that I describe at the end of this answer. The premise is that there is a broadcast unreliable communication channels between the involved parties, so that when one party emits a list of "packets", all others see only some of the packets, and not all of them see the same packets. So Alice and Bob, wishing to establish a shared secret, just have to emit a lot of packets, record what they receive, and then tell each other which packet they received (packets being referenced by some conventional ID). With high probability, the attacker could not see all the packets which both Alice and Bob recorded, so the concatenation of all packets, suitably hashed, is a good shared key.

In the Cachin-Maurer protocol, the broadcast is from a high-bandwidth random source, and the unreliability of reception is due to the impossibility of recording all of the data, because of the sheer size of it. In the Safaka protocol, the transport medium is assumed to be unreliable, which is a bit optimistic because the attacker may invest in a good antenna, something much better at picking up radio waves than the basic WiFi adapters of honest people.

Transporting that principle to application level looks hard because the really basic characteristic of the "application level", the reason why we call it "application", is its inherent reliability. For instance, raw IP packets are unreliable: they can get lost, duplicated, sometimes altered (I have seen it: a Cisco router with bad RAM), and arrive out of order. However, the first thing applications do is to apply TCP, which brings reliability (through acknowledges and re-emissions). When transport is reliable, it is reliable for everybody, including the attacker.

This is a generic trend: the kind of key exchange protocol we are talking about must rely on some physical process which enforces some unpredictability; in the Safaka protocol, the physical process is radio noise disrupting reception of some packets. The computer world, on the other hand, is mathematical rather than physical: it lives and strives in an abstract world where a bit is a bit and does not flip randomly. Indeed, when a RAM bit is flipped (this is said to occur about once every three months on average for a given machine, because of cosmic rays), the machine can crash, depending on where the said bit was. The whole principle of computerization is to run away from the physical world and keep it as far away as possible. This inherently prevents efficient usage of Safaka-like protocols, and even more so when we go higher up the layer stack, i.e. "at application level", as you put it.

A secondary point to make is that these protocols are key exchange, not authentication. They may provide security only against passive-only attackers, who observe but do not interfere. This is not a realistic assumption nowadays. A lot of network attacks involve positive actions from attackers; and some low-power attackers can be described as "active-only": it is often a lot easier to send fake packets to a server than to eavesdrop on packets between a server and an honest client.

Thus, some authentication is needed: you don't want to exchange a key in general, but a key with a specific client or server. To do that, you need some authentication mechanism which happens sufficiently early in the process, e.g. with public keys or some PAKE, and you are back to "normal cryptography", making the Safaka-like protocols rather pointless.


How to handle disk encryption for remote connection?

You can use dropbear ssh to ssh to your machine and then unlock the LUKS volume. There's a tutorial here which can assist you with setting up.


What is the purpose of TLS cipher suites pairing? Why are they paired the way they are?

We need more information about exactly what do you mean in your question, whether you're asking about TLS 1.3 or older versions, from SSLv3 up to TLS 1.2, which worked a little differently, and what kind of thing you would like to do that is currently impossible.

If you only intend to use primitives already specified for TLS and just want to mix and match them more freely, like SSH lets you do (KEX AUTH CIPHERS MAC), the answer for why you can't in TLS is probably partly historic and partly because fewer options means less complexity and more vetting of the allowed options.

It is more secure to have as few options as possible. Modern thinking is that cryptographic algorithm agility (an idea from the 1990s) was a mistake, and modern designs go as far as saying negotiation only causes trouble, and the correct thing to do is to only have a single negotiated value (protocol version) and to only support a single allowed value long term (you may need to support two possible values short term to allow upgrading clients and servers out of sync). So for example, with WireGuard, you get X25519  + ChaCha20Poly1305 + Blake2s. If any of the primitives turns out to be broken, or the joinery turns out to be broken, or something much faster is invented, or people decide to switch to something optimized for very different hardware, then the new protocol will be described with a new protocol identifier and people will switch, and there will not be a recommendation to maintain backwards compatibility for a long time.

So, if, for example, you want to do DHE 2048 + ECDSA P-256 + AES-128-GCM + SHA256 with TLS1.2, you can't, because there is no such cipher suite, although pretty standard client and server code could have supported this easily (IMO) and it would be secure to do (IMO). This is a restriction that I think buys little (improves combinatorics of test set).

What if you want to use your own primitive? For example, ECDH using Curve9767 instead of Curve25519 or NIST P-256? Or what if you want to use symmetric crypto based on Gimli or Xoodoo (also) instead of AESGCM or ChaPoly? Well, there are unassigned cipher suite ids you can use. You can implement a server that chooses your cipher suite if the client offers it, and implement a client that offers it and uses it if it is chosen by the server, and if the connection is made between a supporting client and server then the new cipher suite is used. This is how Google, Cloudflare and AWS did their post quantum cryptography experiments and how some people used national vanity ciphers ( ).

What if you want to change the PRF, so your client won't need to have a SHA2 implementation (suppose you use Blake3 in the signature and as MAC or something)? A ciphersuite can do that (IIRC).

What if you want to change the joinery, the way the primitives are combined?

For example, instead of using asymmetric signatures, you want to use ECDH+HMAC for asymmetric authentication, like Noise does. That might be a new value of SignatureAndHashAlgorithm that changes the flow (if offered by client and chosen by the server). Or maybe an extension. I'm not sure.

Basically, the idea is that ClientHello message looks the way the RFC says, but unknown cipher suites are allowed and new extensions are allowed, and an extension can change the protocol completely. Compliant middleboxes should not even expect the ServerHello, Certificate and ServeKeyExchange messages to be present and make sense, because an extension in ClientHello could mean "let's switch to a completely different protocol" to a server that supports it. Unfortunately, in practice, middleboxes are the bane of everyone's existence and TLS1.3 had to do some cosmetically weird things to work, and major alteration to TLS1.2 flow using extensions would probably not work for clients behind corporate middleboxes. But in your internal network it would be fine. TLS1.3 encrypts more of the handshake to hide what it does from middleboxes (and for privacy), so extending it is easier.

What if you want to use something other than X.509 certificates for asymmetric authentication? TLS spec says you must use X.509. If you change the protocol enough, it's time to stop calling your creation "TLS". This is what Google have done with what they use internally.


Managing SSH key access to AWS servers behind bastion

There is one big hole in this, which is that it is difficult to prove who did what action with shared accounts. Not impossible, just more difficult. In addition, the shared private key is a bad idea from a defense in depth strategy. You can solve both problems by managing the accounts individually, which creates greater management overhead, but it shouldn't be significant with just 5ish users.

I can't comment in depth on the opsworks idea, I haven't used it. Based on a quick read of the document you provided, it really just looks like it sets up accounts on your instances and then the authorized_keys file, which is a pretty small task. You also have to then spend the time setting all your users up with AWS IAM accounts, which doesn't seem like a good tradeoff.


The use of a REST style URL is unlikely to deter an attacker as it is a relatively well known development pattern these days with a number of popular frameworks using it.

When I'm testing REST based apps (usually pretty easy to spot due to the URL format) I'd always fuzz the URL paths (so, eg, user and mode) in this example as it's expected that they're going to be transformed in someway server-side.

Tools like burp have specific options which can be set on their scanning engines to target REST style apps.

From the BURP Help File

  REST-style URL parameters - The values of all directory and filename tokens within the file path portion of the URL. Testing each of these insertion points can impose a significant overhead and should only be used if you believe the application is using these locations to transmit parameter data.


How much harm can an attacker do on the Diffie-Hellman exchange?

Let's go with an example, you are MITM.

Alice sends Bob the prime number and the base, ie: p=23, g=5.
But... MITM changes p and g to 29 and 7.
So Bob agrees with Alice using p and g 29 and 7.
MITM man now can't change Bob response so it just send Alice 29 and 7.

Two options now, Alice can reject the 29 and 7 since they are not the original values and begin the negotiation again or Alice sends an acknowledgement to Bob for 29 and 7 values, let's consider the second option, since the first option ends up with no communication.

Alice agrees to use 29 and 7 as new P and G and select a secret number.
MITM now only can look and he will never now the secret number Alice has chosen. He can try to bruteforce, but that can take time and that is not the matter discussed.

So, in this case it doesn't really matter who chooses the prime numbers, in fact they could be public.

(It can actually compromise the communication by choosing very low prime number as 2 and 3 since a brute force attack to these number is actually easy, but I guess most algorithms will force big prime numbers).

As a last note, if the implementation is really buggy (as @GeneVincent suggest) and allow very low prime numbers, then you got it. You can listen the communication easily.


The definition by Gary McGraw:

  Software security is the idea of engineering software so that it continues to function correctly under malicious attack


If two endpoints establish a mutual authenticated connection (TLSv1.0) is the medium between the endpoints a concern?

The actual physical layer or data link layer do not present a security concern as long as you force mutual authentication and use a properly secure ciphersuite.

There is no direct risk with physical layer access. There is a future risk with it.

As somebody with access to the physical layer or data link layer has the possibility to store all traffic indefinitely, they can use future techniques and processing power to crack the current connection. If the data you transferred is only relevant in the now, no issue there. But keep that in mind when selecting a proper ciphersuite to use and determining the size of your certificate keys.

The security in your connection also relies on the certificates used and their trust-root. So the CA that is used for authenticating both sides is a security issue, as somebody able to compromise the CA can possibly also listen in on or manipulate future connection and/or spoof endpoints.


I have .Kismet files in my root directory. Where could they come from and are they dangerous?

ParrotOS being a security distro includes this IDS as part of the package parrot-tools. Learn more about how the logging can be configured here.

Those log files are a type of sqlite file. They are not encrypted but binary files. You can access their content using sqlite, an sqlite browser, or Kismet itself by using kismetdb_statistics.

Please refer to ParrotOS documentation and Kismet documentation for more information about this.


So how can I get Java to ignore the certificate pinning?

To get around certificate/public key pinning you must usually make changes to the application itself since the pinning is done there with an application specific trust manager. That means it does not work to just add your CA as trusted to the system wide CA store.

For a recent write-up of how this can be done see Defeating SSL Pinning in Coin's Android Application
.


How to transfer securely a file between servers?

The best way is to use SCP with SSH keys. It's some of the best encryption commonly available, designed to work without intervention, very reliable, easy to script, and extremely well documented. Set up your keys and a cron job.

The only other good option is to change your application design to sync the data over an encrypted channel, such as a mysql slave server using SSL (actual solution depends heavily on your app).

For scripting it, write up your own shell script:

#!/bin/sh
SOURCE="/path/to/source"
DEST="user@ip.ad.dr.ess:/path/to/dest"
KEY="/path/to/sshkey"
LOG="/path/to/logfile"

scp -i $KEY $SOURCE $DEST >> $LOG 2>> $LOG


How WPA supplicant can determine whether switch supports authentication or not?

This can be done in two ways, based on whether machine IP is statically configured or dynamically configured.

If machine is  configured for DHCP than a client can initiate the DHCP DISCOVER and wait for response from switch (authenticator). If a DHCP offer is received at client side than switch doesn't supports authentication and client can go ahead with further communication. If authentication is supported then switch will trigger the EAP request (identity) to the client (supplicant), so that the client can complete authentication. This can delay authentication by a few seconds depending upon the how fast switch sends EAP request on getting DHCP packets.

In case of statically configured IP, either a server can be configured so client server can communicate to check whether they have IP connectivity or not. For this approach, we need to make sure availability of the server. Alternatively, a client can send EAPOL start and wait for 30 seconds to check whether the switch asks for EAP request(identity) or not.


Advantages with PIN code authentication where the digits are placed at random positions?

This is to a large extent just security theater. It forces users to hop through a couple of hoops in the name of security, and thereby make them feel secure since they expended effort in the name of security.

That said, it does in fact defeat a simple key logger (since no keys are pressed) or a mouse click logger (since knowing the coordinates of a mouse click will not give you any information about what number was clicked).

However it does not protect against more sofisticated attacks. If someone has managed to install a keylogger on your computer, it is effectively game over. It is not longer your computer. If someone can install a keylogger, they can also install a program that hooks into your browser and logs everything being entered into a text or password field, or all outgoing HTTP and HTTPS requests before they are encrypted with TLS. Just like a keylogger, malware like this does not need to be targeted against a specific site to work.

In addition, they come with a number of security downsides (apart from the usability):

They are more vulnerable to "shoulder surfing", as the screen is harder to hide than the keyboard.
Since only numbers are allowed in this case, it limits the number of possible passwords and therefore makes brute force attacks easier. There are about 2000 million different passwords with six alphanumeric characters. There are 10 million different passwords with six numberic characters.

One upside, as techraf mention in comments, is that you avoid revealing smudge marks on touch devices.


Can SSL traffic encrypted with a weak cypher be bruteforced?

The scenario you exposed is not possible for the reasons described by Dave Thompson as in comments.

However, the concept you are talking about is called a SSL downgrade attack and occurs when the eavesdropper is able to alter the initial handshake. For exemple: breaking the connection to force the client to retry with lower SSL/TLS version: https://p16.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack

At this point, crypto-attacks are possible but they don't actually rely on bruteforce, except if a very weak cipher is used, but forcing user to use weak SSL version AND weak cipher suite is pretty hard. Most of the time, a cryptographic implementation flaw is present in older versions of SSL and allow to decrypt data in a certain way.

If one day you can intercept DES 56 bits stream, you can assume that, yes, it can be bruteforced with modern computer and in a easier way with dedicted cloud computing


How do I protect myself when using a public network?

Here are some useful tips from Kaspersky Lab’s team of Internet security experts:

Be aware
    Public Wi-Fi is inherently insecure – so be cautious.

Remember – any device could be at risk
    Laptops, smartphones, and tablets are all susceptible to the wireless security risks.

Treat all Wi-Fi links with suspicion
    Don’t just assume that the Wi-Fi link is legitimate. It could be a bogus link that has been set up by a cybercriminal that’s trying to capture valuable, personal information from unsuspecting users. Question everything – and don’t connect to an unknown or unrecognized wireless access point.

Try to verify it’s a legitimate wireless connection
    Some bogus links – that have been set up by malicious users – will have a connection name that’s deliberately similar to the coffee shop, hotel, or venue that’s offering free Wi-Fi. If you can speak with an employee at the location that’s providing the public Wi-Fi connection, ask for information about their legitimate Wi-Fi access point – such as the connection’s name and IP address.

Use a VPN (virtual private network)
    By using a VPN when you connect to a public Wi-Fi network, you’ll effectively be using a ‘private tunnel’ that encrypts all of your data that passes through the network. This can help to prevent cybercriminals – that are lurking on the network – from intercepting your data.

Avoid using specific types of website
    It’s a good idea to avoid logging into websites where there’s a chance that cybercriminals could capture your identity, passwords, or personal information – such as social networking sites, online banking services, or any websites that store your credit card information.

Consider using your cell phone
    If you need to access any websites that store or require the input of any sensitive information – including social networking, online shopping, and online banking sites – it may be worthwhile accessing them via your cell phone network, instead of the public Wi-Fi connection.

Protect your device against cyberattacks
    Make sure all of your devices are protected by a rigorous anti-malware and security solution – and ensure that it’s updated as regularly as possible.

Source


GnuPG "public key decryption failed: Invalid ID" using Yubikey Smartcard

I just ran into this problem today. I still have no idea what causes it, but I can reproduce it every time. I have gotten it to work consistently by doing the following:

plug in the yubikey
run gpg --card-edit
at the prompt type "verify" (and enter the password to unlock the card)
Quit out of gpg card edit, and then I am able to decrypt files as normal.

I am still looking for a less manual solution but this has been working for now.


Should I encrypt Blutooth communication?

Secure "enough" really depends on your use case.

Security is often a tradeoff between cost, time, user experience on product side but also cost, time and gain on the attackers side.

I assume your app is kind of product. So from marketing side, do you need to write "most secure ecryption possible" on your product or just "state of the art encrypted data transfer" ? Does anyone care?

How much could an attacker gain from sniffing the data? How much knowledge, time and money would it cost him?

Is your product usually used in a home environment? Then an attacker would maybe need to wait and sit very long in front of your house to sniff data at all. Not so realistic. Is your app usually used in front of an ATM? Then an attacker would know where to wait.

And then even if an attacker was able to sniff the raw data, can he decrypt it? I agree with comments above: If you can ensure that L3 with ECC192 will be used, a successful attack is very unlikely today.

Is the encrypted data of any value if decrypted in 10 years or so? If yes, maybe additional encryption would make sense, but I see rare use cases for that.

Using RFCOMM or not has little implucations on the security I think.