Account hacked on mobile music streaming app - what should I do next

I'd say you've done the right thing, adding 2fa and changing your passwords, cancelling credit cards, ect.

I'd recommend enabling 2fa everywhere you can, including the music app if you can, and change that password again- unless you've already done so since the last time you deleted the unknown device.

When you mentioned changing your password on a few other sites you frequent, that suggests that perhaps you've been reusing passwords? In any case, I highly recommend a password manager, such as LastPass, to enable you to have strong, unique passwords over all of your accounts.

To further prevent something like this happening, you could get a VPN to use on unsecure WiFi networks (or all the time) I use F-Secure's Freedome vpn all the time on my mobile devices.

Links:

List of Password Mangers - https://en.wikipedia.org/wiki/List_of_password_managers

Freedome - https://www.f-secure.com/en_GB/web/home_gb/freedome


Is there a way to prove that a program was executed on my Windows PC?

Regarding program execution: Some programs will copy themselves to a temporary directory on the Windows machine when executed from a USB stick, you could look for a program with the same name in temporary files directory on the computer of interest. You can also look at Windows Registry keys associated with recently executed programs such as "shell\bagMRU." You could also look for "prefetch" files associated with the program being executed.


CVE-2018-10933 - Bypass SSH Authentication - libssh vulnerability

...  does OpenSSH rely on libssh

OpenSSH (which is the standard SSH daemon on most systems) does not rely on libssh.

  I tried looking for openssh v.s. libssh ...

Actually, a search for openssh libssh gives me as first hit: OpenSSH/Development which includes for libssh the following statement :  "... libssh is an independent project ..."

Also, if OpenSSH would be affected you can sure that you would find such information at the official site for OpenSSH, which has explicitly a page about OpenSSH Security.

  Do Operating Systems like Debian, Ubunutu rely on libssh for SSH  ...

See the official documentation of libssh on who is using it (at least): KDE, GitHub...

You can also check which available or installed packages on your own OS depend on libssh. e.g. for Debian and similar (e.g. Ubuntu) this would be apt rdepends libssh-4 or apt rdepends --installed libssh-4.

Note that the use of libssh does not necessarily mean that the product is automatically vulnerable. First, the problem seems to be only relevant when using libssh for SSH server not client. And even in the server role it is not necessarily affected, for example Github seems to be not affected even though they use libssh in the server role.


SSL / TLS: Is a server always required to respond to a close notify?

The close notify should be sent by both client and server according to the specifications.

RFC 2246 Section:

  The client and the server must share knowledge that the connection is
  ending in order to avoid a truncation attack.  Either party may
  initiate the exchange of closing messages.

  close_notify
        This message notifies the recipient that the sender will not send
        any more messages on this connection.  Note that as of TLS 1.1,
        failure to properly close a connection no longer requires that a
        session not be resumed.  This is a change from TLS 1.0 to conform
        with widespread implementation practice.

  Either party may initiate a close by sending a close_notify alert.
  Any data received after a closure alert is ignored.

Now, not all implementations follow the specifications.  Everyone is shocked... I know.  Look at the bolded part of that quote.  They changed the spec in 1.1 because wide spread implementations do not send close_notify messages.

To ensure that your app is doing its due diligence you should always send the close_notify.  The important thing for you is to ignore any other data that is sent to you except a close_notify.  As far as you're concerned the connection is over.  It is nice to hear this from the server, but all you need to do is drop any other data that comes along the tunnel.

As stated in the above quote, in TLS 1.1 you can still resume sessions even if one side does not perform a close_notify.

This does mean that you're susceptible to a truncation attack:

Truncation attack

A TLS truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no more data from sender) to close the connection. The server therefore doesn't receive the logout request and is unaware of the abnormal termination.

This is one good reason why most financial sites log you out if a session expires or times out.


Is there any protection against malicious devices on a CAN bus?

CAN is designed to be relatively simple and is often implemented between microcontrollers with very little processing power (that are busy doing stuff where timings are important), and is used to relay messages in real time. Adding some encryption and DoS protection would introduce too much complexity and given that it's just two wires shared by all controllers, I don't think DoS protection is even possible in this case (what are you going to do if a rogue device decides to flood the bus with garbage or continuously hold the data lines "high"?).

A partial solution would be to separate the network into multiple buses, like it's done in most (all?) cars, where a separate bus is used for critical elements, and gateways are used to relay specific messages between them. DoS on a single bus doesn't affect the other one.

It is indeed possible to reprogram the firmware of any controller :

There are even easy-to-use software and hardware for that. This particular screenshot shows a program capable of updating the firmware of engine controllers and instrument clusters, but I'm sure the same applies to all controllers, it's just that the demand for software capable of tampering with engine/instrument clusters is higher (for obvious reasons) than the ones capable of interacting with the airbag or ABS ones. I'm sure criminals are exploiting these flaws and it proves yet again that security by obscurity just doesn't work.

If you have the time to reverse-engineer the original firmware you can easily make your own malicious version, and all you need is 30 seconds of access to the car's CAN bus (via the diagnostic port) to install the new firmware. Of course, you can use the radio as an entry point (for example, by exploiting vulnerabilities in its MP3 decoding functions) to get onto the CAN bus and install malicious firmware on other controllers. The only security is obscurity of the protocol which decays over time.

Finally I don't think there is an efficient way of securing the CAN bus - encryption and authentication won't do much - it will indeed prevent intrusions on the bus (such as a rogue device connected to the diagnostic port) but won't prevent against compromising a device that's supposed to have access to the bus (like the radio) which would be the main entry point of an attacker.

About installing firmware, requiring a unique passphrase printed in the car's documents before any firmware can be installed is a good solution, it will prevent a compromised device on the bus from compromising other devices, while still allowing the legitimate owner of the car to tamper with the firmware if they want to (because having to pay 300€ and often more to the dealer to replace a lost key or reprogram an used controller is what I would call getting ripped off).


First, anyone who says "PCI compliance is baloney" is incompetent; you absolutely did the right thing by walking away from them.  Also note that PCI liability means you are on the hook not only for fines and card replacements, but all the fraud that was committed with card data stolen from your environment.  If the thieves buy a fleet of Ferraris, you are pretty much all done.  (There are other nuances to PCI liability, but web sales are pretty much guaranteed to be the least secure option, and will always shoulder more of the blame.)

Regarding auction software, consider looking for software that performs the functions you wish to offer, but does not perform the payment processing at all.  There are many players in the payment processing game; because Security Stack Exchange policy forbids product recommendations, we can't offer you a specific list.  There are many reputable big companies that take money over the web; you should have no trouble finding one.

A good way to find a payment company is to observe how they work.  Next time you're shopping on line, look to see if the payment company takes you to their branded web site for payment processing, then returns you to the store's site after your payment is approved.  That's the kind of payment company you should be looking to hire; it keeps all the PCI risk out of your hands.

Once you've seen how the various players in the payment space operate, you'll know what to look for and who to ask for in your auction software shopping.  Some may prefer one payment gateway over another, or offer only one option; that might be OK if you don't mind their choice of providers.  If the auction software company doesn't already offer such integration built in to their off-the-rack package, ask when they plan to offer it, not if.  Let them know you're only going to buy a package that offers you complete isolation from the payment environment.


How real is the threat of MITM when you have your own network

Your direct ISP is only a very small part of the chain, there's many scenarios where your network traffic could potentially be accessible to hostile agents. Don't forget that in many cases hostile agents might also have the resources of a nation state (eg. in the case of mass surveillance):

You may trust your ISP, but do you trust the ISP of the party you're connecting to and all the networks in-between? Which might be in another country. TLS may protect the content of your requests against intermediate ISPs and/or government surveillance.
There's the threat of malware on either your client or your router. TLS is end to end so it may protect you if the system is compromised provided the integrity of the client implementing TLS is maintained.
What if your traffic doesn't end up going to who you intended? There could be instances where an IP is assigned to a new customer and your traffic for the old customer may go to the new. TLS could save you there.

On generally trustworthy networks the probability of your traffic being compromised might be low, but the consequences of your traffic being compromised are very high (eg. session cookies can easily be stolen which allow an attacker to log into your account for example). Considering that these days the overhead of implementing TLS isn't huge the cost/benefit is usually worthwhile.


Why is it harder to brute force an iphone than a zip-file?

Having only 1,000,000 possible combinations, an encrypted zip-file with a 6-digit numeric password, could be brute force cracked within a second.

This depends on the hashing or encryption algorithm, and the hardware as well.

  But for an iphone (let's say iOS9 if it matters), it is said that it would take years to do so.

Again, this depends on the hardware and algorithms used, and whether it's a hash, or if it's encryption.

  Of course there is the time-lock that restricts password attempts after a few failures.

You are trying to compare breaking the password on an offline zip file, whose brute force protections (if they even exist) can be circumvented by simply writing your own unzip utility, to the breaking of a password on an iPhone's lock screen which stops you after 10 incorrect attempts. The two are entirely different concepts and problems, but they do seem somewhat similar, I'll give you that.

  But I think there should be a way, by using an external device, to copy the encrypted iphone's data(the combination of 0s and 1s in the entire hardware) to bypass such 'software' restrictons.

Regarding the last part, please read Rory McCune's link.

Is there any hope to crack "impossible" encryption?

While some news articles are reporting that it's impossible to break the encryption of the iPhone, and "even the NSA can't do it," I'd take it with a grain of salt as this is a red herring.

Who cares about your Dr. Dalek AESontaren 256 billion bit Racnoss Encryption if you can exploit a vulnerability in the iPhone itself? Let's say in the example of a malicious application.

Instead of unlocking the heavily-fortified front door that's capable of withstanding tremendous punishment, what if you could just break the window and climb in? A vulnerability that allows you to run malicious code, which in turn allows you to view the actions of a user in real-time, and access the contents of their device, is the new frontier. If you can compromise any device, either Point A, or Point B, then encryption becomes a moot point.


Filter user input before the database or upon display?

Great question!  You are asking the right questions.

Short answer.  In most cases, escaping at the output side is the most important thing to do.  The best solution is to use a web development framework (such as Google ctemplate) that provides context-dependent automatic escaping and automatic defenses against other injection attacks (like prepared statements to avoid SQL injection).  This is likely to be more effective than sanitization on the input side.

Explanation. Here we have a flow of untrusted data from some input source (e.g., a URL parameter), through a complex chain of computations (e.g., through the database), and finally out to some output sink (e.g., dynamic content in a HTML template).  Where should we put the sanitization/escaping?  We could put it near the input, or near the output, or somewhere in the middle.  How do we decide where is best to put it?  I think that's what you are asking.

The first part of the puzzle is to realize that it is better to have a consistent policy.  It is better to put everything at the input, or everything at the output, than to sanitize 50% of the inputs and 50% of the outputs (if you do the latter, then it is too hard to check that your policy has been followed consistently, and it is too easy to end up with a flow of data from untrusted source to output sink that never gets sanitized/escaped).  It is better to have a policy that "everything in the database is already sanitized and escaped, and it can all be treated as trusted" or "nothing in the database is sanitized/escaped, and it should all be treated as untrusted" (or to have a policy which documents which fields in the database can be trusted to have already been sanitized/escaped, and which ones are trusted) than to have no documented policy.

The second part of the puzzle is to ask: What extra information do I need to know, to do the sanitization/escaping correctly?  Do I need to know some information about where the untrusted input came from?  Do I need to know some information about where it will be used (what part of the output it will be inserted into)?

In most cases, it turns out that the answer is: we need to know where the untrusted data will be used (where it will appear in the HTML output), but not where it came from.  We need to know where in the HTML document it will be inserted, because this determines the choice of escaping function: if it is inserted in between tags, then you should use HTML escaping to escape <, >, and &; if it is inserted inside an attribute, then you need to escape quotes as well; if it is inserted as a URL, then you also need to check the protocol scheme (to make sure it is not a javascript: URL).  This information is readily available at the output sink, but not at the input source.  If you perform escaping at the output side, then this information is readily available: when you insert dynamic data into a HTML document, you have all the information you need about what parse context it will be inserted in, at your fingertips.  On the other hand, if you try to sanitize at the input source, it is not clear where the data might be used, so it is hard to know how it needs to be escaped.  So this suggests escaping at the output sink, rather than sanitizing at the input source.

The third piece of the puzzle is that there are web programming frameworks that do context-sensitive auto-escaping.  Typically, they use a template system, and for each value that will be dynamically inserted into the template, they look at the HTML context where it will be inserted (is it between tags? inside an attribute? a URL value? inside Javascript?), figure out what escaping function needs to be used, and then automatically apply that escaping function.  This is a big win, because it ensures that the proper escaping function is used, and eliminates vulnerabilities where you forgot to escape some value.  Today, both of those kinds of vulnerabilities are common: developers often forget to escape some value, and when they do remember to escape, they often apply the wrong escaping function for the context where the value will be used.  Context-sensitive auto-escaping should essentially eliminate those vulnerabilities.

Discussion. That said, the best defense is to use both context-sensitive escaping at the output, and input validation/sanitization at the input.  I consider context-sensitive escaping your most important line of defense.  But sanitizing values at the input (based upon your expectation of what valid data should look like) is also a good idea, as a form of defense-in-depth.  It can eliminate or mitigate some kinds of programming errors, making it harder or impossible to exploit them.


PART 1: Generic explanation, unnecessary to read if you have read the question.

The first (how does the packet arrive at the attacker):

  Victim sends a packet with source IP '192.168.1.3' and source MAC
  '00:00:00:00:00:03' to destination IP 'DEST' and destination MAC
  '00:00:00:00:00:01'. Where 'DEST' is some external IP like '47.32.1.6'
  The router receives the packet and because the MAC is pointing to me
  (as the attacker) it forwards the packet to my interface.

The victim sends a packet with source IP '192.168.1.3' and sourced MAC '00:00:00:00:00:03'  to destination IP '47.32.1.6'. The victim cannot find a direct route to this address (as it is not in his subnet), so it sends the packet via the default route, to '192.168.1.1' (i.e. to the default gateway, the router in this case). However, as we are on ethernet, the victim needs a MAC address to send the packet. You mention that the router has MAC address '00:00:00:00:00:00', but the attacker has poisoned the victim's ARP table. Instead of the entry

192.168.1.1           00:00:00:00:00:00

the victim has the following entry in his ARP table:

192.168.1.1           00:00:00:00:00:01

(You can check this by opening a command line on the victim's PC, and running the command 'arp -a' before and after you started Ettercap).

This means that, whenever the victim tries to send a packet to the router OR to the external network, this packet will arrive at the attacker, until you 'RE-ARP' the victim.

The second (how does the packet arrive at its real destination):

  Now Ettercap gets the packet and recognizes the source IP as victim's IP (which is '192.168.1.3') and the destination IP as the router (second victim), then sends this packet to forward the packet to real host and allow streaming:

Before the poisoning starts, the attacker makes sure his ARP table contains the correct entries, like so:

192.168.1.1           00:00:00:00:00:00 (the router)
192.168.1.3           00:00:00:00:00:02 (the victim)

Now, in the first section, we stopped at the point where the external packet arrived at the attacker's PC, but of course, we need to make sure the packet reaches its 'real' destination. Otherwise, the victim would never get a real response, and would thus notice it fairly quickly that something's off. Therefore, the attacker wishes to forward the packet to its real destination: the default gateway (the router). This is possible, as the attacker knows the real MAC address of the router. It actually receives the following packet from the victim:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6
Destination MAC: 00:00:00:00:00:01
The fact that the destination IP is translated to the MAC address of the attacker, is because the victim will look up the destination IP in its routing table (route print), and it finds that it should send this packet to the default gateway. It therefore sends out an ARP request (or looks in his ARP table, arp -a), and notices that the MAC address the packet should be sent to is '00:00:00:00:00:01'

What's important here is the fact that the attacker sees that this is a packet that is actually not intended for him. A packet that would have been intended for him would look like this:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2
Destination MAC: 00:00:00:00:00:01

So, whenever the attacker receives a packet, he will check the source and destination IP, and forward it using his unpoisoned ARP-table, in this case to '00:00:00:00:00:00' (the router).

PART 2: Summary of the question asked

At first, the question was not fully clear to me. However, after CS explained it more carefully in chat, the question comes down to this:
In a set-up, where Ettercap is active AND a custom application listening on port 8080 is actively forwarding traffic (to the victim), and where port forwarding is active to redirect traffic coming in on port 80 to port 8080 (the custom app), why is it that the these packets (the one originally intended for port 80) arrive at the victim only once?

One might think that the following would happen:
- Packet comes in on port 80, actually intended for the victim, but redirected to the attacker because of an ARP poisoning attack
- Iptables redirects this packet to port 8080
- Ettercap forwards the packet to the victim
- The custom application, which is explicitly built for forwarding packets, also forwards the packet to the victim

However, the victim receives the packet only once. Why?

PART 3: The final answer

Ettercap will only forward traffic which has the following characteristics:

the dest mac address of the packet is the same of the mac address of the attacker
the dest ip is not the same as the ip address of the attacker

Now, the problem is that, by using the iptables REDIRECT command, the following happens:

the destination port is changed (from 80 to 8080 in this particular case)
the destination IP is changed to the main IP address of the device on which iptables is running.
as this is a PREROUTING rule, the above happens before the packet reaches Ettercap

It is the 'destination IP change' that answers the question why the packet is not forwarded twice. Imagine the following packet, intended for an external web server, coming from the victim:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6:80
Destination MAC: 00:00:00:00:00:01

If this packet were to arrive at Ettercap, the forwarding condition would have been fulfilled: The destination MAC of the packet is the attacker's, but the destination IP is not.

Now, this packet does not arrive in that form, the iptables REDIRECT command transforms it to the following:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2:8080
Destination MAC: 00:00:00:00:00:01

It does so, because 192.168.1.2 is the main IP address of the device on which the redirect command takes place. Thus, this packet will be ignored by Ettercap.

PART 4: Final insight

Now, the above is actually the same that happens in case you enable SSL dissection. To enable SSL dissection, the following lines need to be uncommented in etter.conf:

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

As you may notice, this is almost exactly the same command as the iptables command mentioned in the question. Therefore, the same applies: ettercap does NOT forward packets coming in on port 443. What happens is the following:

Traffic from the victim comes in, that is supposed to go to a https server
Because it is redirected by iptables, ettercap will not forward it anymore (as the destination IP is changed). This means all SSL traffic stays on the attacker's pc.
Ettercap then creates a fake server, with a fake certificate. It starts communicating with the real ssl server to provide HTML/JS, but the client talks DIRECTLY to ettercap. Packets are not forwarded anymore.

This is the same as in the case explained in the question, except for the fact that the SSL dissector does NOT forward traffic, whereas the application created by the TS still does.


Where can I find real life examples of software vulnerabilities in OSS?

Try this one (https://blogs.securiteam.com/index.php/archives/2543#more-2543), the advisory shows the vulnerable code and since it's an open source product the patch is available from the vendor source code (http://www.live555.com/liveMedia/public/).


Extrapolating home address of a visitor when they click on an e-mail phishing link (Mr Robot)

Does this count as phishing?

While people classify multiple things as phishing (often almost calling phishing almost anything), I wouldn't consider this as such, since no credentials are stolen. See for instance PhishTank definition:

Phishing is a fraudulent attempt to get you to provide personal information, including but not limited to, account information.

On the other hand, if the link led them to a page where they provided their FBI username and password, then I would count it as phishing.

How could he have derived the street address of the safe house, when usually internet visitors are identified online only by an IP address?

Through the ISP. While there are databases (both free and commercial) that geolocate IP addresses, they don't work with such precision as to identify an IP address as a given residential house.
The ISP will be assigning IP addresses to the customers (either quite statically, or potentially a new one each time they reboot they router), and only the ISP would know to which address they are assigned a given IP address at a certain time. This should in principle only be disclosed through a subpoena, although it would be possible for Elliot to have access to that if:

Elliot himself worked for the ISP and had access to such data
Elliot obtained that data from someone which had (legitimately or illegally) access to it (e.g. through bribery, blackmailing…)
Elliot has compromised the database where the ISP stores such data

Other ways to obtain the address not involving the ISP would include:

The page used the geolocation API to query the browser where it is and

somehow the feds granted the browser permission to disclose it
the browser itself has an accurate notion of its position, such as a smartphone with a GPS receiver

they provided the address to another service, and Elliot was able to fetch that from the other service.
For example: they previously bought pizzas from that connection, and provided their physical address for delivery. Elliot was able to look up (he compromised the pizza company?) that someone from that IP address requested a pizza to a given location 3 hours ago and concluded that the person currently using that same IP address is at that address.


Protect against cgi-bin/php attacks centos

This is the (URL) decoded value:

  POST /cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d
  suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d
  auto_prepend_file=php://input -d cgi.force_redirect=0 -d
  cgi.redirect_status_env=0 -n

This log entry tells me that an attempt has been made to exploit a PHP-CGI vulnerability from 2012.

It allows the attacker to override specific PHP configurations. In this case, one of the key modifications is to specify "auto_prepend_file=php://input" which will allow the attacker to send PHP code in the request body.

  How can I prevent from this attack ?

Regularly update your web server(s) and its components. It is also possible to prevent this earlier in the network by means of an IDS/IPS, which should detect this signature.


Should network firewall rules be secret?

It is normal that the only people with access to view and review the network rules are the network engineers and the security team.

The development team should know what ports and protocols are required to use their applications and work with the networks team to ensure the appropriate rules are in place. If there are standard ports in use by other applications, these might be re-used. Otherwise, when making changes for testing or deploying to prod, the applications team (or product owner etc) should coordinate with the networks team. The security team should be reviewing the change request to ensure no vulnerabilities are introduced.


How do I verify that in-app social login dialogs are secure?

You can't, at least not until mobile OS developers stop prioritizing UX over security.

For now the best you can do is to make sure the app you're using is from a legitimate and trusted developer, and the credentials it's asking for are related to the function of the app (a photo app asking for Instagram credentials to post on it seems alright, but the same photo app asking for Spotify credentials would be more suspicious). Also you should consider that particular account compromised by the app's developer so you should't use that account for information you don't want them to see. On some sites that don't revoke OAuth tokens on password changes, a solution to prevent future unauthorized (outside of the legitimate OAuth flow) access would be to change your password. As the OAuth token would still be valid, the legitimate functionality of the app should still work but sneaky attempts to login using the harvested password would no longer be successful. Of course, this isn't bulletproof as a truly malicious app would probably have a bot running on their servers that changes your account's email and password the second you enter it, preventing you from ever accessing your account.

In the long run, the solution would be to put pressure on mobile OS developers to either stop the nonsense described in my first link or at least provide a secure, OS-controlled WebView alternative that apps can use to request credentials. That WebView should prove to the user it's indeed OS-controlled (by doing something that normal apps can't, like intercepting a home button press) and clearly display the URL that's been requested by the app so it can't attempt to display a phishing site.


How much can I trust domain registrars to honor Whois identity protection services?

It would seem that with "proxy" registrations still leave customer IDs, but email addresses, physical addresses, phone numbers, etc., are left out.

A part to note is that it can also matter which domain name you pick. Not only was this cheaper in my case (with a .ca), but also arguably more secure.

For instance, using one of many WHOIS services on the internet, .ca domains will have less information available about them (my customer number replaced):

Domain name:           darkst3alth.ca
Domain status:         registered
Creation date:         2015/09/06
Expiry date:           2017/09/06
Updated date:          2016/10/21
DNSSEC:                Unsigned

Registrar:
    Name:              Go Daddy Domains Canada, Inc
    Number:            XXXXXXX

Name servers:
    pam.ns.cloudflare.com
    tim.ns.cloudflare.com

% WHOIS look-up made at 2016-11-26 00:35:29 (GMT)
%
% Use of CIRA's WHOIS service is governed by the Terms of Use in its Legal
% Notice, available at http://www.cira.ca/legal-notice/?lang=en
%
% (c) 2016 Canadian Internet Registration Authority, (http://www.cira.ca/)

As per GoDaddy's "Domain by Proxy", or "Domain Registration Privacy" feature, .com domains have much more available:

Domain Name: XXXXXXXX.com
Registry Domain ID: XXXXXXXXXX_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2016-08-26T23:33:53Z
Creation Date: 2016-08-26T23:33:53Z
Registrar Registration Expiration Date: 2018-08-26T23:33:53Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: email@godaddy.com
Registrar Abuse Contact Phone: +1.4806242505
Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Registry Registrant ID: Not Available From Registry
Registrant Name: Registration Private
Registrant Organization: Domains By Proxy, LLC
Registrant Street: DomainsByProxy.com
Registrant Street: 14747 N Northsight Blvd Suite 111, PMB 309
Registrant City: Scottsdale
Registrant State/Province: Arizona
Registrant Postal Code: 85260
Registrant Country: US
Registrant Phone: +1.4806242599
Registrant Phone Ext:
Registrant Fax: +1.4806242598
Registrant Fax Ext:
Registrant Email: email@domainsbyproxy.com
Registry Admin ID: Not Available From Registry
Admin Name: Registration Private
Admin Organization: Domains By Proxy, LLC
Admin Street: DomainsByProxy.com
Admin Street: 14747 N Northsight Blvd Suite 111, PMB 309
Admin City: Scottsdale
Admin State/Province: Arizona
Admin Postal Code: 85260
Admin Country: US
Admin Phone: +1.4806242599
Admin Phone Ext:
Admin Fax: +1.4806242598
Admin Fax Ext:
Admin Email: email@domainsbyproxy.com
Registry Tech ID: Not Available From Registry
Tech Name: Registration Private
Tech Organization: Domains By Proxy, LLC
Tech Street: DomainsByProxy.com
Tech Street: 14747 N Northsight Blvd Suite 111, PMB 309
Tech City: Scottsdale
Tech State/Province: Arizona
Tech Postal Code: 85260
Tech Country: US
Tech Phone: +1.4806242599
Tech Phone Ext:
Tech Fax: +1.4806242598
Tech Fax Ext:
Tech Email: email@domainsbyproxy.com
Name Server: NS77.DOMAINCONTROL.COM
Name Server: NS78.DOMAINCONTROL.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2016-10-27T18:00:00Z <<<

For more information on Whois status codes, please visit https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

****************************************************
See Business Registration Listing
****************************************************
Copy and paste the link below to view additional details:
http://who.godaddy.com/whoischeck.aspx?domain=3zliving.com

The data contained in GoDaddy.com, LLC's WhoIs database,
while believed by the company to be reliable, is provided "as is"
with no guarantee or warranties regarding its accuracy.  This
information is provided for the sole purpose of assisting you
in obtaining information about domain name registration records.
Any use of this data for any other purpose is expressly forbidden without the prior written
permission of GoDaddy.com, LLC.  By submitting an inquiry,
you agree to these terms of usage and limitations of warranty.  In particular,
you agree not to use this data to allow, enable, or otherwise make possible,
dissemination or collection of this data, in part or in its entirety, for any
purpose, such as the transmission of unsolicited advertising and
and solicitations of any kind, including spam.  You further agree
not to use this data to enable high volume, automated or robotic electronic
processes designed to collect or compile this data for any purpose,
including mining this data for your own personal or commercial purposes.

Please note: the registrant of the domain name is specified
in the "registrant" section.  In most cases, GoDaddy.com, LLC
is not the registrant of domain names listed in this database.


As @bonsaiviking commented, this is a form of DNS Registry Spam, and unfortunately it is very easy to do. The upside is, it's not an attack on your domain, and it shouldn't cause anyone actual problems (unless you are trying to sift through DNS records...)

The example of google.com given at the razzed.com link is as follows:

  whois google.com

  Whois Server Version 2.0

  Domain names in the .com and .net domains can now be registered
  with many different competing registrars. Go to http://www.internic.net
  for detailed information.

  GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
  GOOGLE.COM.ZZZZZ.DOWNLOAD.MOVIE.ONLINE.ZML2.COM
  GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM

  ...many lines left out

  GOOGLE.COM

  To single out one record, look it up with "xxx", where xxx is one of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record.


Can https be used instead of sftp for secure file transfers?

HTTPS and SFTP when used properly are equally safe.  The underlying encryption algorithms in practice are both functionally equivalent -- neither can be broken in practice by directly attacking the cryptographic protocols.

However, in practice with non-tech savvy user, HTTPS is slightly weaker in my opinion.

There are attacks on both that can be launched on uncareful, non-tech savvy users.   The attack on SFTP as Rell3oT said is that typically you initially do not know the public key of the SFTP when you first connect, and remember it for all subsequent connections (though the SSHFP DNS record defined in DNSSEC could solve this issue, but are not currently widely-used) .  This means an attacker who rerouted internet traffic initially to their fake sftp server could capture your data, if they targetted the attack on someone connecting to the sftp site for the first time from a computer (that does not have the public key saved).  This attack cannot happen on subsequent connections.

However, with https there are several more potential attacks introduced that non-tech-savvy users could get tricked into.

The user may not go to https://your-secure-file-transfer.com but instead just type your-secure-file-transfer.com into the web browser (which by default goes to the http version).  An attacker could wait for this case, and then capture this traffic and redirect it to their forged copy of that site; stealing the authentication information/financial data.  (Yes a similar thing could happen with sftp being replaced with ftp; but as its typically done in a separate app that saves the connection information this seems less likely -- to go to the ftp version the user typically has to manually type in a different port number).  You can fix this by requiring the site to have HSTS enabled.  Unless they are careful about the URL bar displaying https, the user may not notice they are at an http site or a different URL.  HSTS is only enabled on a small list of major websites by most browsers.  Most of the time, it gets enabled in a web browser after successfully visiting the HTTPS site the first time (where there is a header to remember that this site must always connect over https); giving functionally equivalent security to SFTP.
A non-tech savvy user's web browser is less secure than your standard SFTP client.  Users often install various browser extensions that have the ability to access all your internet activity to get some sort of functionality.  This added-on functionality may come with a secret attack; e.g., steal session cookies, information entered on forms (like their password), etc that eventually gets sent back to the client author.
The CA (or intermediate CA) could be compromised at any date and attackers could get browser-trusted certificates that allow them to spoof your https without detection.  This differs from SFTP again, where the sftp client remembers the public key for the site that it has seen before and alerts you if it has changed.  (Web browsers will not do this; certificates are allowed to change as long as they are properly signed.  Again this is not likely to change any time soon, as load balanced web servers generally all have different signed certificates.

All and all I'd say HTTPS is slightly weaker in practice than SFTP; while both are equally secure based on their cryptographic merits.  If you train your users to check that https is present and at the correct domain, and additionally instilled some paranoia about using browser extensions on their work computers (or suggest using browsers' private mode typically with few extensions installed) it will be roughly equivalent (assuming you have the site setup correctly with HSTS/secure http-only cookies, etc).


According to "Absolute Computrace Revisited" and "Absolute Computrace / System Requirements" answers to your questions are:

Yes (Ubuntu, Debian). There should not be a big problem for
CompuTrace developers to make it work with RH or SuSE I
believe, since SW versions, placement of binaries and packaging are
more or less standard in these distributions also. RH SeLinux and
SuSE AppArmor can be a bit of a problem, but it is more
administrative (to get a proper profile built-in) than technical.
Yes/probably. Since VPN just wraps IP traffic and routes all or part
    of it to another location, CompuTrace will follow that routing. If
    the addresses it wants to contact are routed to VPN gateway and the gateway
    does not know/is not configured to route these addresses further, CompuTrace will
    not work, but this issue is not specific to VPN, the same is also
    true for any router that has configurable routing tables. As for TOR
    if a TOR proxy is set in IE properties of a user then IE process launched by CompuTrace will also use this setting. Other ways to
    connect to Internet are not announced, but there is no problem for CompuTrace developers to build TOR presence detection and act accordingly.
On the first linked page there is a list of signs of CompuTrace
presence on a computer. Also on CompuTrace official site there is a list of laptop models where CompuTrace is preinstalled by manufacturers, so if you buy a new laptop that is in the list - you have CompuTrace.

And the answer to your last question would be "Yes, but..." Technically CompuTrace is a permanent irremovable (for an average/above-average user) backdoor. Legally it was not developed with malicious intentions in mind (or I hope so) so at least in some countries it is not considered malware. It is not an exploit per se, since it was made to function exactly like it functions, but it can be exploited by bad guys, just like any other network-enabled SW.


Is this token authorization scheme secure?

It sounds like you could benefit from a separate authorization server that all of your applications can depend upon.
In the long run it will probably be easier to make authentication/authorization a cross-cutting concern instead of copying users from on application to another.

OpenId Connect could be appropriate; it builds on top of OAuth2.

These might not be the flaws you are looking for, but consider these separate situations:

3 new system C, D, and E are introduced into the organization and users need to login into all of them
A new requirements arises for System B to call an HTTP API, System F, as the current user
A user is removed from System A
System A is decomissioned, but system B has become critical to the business
A user opens B directly, without going through A
Regenerating all the secret keys might cause unnecessary load on network/systems
The consultant company developing System B has to learn your custom authentication method
New team members have to learn your home grown authentication protocol instead of an industry standard
Having gained access to System A, an attacker also gets access to System B.

What you have described does not sound like token based authentication IMO. In token based authentication the username and password are exchanged for a token, which would be presented to System A with each request.
At a high level this is how I understand token based authentication to work:

Unauthenticated user browses to System A
System A redirects the users' browser to System Z, the authentication provider
The user enters her credentials into System Z
System Z redirects the user's browser back to System A, with a token
All subsequent requests from the user's browser to System A include the token
System A trusts tokens issued by System Z

Note that the user does not enter her credentials into System A.

The above steps are over-simplified; they do not include token expiry or refresh tokens. I have described the most simple OAuth2 authorization flow (implicit flow); the more common is the "Authorization Code Flow".
The Implicit Flow is suited to JavaScript clients, while the Authorization Code flow is suited to server based applications.
There is a lot of good information online on OAuth2 and OpenID Connect.


How to mitigate the new malicious USB cable USBHarpoon (NOT BadUSB) threat in an enterprise?

Depends on your OS.

If you're on Windows you can use Penteract Disguised-Keyboard Detector which will lock the screen when it detects any HID.

If you're on Linux, I think there exists software that whitelists or blacklists USB devices, therefore avoiding the need for awareness.


What Math has told you is correct if you assume uniqueness and equality. For example, from a = b + c, it follows that b = a - c. Why is that? Addition has an inverse function mapping a pair of integers to a unique integer again. If you think of + as a function with infix notation and two arguments. Think of - as the inverse of that function. Then you would get: a = +(b,c), and hence b = -(a,c).

The same way, you could think of hash as a function with two arguments. And the inverse would be some function hash'. I will discuss the existence of such hash' below. Then, we would get

h = hash(m,p).

However, we would not get m = hash'(h, p).

Why? The simple answer is that there does not exist a unique v such that given h we have that h = hash(v). The pigeonhole principle tells us that there must be collisions for hash (meaning that there must exist some h for which there are v1 and v2 such that hash(v1) = h = hash(v2)). This is because  the length of the images under hash is fixed. The length of the inputs of  hash, however, are not bounded. Therefore there is no function hash' that returns a single value. It would rather return something like a set of values.

Your question is why we cannot find such value(s) by (simply?) reverse engineering hash. The answer to this question lies in the way such hash functions are constructed. Their purpose is to compress and to obfuscate, meaning that a small variation in the input shall result in tremendous changes in the output. If you need more precise explanations, I recommend looking at a simple hash function like md5. The source code is publicly available. Just try to 'invert' it!


Managing and deploying web app passwords

Your question is very vague and covers a number of areas.  An example would be most helpful.

Based on the title of your question, it seems you're interested in how to securely handle credentials that are required by an application.  If this is a Microsoft environment one can encrypt sections of the web.config which is used to store sensitive information (SQL logon credentials, etc.).  This post offers a good explanation: why-to-use-rsa-for-dpapi-web-farm-encryption.  In short, if you have a single webserver DPAPI is the recommended solution whereas RSA keys are preferred for web farms.

However I believe you're also interested in a enterprise password management solution.  SANS instructor Jason Fossen posted a great entry on his Windows Security Blog.  He wrote a script that will assign a unique password to local accounts and leverages asymmetric encryption to save the password to a centralized location.  In the entry he also mentions a number of commercial products in the Password Vault or Enterprise Password Management space.

HSM is typically only used for critical accounts like domain/enterprise administrators or for certificates used by critical infrastructure.  For general or everyday use, these enterprise password management solutions are great.

Quite some time ago I looked into the Lieberman solution and found it to be very cool.  There's full auditing to log the user accessing credentials, what credentials were access, and of course when.  There's also flexibility to setup temporary accounts (only good for x time) which is useful for contractors, consultants, etc.


What is the recommended procedure for migrating 2-factor authentication to a new device?

I don't think that disabling 2FA entirely is a recommendable approach, but this update process is specific to the site/service implementing 2FA.

In the case of Google 2FA, I don't think disabling it is required, or even recommendable, if only for the practical implications.[1]

To migrate Google Two Factor Authentication to a new device, I'd recommend the following:

Make sure to have generated and saved/printed a set of emergency codes, in case anything goes wrong. You can also register a phone number to send codes to.[2]
Configure a new Authenticator app via your account preferences, using your old device to log in, and configuring Authenticator on the new one.[3]

If you are reinitializing the device that has Authenticator installed, you could do one of the following:

Login before wiping the old device, re-install and update the Authenticator prefs in your account, or
Use one of the aforementionned emergency codes to log in and update your prefs once the device is re-installed.

1: If you have set up app-specific passwords (e-mail client on your phone or computer, for example), they won't be able to connect while 2FA is turned off, and you may need to reconfigure all of them once you switch it back on.
  2: This will also prevent any catastrophic scenarios where a phone is lost along with its backups
  3: As far as I am aware of, Google 2FA does not allow you to have two Authenticator app's configured for your account. Once the new one is succesfully set up, the old one won't work.


In Healthcare IT, is a "break glass" mode to bypass access controls commonly required?

My healthcare organization uses Break The Glass with our EMR.  I work on the IT side of things so I'm not sure how it applies to the clinicians, but for us it is setup so that if we access any patient record we are required to Break The Glass.  In doing so we are forced to enter a comment as to why we need access to the record.

It's a good feature - with the introduction of the HITECH act, and of course with HIPAA, it is important to document why you went into a patient's chart.

As a patient, you have the right to request the names of all of the employees who accessed your medical record and you also have the right to know why they needed to see your chart.  By forcing the Break the Glass feature, we as employees are forced to create this documentation.  If we didn't have this documentation and a lawsuit was brought against my organization, the individuals who accessed the chart could be held liable if they cannot produce sufficient reason for entering the chart.

So in short, no it is not required, but it is an excellent way to mitigate risk - not only for your organization but for the individuals who can be held liable by HITECH and HIPAA.


What are the parameters to be logged in a web application?

If it was me, I'd want the following:

Precise timestamp (at least 1 second resolution)
Source IP address.
Source port, if possible.
Full set of request headers, if possible.
Session ID.
Forwarder headers (e.g. X_FORWARDED_FOR) are mandatory for tracing through  non-transparent proxies.
Full raw requested URL.
POST parameters if applicable.
Any other data specific to your webapp that might be useful in tracking actions.

In some cases, this information might be bulky. By splitting the logs off daily and archiving them in a compressed format, it should be possible to store a reasonable history of logs. It would also be acceptable to strip out the more verbose information (e.g. full POST data) after a couple of weeks, but that may limit the effectiveness of incident response and forensics for attacks that are detected at a later date.


Can you feed old unsalted hashes to a salted PBKDF function to increase security?

Well, I'd suggest BCrypt over PBKDF2.

That being said, your solution should be two-fold.

To secure the system immediately, yes your solution is good. Treat the MD5 as the input password, and have per-user salt as you suggest.
I would suggest migrating MD5 out of the picture. (unless this is strictly legacy application)

Next time the user signs in, your application will have access to the unhashed password, and will have the ability to update the hash with one that skips the MD5 step. You'll have to have some indicator on the account as to whether this has been completed.

I would also recommend pre-pending Pepper to the input password (or MD5) as an additional security precaution.

BCrypt has a max length on passwords, so it is best to place the input password combined with Pepper in an SHA-256 hash first. I'm not sure if PBKDF2 has this limit. Eventually you may one day use an even newer hash that does not have this limit either.

You know, really, migrating off of MD5 is probably not necessary, but getting rid of MD5 would be the ideal solution for best collision resistance and just seems like a cleaner design.


It really depends on who you are trying to secure the machine against.

If you just want to deter honest but creative users from plugging random USB devices in ports, some tape over the ports ought to be sufficient -- to remind them that this is not acceptable behaviour. Prefer some tamper-evident tape: this will make it more "official looking".

If you want to prevent evil attackers from plugging USB devices into the machine, conditions are harder. Such a person could also bring a screwdriver and open the laptop case altogether -- this is not that hard, and can be done relatively silently and quickly. Storing the machine in a hardened case would be safer. you would need some air flow to dissipate heat, but this can be as simple as a metal grid in front of the air holes of the laptop. The keyboard would still be a challenge: if the attacker can put his hands on the keyboard then he may "dive" through it (destructively, but attackers are not nice people).

Alternatively, you may plug an external keyboard, letting the wire exit the box, but this gives an entry point to the attacker: by dismantling the external keyboard, the attacker would gain access to some wires directly plugged into one of the laptop USB ports, the very thing you would like to avoid. Paradoxically, a wireless keyboard might be safer here, or not, depending on the details of the radio protocol between the keyboard and the dongle plugged in the laptop (and it would be in flagrant contradiction with the whole "air gap" concept).

To sum up, if the potential attacker is definitely hostile and has physical access to the machine, then you are in big trouble, and you need some really strong protection (supervision by an armed guard or even with CCTV could do the trick). If, on the other hand, the attacker is not really evil, then this becomes a matter of user education, and simple "plugs" should suffice.


Should users have access to the IPsec pre-shared key?

This is really too broad to have a single answer. If you trust your users enough to give them root/admin access, then they can get the PSK anyhow; nothing to be done about it. At some companies it's standard practice to give everybody root access if they want it; at others it's standard practice to never give it out at all except to the actual sysadmins. Neither of these are an industry-wide practice.
The same is true of hiding the PSK or not. If they don't trust (in the sense of "confident won't do something wrong, knowingly or by accident) employees enough to give root/admin, then it wouldn't surprise me if they don't trust employees to see the PSK. If they do trust employees to follow the principle of least privilege and only use elevated access when necessary, they might still keep the PSK secret because most people have no need to know (and they might not have considered your valid reasons to need it... or they might not think your reasons are valid).


Obtain X.509 Certificate Fingerprint from Certificate Info

No
I'd say no. Not in any practical way.

You'd have to have a parser to turn it back into a DER encoded ASN.1 data structure. This would give you the original certificate.

Two difficulties:
1. No parser. You probably don't have a parser to do this.
2. You'll miss ASN.1 details. Even if you did have a parser, not all information might be exposed to you.

Details are as follows:
Type information in ASN.1
Using ASN.1, the same information can be encoded in different ways. (For example: the "Common Name" field might be encoded as UTF-8 or something more like ASCII. And there is a tag field that says what the encoding is. So even if the encoded data looks exactly the same, it might be encoded in a different way. And this will totally change the hash value.)

Nesting in ASN.1
Also, there are different ways to nest things that wind up meaning the same thing. And I don't think "-noout -text" exposes these intricacies to you.

ASN1PARSE printout might save you
If you really, really want to know the innards of cert, you need OpenSSLs "asn1parse". (So if you had an asn1parse printout, then you could (in principle) parse this back into binary bit-perfectly.)


The two server may:

Have the same certificate
Have different certificates covering the same domain(s)
Have different certificates covering different domains, even with wildcard (but at least covering the domain you want for redundancy).

Valid examples:

For example.com:

Server1 certificate covers example.com
Server2 certificate covers www.example.com,example.com

For example.com:

Server1 certificate covers example.com
Server2 certificate covers *.example.com,example.com

For www.example.com:

Server1 certificate covers www.example.com
Server2 certificate covers www.example.com,example.com

For www.example.com:

Server1 certificate covers www.example.com,example.com
Server2 certificate covers *.example.com,example.com

Invalid example:

For example.com:

Server1 certificate covers example.com
Server2 certificate covers *.example.com
Because *.example.com is NOT valid for example.com

Security notes: Be careful, if the certificate of a server covers MORE domains than the server is supposed to answer, it may be vulnerable to virtual host confusion attacks.


Is it a bad idea to use a domain name to access my VPN?

If your IP is completely static, you could obviously use the IP address safely and reliably.  But you're fine using the CNAME, as long as you trust the entity hosting your DNS zone file.

If they're not trustworthy, or if they're sloppy, it's conceivable that some third party could substitute their own DNS records for yours and redirect vpn.example.com to their own "bad guy" server instead of your legitimate one.

It's always possible that you could get DNS-hijacking malware on your computer, or malware that fills your local hosts file with bogus entries. But if that happens, it's just as likely the the malware is recording your keystrokes and mailing them home, so you're compromised anyway in that situation.

Having said all of the above, however...

Are you connecting to your VPN from a lot of potentially suspicious places (open hotspots on the rough side of town, hotels, Internet cafes, etc.)?  If so, there's always a chance that those systems have been compromised and are pointing at poisoned DNS servers.

At least two mitigating factors jump to mind, though.

The first is that depending on the VPN technology you're using, you should get a warning if the server you reach isn't the one you intended to reach. OpenVPN uses assymetric encryption and your client VPN keys won't work with a rogue server unless that server has somehow been loaded with your server's private key (in which case you're already completely compromised). Microsoft's SSTP VPN (another HTTPS VPN) is protected with a SSL/TLS cert and should bark at you if the cert on the server isn't correct, and so on.

The second thing is that even if the DNS at some public WiFi hotspot has been poisoned, the owner of the poisoned DNS server would need to be specifically targeting your vpn server's CNAME in order to redirect you to a poisoned VPN server or relay. Unless you're a high-value target of some kind, that seems fairly unlikely.

EDIT: There are also anti-malware packages and other services that always redirect your machine to their own DNS servers.


What are the recommended scrypt cost factors for 2016?

In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay.

In most systems, I strive for a 10 to 20 ms delay. Assume your attacker has hardware that is, say, 1000 times more powerful than yours (which is not unreasonable, given that scrypt cannot be GPU-accelerated), he can try 105 guesses per second. For a 10-character alphanumeric password, that's 2610 passwords, or about 1014 potential guesses. That would take 109 seconds, or 31 years. Sounds acceptable to me.

If you want to use even higher delays, remember that scrypt is memory hard. This means it uses a (relative) lot of memory, in the order of megabytes, for each verification, so having a lot of them running in parallel might be more of a performance hit than the absolute processing power required.

Have a look at Security.stackexchange.com "Recommended # of iterations when using PKBDF2-SHA256?" for a good analysis of the same subject on PBKDF2.


With a PaaS, they manage both the hardware and software for you (which is different from IaaS, when they manage the hardware and you control the software).  The advantage of PaaS is of course that you have less to do - you hand them your application and they manage everything to make it run - hardware, OS, load balancing, automatic scaling, etc...  Many of these items can be a pain to manage properly, so PaaS has some helpful advantages.
I know you already know all of this, but your answer is hiding in there.  They manage everything, and as a result you implicitly assume that they are managing it properly.  Downtime, for any reason, is covered by your service agreement.  As a result:

If they are down because some critical hardware fails, they may owe you a refund
If they are down because they upgrade their software and crash their systems, they may owe you a refund
If they are down because ransomware takes over their systems, they may owe you a refund
If they are down because a virus takes over their infrastructure, they may owe you a refund
If they get hacked and the attacker walks away with your confidential information, you may be able to sue them for lots of money

So to recap:
Should they use an anti-virus?
Who knows!  If they are running an OS that requires an antivirus, then they probably should be.  If they are running something else, then they probably shouldn't.  Neither you nor I really "know" what their hardware/network/OS setup look like, so no one can answer that question for you.  The only question that really matters is:
Can they reliably provide the service they promised and keep your data safe too?
Answering that question goes far beyond the usage of anti-virus software, and is even more impossible to answer.  Therefore, the question you really want answered is to some extent unanswerable.  At least, I wouldn't expect them to talk extensively about antivirus usage or any details like that.  I would just expect them to make general promises about how awesome and secure they are, and probably mention as many positive reviews or referrals as they can squeeze out of their customers.  I don't expect your typical PaaS provider to let you "peek under the hood", so to speak, so at the end of the day it is really just about trust and the threat of legal action if they screw up.
Trusting a PaaS
Finally I think it's worth a brief aside to say that while you can't necessarily verify just how well a particular PaaS might secure their ecosystem, it's certainly worthwhile to ask whether a particular vendor might be trustworthy.  The problem is that egregious failures on the part of PaaS vendors have definitely happened.  The biggest example that comes to mind is Code Spaces.  Part of their services were data protection, for which they promised:

“Backing up data is one thing, but it is meaningless without a
recovery plan, not only that a recovery plan – and one that is
well-practiced and proven to work time and time again,” a cached
version of their website reads. “Code Spaces has a full recovery plan
that has been proven to work and is, in fact, practiced.”

Unfortunately they were hacked and had their full infrastructure destroyed by the attacker, effectively destroying all customer data and rendering them immediately out of business.  Some caution is required!


Methods to keep an autonomous log with high integrity

I would use an externally provided service (Splunk on Cloud, Papertrail - there are others but i have used these ones) to ensure reasonable integrity. Or use your own, separated from the service (based on a commercial solution or, for instance, ELK)

The confidentiality part is more tricky. For the Splunk case, if you have a pre-defined list of users, you could create views with a per user content and give read rights to appropriate users. This is hardly scaleable, though.


Reset password with email client which link checking

You could insert captcha on temporary page. It will exlude any automatical clients.

In addition, to spare users' time, you can create a whitelist of popular user-agents where captcha won't be needed. This way most users will not see additional step and you will be protected against automatical clients.

NOTE: This is NOT protection in terms of security. Remember that user-agent can be extremely easly spoofed by any client.


I agree with the answer that suggested the overall design of determining what is, and is not, a good system call may be difficult. Indeed, in isolation, a single system call might not be enough information.

In terms of the way Windows works, there are actually two levels of operation:

NT-level calls. These are the typical system calls you'd expect via sysenter to code in ntdll.dll i.e. Kernel mode routines.
The Win32 subsystem level. These are the functions implemented in advapi32.dll, kernel32.dll, user32.dll and others. Some of these act directly, others may call the above functions themselves depending on what is needed.

In addition to this, as a broad survey there are two abstraction layers on top of the Win32 subsystem:

COM and friends, also known as COM, COM+, DCOM, ActiveX, SuperDuper (okay, joking) and others.
.Net and friends. .net executables are modified PE binaries that load in mscoree.dll amongst other things and may use APIs in other .net binaries, or Win32, or via COM interfaces.

Now, for hooking techniques, you have:

Kernel. These days, ISR Hooking is tantamount to stability suicide unless you want to reverse engineer PatchGuard and disable it, or are permanently running your OS under a debugger. However, there are options for filtering implemented in Windows, provided by Filter Drivers. This is typically how an antivirus product might scan network activity and implement a firewall.
User. You have a few options here:

Patching the binary on launch. @Poly talked about code caves and redirects - given a target binary, one option is to overwrite code in its functions, or the functions of interesting APIs to redirect to your code. Typically, you don't have enough space to patch a jump to any old place in the address space, so you need a "code cave" near to the function to put your call/full size jump.
Alternatives to this include IAT Hooking, a way to modify a binary's import table to pull in your functions rather than the original target.
Another alternative is to use DLL redirection. Under Linux, you'd know this as LD_PRELOAD, - in plain English, you'd load your DLL of the same name and with matching symbols before the desired API dll, and steal the calls that way. It's even a feature of MSVC that you can produce redirected link functions in DLLs rather than having to implement your own stubs for things you don't care about!
You can patch COM calls by overwriting the relevant entry in the vtable of the resultant interface class.
There are other techniques, e.g. DLL Injection etc.

So if you are looking to implement a sandbox meeting your criteria, then there are a few considerations to take into account:

First up, where and what you hook. If you hook all of kernel32.dll it is still feasible that API calls may get around that if they do not call these functions. I don't know any COM or .net code like this, but I'd bet there is some.
You need to be careful with Kernel patching, as a result of PatchGuard. The filter manager provides most of what you could ever want to do antivirus (and therefore probably sandbox) wise, however, if you're going outside the filter manager you're going into unstable land pretty quickly. There may be limits to what you can do.
Then, whatever hooks you place in userland are almost definitely detectable by the sandbox assuming you are not using binary translation. For example, let's pick on patching CreateFile. Untrusted code could simply read the memory of this function and check that the prologue is as expected. Likewise, there are ways to detect injected dlls, IAT hooks etc.
The same applies to sandboxing kernel mode code. If you let the untrusted code install drivers, you are again on a level playing field with it.

This kind of work has been done - Sandboxie is one product that attempts to implement a sandbox at this kind of level, although it likely has more kernel level stuff than you'd necessarily like. I've only briefly looked at Sandboxie back when I knew less about this sort of thing, but I suspect a core component is kernel level because almost any amount of user mode hooking can be undone if you know to expect it. The only defence is to have a greater level of permission.

You've mentioned not having binary translation - I've not covered the various debugging APIs in Windows for this reason. Using these, you could essentially run a program as if you were stepping through it, and analyse any calls or jumps before they were made. However, this is basically binary translation, and debugging affects performance in any case. Not only that, but if I were writing a program to resist your sandbox, there are a number of known tricks for detecting debuggers (one being you can't debug a debugger, so if you relaunch yourself and try to debug that new process and can't, you're being debugged. This definitely applies to ptrace) which would render the program unusable in the sandbox.

On a positive note, most non-malware products would likely play well with whichever set of techniques you used, since they're probably not trying to resist running under these environments. This can be quite a useful fact.

Last but not least, I apologise for the excessive use of bullet points! And, my list of techniques for hooking calls is not exhaustive - there are definitely others.


Do cell-phones exist with open source baseband processors?

From a security perspective, you can achieve the same security either through a review of the component (which you want to achieve with an open-source baseband through the many-eyes-principle), or proper isolation.

Open source

The first appproach is very hard, as regulatory authorities need to certify your baseband firmware. Because of this certification requirement, even if you had an open-source baseband, it would need to be tivoized. You would perhaps see there is a backdoor, but you couldn't remove it.

Open sourcing generally does not imply anything over the security of the product. There are chilling effects from the easy possibility for a security review, which make backdoors harder to create. Of course, security patches can be provided by anyone and not just the vendor, which decreases the time between the discovery of a 0day and its fix. But that doesn't remove the need for a security review.

Isolation

Isolation removes the need for a security review of the isolated component, because the isolating component is reviewed instead. In that review, the isolated component may not be trusted at all. Google did this on the adobe pdf reader and flash player in chrome, and mozilla plans to do this on the adobe DRM plugin, to name two examples. In our case the baseband chip for example needs to be cut off the microphone line when its not having a call.

This approach is done by the Neo900 project. They state on their website:

  On Neo900 one can be sure that the modem is actually turned off when requested, not just pretending to be. User will be notified in case of modem wanting to do something without his consent.

Isolation perhaps renders backdoors in the baseband chip useless, but when there is a 0day in the isolating component, it can be used to gain control over the phone.

If you want to be sure the phone is off when it tells you so, you should remove its battery. This can be inconvenient, but with that you can be sure, as the other smaller batteries in the phone are not capable of sustaining the phone for a long time. However, sending a few weak beacons "Hello, this is me!" may be possible, but that is pure speculation.


Setting a temporary cookie to an invalid value when logout improves security?

Ultimately with a web application, the security should always reside at the server-side, and as such the important measure when a user is logged out of an application is to ensure that the session is no longer valid on the server-side.

I don't think that there's any harm in invalidating the session on the client-side as well, it might be useful to reduce load on the server as it doesn't need to do a look-up on the session ID to see if it's valid or perhaps to improve user experience in quickly routing a user to the login page.

However setting it on the client-side should not be considered a security measure.


What is the difference between privilege escalation and authorization bypass?

These terms focus on different aspects of the attack: privilege escalation describes what was achieved, i.e. gaining higher privileges, no matter how. Authorization bypass describes how things were done, i.e. by bypassing the authorization, no matter what was gained this way.


You can look for traffic patterns and the like, but there's significant crossover between the crowd that mines bitcoins, the crowd that knows how Tor works and the crowd that goes to amazing lengths to protect their privacy. That means: detection on the network isn't all that reliable. That it doesn't use a whole lot of bandwidth makes it especially hard.

What they likely can't hide is CPU and GPU usage. If you have access to the machine via SNMP, you can remotely watch for CPU spikes, or you can use the Get-Process PowerShell cmdlet against the machines on your network to look for things running up CPU time. For GPU time; you're not that likely to be able to actually spot the usage unless you can somehow monitor power draw.

Unfortunately, since you allow people to install software they want to arbitrary paths, you're not likely to be able to come up with a reliable, repeatable method - the people you're looking for could change miner, change path, etc. to change their signature.


Different password for each login - based on some variable

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings.

In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started.

You have to assume your clients are stupid, over complication login features with variating passwords will confuse them.

as for extra features for security many websites use features such as:

approved devices
2 factor authentication
advanced logging
IP restrictions
fail2ban (x amount of tries = lockout)
advanced analytics suggesting the real person isn't using the account (common with banks)

I hope some of these features give you some good ideas.

WARNING:

Your idea might interfer with password security, adding data onto the end of a hashed password could cause numerous errors, you should never be able to decrypt passwords and to do this something like this right you would want to change the password hashes in the database to have that number added onto it. I see you did mention hash and therefore you cant reverse the obfuscation. Though once again I do suggest that you avoid your idea as if this is a feature everyone knows about it.

anyway I imagine you would do this number feature would either be:

Predictable and therefore pointless (if i was a hacker I would simply expect this)
dirty coding forcing the feature rather than applying extra security


Wordpress - 3.9 - uploading a php file through media gallery

Generally you can not bypass it if there is no known vulnerability which allows this.

So far the mediagallery in WordPress does not have such a vulnerability and https://wpvulndb.com does not mention any vulnerability for the mentioned plugin.

You might find some vulnerability in the plugin using fuzzer, pentesting tools or by studying the sourcecode manually.


Print sensitive info without leaving data on the printer

High-End laser printers (and copiers) often have hard drives that store a significant history of documents, so this would be the worst option.
SoHo laser printers don't generally have hard drives but laser printers are page printers, an entire page of content is held in memory. Standard practice is to print several benign pages afterward to flush the memory. If you are more concerned, powering down the printer for a few minutes should dissipate any memory content remaining.
Inkjet printers are line devices, they have no need to store a page of content as they are only spewing several lines of ink in a rastered pattern. Very low end Windows ink-jet printers use the windows computer for formatting and serializing the ink lines. Higher end inkjets will hold pages like a laser printer and serialize the ink sprays internally. Like the SoHo laser, standard practice is to print several benign pages afterward to flush the memory. You can also follow this with a power down of the printer for more assurance.


Question about ipsec prevent SYN flooding attack

IPSec does not prevent SYN flooding. IPSec is a VPN at the network layer (i.e. IP) and not the transport layer (TCP, UDP). It will transport any IP packets and not look deeper. But since SYN is a capability of TCP and SYN flooding an attack thus at the transport layer a pure IPSec VPN will not detect SYN flooding.

Of course you could augment an IPSec VPN with additional software or hardware to detect such attacks the same way as you could augment plain (non-VPN) IP networks this way. Though it will not be possible to detect such attacks within the encrypted IPSec traffic but only in the decrypted traffic.


HTTP, the protocol used to communicate with webservers, without cookies is stateless -- it has no memory.  You make an HTTP request -- you tell your browser GET me the information from http://www.example.com/page01.html.  The webserver responds to your request and sends back the appropriate data, which your web browser then displays as appropriate.  If you then go visit a link to see page02.html, you start from scratch -- your browser asks the webserver GET the data from http://www.example.com/page02.html.  Yes, the webserver has your IP address, but if two people on your wifi network (same IP) both visit amazon.com, without cookies there would be no way to follow a unique user as they visit a variety of webpages in a weird order.

For interactive webpages where you can do actions on the web page, they need to keep track of the user to function.  E.g., if you go to a shopping website and want to add an item to your cart -- they need to keep track of who you are.  You wouldn't want some other user to suddenly see the items in your cart, or lose all the items in your cart every time you change the webpage by clicking a link.

Therefore, websites track users with a session cookie.  This is just a small text string -- typically 30 to 100 characters or so, that's randomly created for each user to be unique.  They store this identifier in a database, and attach information about each user in their database.  E.g., the user with the token e097e1136dc79bc1149e32a8a6bde5ef added 2 of item 38582 to the cart and 1 of item 57372 to their cart.

Then when you fetch a webpage from the dynamic website, you send the website your session cookie with your request -- GET http://www.example.com/dyanamic/page/ -- my cookie for example.com is e097e1136dc79bc1149e32a8a6bde5ef and then the webserver can look up your session cookie and recall all the information that is saved in the database about you so it can properly render the webpage you are supposed to see.

Note for a random 32 character session cookie with characters being 0-9 a-f, there are 2128 ~ 340 282 366 920 938 463 463 374 607 431 768 211 456 possible session cookies.  So even if a billion attackers tried a billion session cookies every second and did this for a billion years, they'd only be a 1 in 10000 chance they'd find your random session cookie.


Anonymity of prepaid SIM card in phone linked to real identity

Your Amazon purchased hardware provides identity information unique to the phone and unrelated to the SIM card.  You have linked the phone to yourself through that Amazon purchase and also via the previous use of that device with a SIM card with your identity.

The IMEI appears to be your main problem.  Please see details of identifiers here - http://developer.samsung.com/technical-doc/view.do?v=T000000103

Simply stated your scheme does not provide anonymity.


I agree with RobM.

  So it would be possible that they share everything they know about me with (american) governmental organizations.

Yes, very possible.

  Are there even alternative browsers which wouldn't do this?

The Onion Router. There may be others. Even Firefox will work this way if you use local syncing, and disable malware and phishing protection. Personally, I would not disable those.

Can you trust Firefox?

I don't think this is a Firefox issue. This is a government issue. For example, you can read about telecommunications data retention in various countries. The Electronic Frontier Foundation has a good write-up about the Stored Communications Act.

You should note that synchronization usually means your data is stored online. I am aware that local syncing is possible. However, because of the wording, they are likely storing your data online ("in the cloud"), and are required to hand it over to the proper authorities if compelled.

Let me reiterate: If, as a company, you're storing information online about users/customers, then in many cases you can be required to hand it over when compelled by law enforcement. If you are not storing information, you don't have to hand over what you don't have.

Firefox is storing information if you allow it. This is a very convenient feature which has the added affect of being held to government data regulations. If you ask me, Firefox is very trustworthy. However, do you trust the government of your country?

Even simple Metadata can be used to quickly identify you

Because of Metadata, whether this is encrypted or not may be irrelevant. They may be able to decrypt your cloud-stored data. Even then, it may not matter due to certain laws in certain countries. Wait, what?

For example: user connected to X server at Y time may be all they really need. As an example, you could be in China and end up visiting a website associated with Falun Gong. For Firefox to operate in China, they would be compelled to cooperate with Chinese law.

They may store your meta data details, such as the IP address you connected to before checking if it was a malicious website or not, even if you're behind a VPN at the time, your previous profile was associated with other IP addresses.

This is just a rough example of how meta data can work, and is not necessarily relevant to you. It's my hope that this would explain how powerful meta data is so you can apply it to other situations.

Firefox's Built-In Phishing / Malware Protection

Let's see what Mozilla has to say. How does built-in Phishing and Malware Protection work?:

  "Firefox will request a double-check to ensure that the reported site has not been removed from the list since your last update. This request does not include the address of the visited site, it only contains partial information derived from the address."

This partial information / metadata = exposed as a rebel sympathizer. The Death Star is on it's way.

If you don't like that idea, then don't sync online, and don't use the built-in phishing and malware protection. Personally, I don't like the concept of syncing in many situations. However, I will use the built-in phishing and malware protection as it helps minimize the amount of work I have to do while surfing the web, and it protects me!

Mozilla is up-front about what they are doing. They are not lying to you.

So why does Firefox cooperate with the government?

They have to. And why wouldn't they? In many cases, there are very good reasons to do so, for example, to track down criminals. Obeying the law is a cornerstone requirement to doing business in any country. If you don't like a country's laws, you have the choice to leave, and not do business there. Try to break those laws, and see how long you last.

Unfortunately, there are also cases where countries do not offer fair trials, and would quickly imprison, or even execute anyone caught engaging in banned activities, such as religious organizations like the Falun Gong. Again, if a company doesn't like the laws of a country, they may leave.

Raising awareness and fighting against corruption is one thing, and beyond the scope of this answer, but you can't expect to do any kind of business in any country, unless you obey their laws. And that's why Firefox provides this disclaimer. They are telling you the truth, even though they can hide it from you.

If you ask me, Firefox is very trustworthy. I don't know what your government is up to, or if Firefox has a presence in your country, though.


certificate chain ".DER" is same as intermediate certificate. Is it correct?

I used cat command to combine them into certificate chain ca-chain4k4k.cert.pem ...

openssl x509 -outform der -in certificate.pem -out certificate.der

  i converted intermediate4096.cert.pem and ca-chain4k4k.cert.pem into corresponding .der certificates. Both resulting files are binary equal.

The command you used essentially converted the first certificate in  intermediate4096.cert.pem and the first certificate in chain4k4k.cert.pem into the DER format. Since the first certificate in chain4k4k.cert.pem is the same as the first (and only) certificate in intermediate4096.cert.pem the result is the same.

  How can i attach root certificate information in the .der chain certificate.

You cannot simply concatenate multiple certificates in DER format. While with PEM simply concatenating all the certificates is possible with DER you would need a container like PKCS12. See Generating a PKCS#12 file with openSSL for examples on how to create PKCS#12 files with OpenSSL.


Issuing TSA (Time Stamping Authority) certificates

Your argument is correct, in most cases you should create an intermediate certificate, which issues your timestamping certificate.

The only reason I can think of for creating it directly from root would be, that managers of very small PKIs want to avoid the additional administrative overhead of an extra intermediate CA for a certificate type which will only be issued very seldom (probably less than one certificate per year). It can be done in a private enterprise setting, but it is definitely bad practice.


"Unexportable" means that the dedicated functions from the operating system will refuse to export the private key. However, it is of course there; this is just software, so the private key, when used, necessarily exists at some point in RAM with all its structure. The marking of the key as "non exportable" is a security system only against attackers who do not have administrator rights, and must act within the constraints of the API. Otherwise, export is rather easy. For that matter, a simple whole-system backup would be sufficient to obtain the private key.

To make key storage robust against local attackers (people who have access to the machine, and are technologically competent), you need a Hardware Security Module. This is an expensive piece of hardware, which will never give away a key which has been entrusted to it; it will actively destroy the keys if it detects a physical breach. Moreover, it will log all private key usages. Someone accessing the HSM physically could still obtain as many signatures as he wants, but they all will be logged and will not have the key itself (so he won't be able to sign afterwards). A cheaper (but somewhat less robust) version would be a smart card.

The usual method for securing access to code signing keys is to have two keys; a "development key" which is used for development, and a "production key" which is used only when an actual product is about to be shipped. Developers' machines are configured to accept the development key as valid, so that developers may work with code signed with the development key, but of course only the production public key is deployed in the user base. The idea is that signing with the production key should be sufficiently rare that you can do that in a non-automated way, under physical scrutiny of the management, and using dedicated hardware (e.g. a smart card which is normally kept in a safe).

(When using special hardware to store a private key, backups can be an issue. You should take care to either keep a safe copy of the key somewhere, or to be able to obtain a new one within a short notice.)


Is dual control password is a feasible way to secure against unauthorized login?

Well, by definition if some organisations are doing it, it must be feasible!

More generally, all security controls have a cost and when you select a control the cost must be taken into account. Is it worth it? If so, implement it. If not, don't.

Dual password control is a very powerful and effective control against loss of integrity; but as you point out it comes with a high cost in terms of systems complexity.

That's why it's pretty rare to see it used, but if the integrity of the data is important enough, that cost is worth paying. The classic example of dual control is the launch controls for a nuclear missile. If the possible impact of a failure includes the end of the world, it's hard to argue that the controls cost too much!


I don't think it's impossible considering where IT security was 20 years ago. It is very possible that he attacked the ATM remotely by dialing into it. It would require a certain skillset though.


Why does SSLStrip fail when user types HTTPS?

SSLstrip works by replacing HTTPS links in web pages returned by the server with HTTP links. This happens during a standard HTTP request, response exchange.

While the initial HTTPS call isn't encrypted, it is part of the TLS handshake and is definitely not standard HTTP requests. The TLS handshake can only result in a TLS connection or a connection failure. There's no way for it to magically become standard HTTP.

So there's no way for SSLstrip to downgrade an HTTPS request.


Issues with format of Logs generated by Auditd

Here is a quick fix for your datetime format conversion http://www.linuxquestions.org/questions/linux-software-2/how-can-i-read-the-audit-time-stamp-msg%3Daudit-1213186256-105-20663-a-648547

As to your lack of hostname that is a factor of using the name argument as you are (defaults to none if not properly configured) - see http://man7.org/linux/man-pages/man5/auditd.conf.5.html Replace that with name_format=hostname and that issue should disappear.


Have computer criminals been known to exploit easily-edited websites like Wikipedia to embed malicious scripts?

Assuming that you are coming from a BT connection, it's possible that this is part of the BT parental controls program.

There is a discussion of a similar looking pop-up here , which seems to tie into what you're seeing, and also a thread here on the BT site which has a link to a process to turn off that setting.

To test this theory you could log into your account and opt-out of parental controls. I wouldn't advice doing it from any link presented in the pop-up in case it is malicious though.

Once you've done that try accessing the same page to see if the issue re-occurs.

Another way to test it would be to access the site over HTTPS as then they shouldn't be able to inject any content unless they've installed a trusted root certificate in your browser, for which you would have needed to install BT software on the affected system.

As to your original questions about criminals injecting content into legitimate websites, this is a common vector of attack, either via compromise of the website (e.g. through exploitation of outdated software) or via content injected into the site such as adverts (this is common enough to have its own Wikipedia definition "malvertising")

As to whether it could happen to Wikipedia, I'm not aware of that occuring and with Wikipedia being such a well trafficked site, I'd expect it to be a large target.


Is using SHA256 to create 256bit secret key from bcrypt good ok?

First things first: AES is a standardized subset of the Rijndael cipher, which supports 128, 160, 192, 224, and 256-bit key sizes (AES restricts that to 128, 192, and 256, and also fixes the block size to always be 128). So you don't need to use 256 bits at all; you can, if you want to, but 128 and 192 also work even without stepping outside of AES per se and back to Rijndael.
Since key stretching (hashing a weaker key with an algorithm that produces a longer digest) doesn't add any entropy and therefore probably doesn't impact the security at all, you can either skip it (use AES-192 on the raw output of bcrypt) or you can use it (SHA-256 or even SHA3-256 hash the bcrypt output and then use AES-256). The only place I can think of where using a stretched key might be more secure is if quantum computing ever takes off, brute-forcing a 256-bit key might be enough harder than brute-forcing a 192-bit key to make a difference, but in that situation (actually, in most situations) the easiest option by far would be to just brute-force the password being fed to bcrypt.

Two other obligatory questions:

As @kelalaka asks, why use a 22-year-old password hashing algorithm, that only allows tuning the compute cost and has (by moderns standards) a very moderate memory cost, when newer algorithms that allow tuning both are available?
Why are you building your own password manager to begin with? There are so many options, both proprietary and open-source, most of which have been subjected to extensive review and stood up to actual field usage. Rolling your own cryptosystem isn't quite as bad an idea as rolling your own primitives, but it's still not a good idea. If you need to ask when or how to (safely) do key stretching, you might create a password manager as an interesting project, but you should think at least twice before actually storing any sensitive passwords in it.


What constitutes a Virtual Private Database?

The name is slightly misleading, but Oracle have obviously used it in a similar way to VPN being a virtual private network.

With a VPN, the network is actually public, but encryption and authentication provide privacy without the network itself needing to be private.

With Oracle's VPD, the database can be public (or at least open within an organisation) with access controlled through authentication and encryption so private areas can be created virtually within this public database.

In order to manage this, the database software needs to run the additional clauses and encryption to enforce the controls.

Your scenario, where the encryption and authentication is done separately to the database should still be able to provide the same Virtual Private Database.


You are correct about listening to all broadcasts on a wireless network.  In a wired network (modern network with packet switching without hubs), the big threat is Man in the Middle (MitM).  This can be done on the local network using Layer 2 MitM attacks like ARP Poisoning, and Layer 3 MitM attacks like HSRP or STP hijacking.  The former involves spoofing MAC addresses to inject a malicious computer between your computer and the default gateway, and the latter involves exploiting weakly configured routing/switching protocols to force all network traffic through a hacker's device.  On a grand scale, MitM can also be done by hijacking entire WAN segments by broadcasting a more specific BGP segment to neighboring BGP routers, or more covertly by nation states (think NSA) placing sniffers in telecom hubs.  The key overall is MitM.

In addition, there are more targeted attacks against a particular network by physically splicing into a network connection using a device like the Throwing Star LAN Tap.