Ability to get a MAC address and IPv6 through proxy servers Now I'm pretty sure I know the answer to this question, but I am just curious to see what the security experts of the world think of this.

First a little back story:

I was a former member of a website (I won't be saying any names) and they got mad at me because I was able to successfully exploit their site (after being asked to). I got banned and the rest is history. Turns out they threatened me (personally), and said they are capable of getting my MAC address.

So here's where I started asking questions, I was accessing their site one of three ways; Tor/TAILS, a VPN, or random proxies in random countries. The administrator of the website told me:

  "I am able to get your IPv6 and then your MAC address from that no matter how you enter the site, via my firewall."

If I am not mistaken, there are multiple issues with this statement:

You can turn IPv6 off on any system, and it is off by default
Getting a IPv6 address from a unfriendly proxy server would be extremely difficult
Getting an IPv6 from Tor/TAILS would be extremely difficult unless you had access to their exit nodes.
That networking just does not make sense in a security aspect

So my question being, would it be even remotely possible to get my IPv6/MAC from a firewall accessing a website via Tor/TAILS, proxies, or a VPN? And if so, how could this be done?

First and foremost, understand what a MAC (Media Access Control) address is and IP (Internet Protocol).

A MAC (semi-unique but not really) is an identifier for your network card to talk with it's local network at a level lower than Internet Protocol. Typically this is an ethernet packet along the lines of:

      | MAC | Flags | Payload_1 |

Inside the payload is your IP protocol.

As soon as the ethernet packet hits your local router or access point, everything except payload_1 is stripped away for connection to the next router up the line, becoming:

     | controls | Source address | Destination address | Payload_2 |

The MAC is gone, it's not part of Internet protocol! The only MAC the web site can get is his own router connection, yours is long gone.

As far as your IP, if you are using Tor or a functional anonymizing VPN, that's been changed as well by the time it hits the web server.

One odd exception is an obscure IPv6 auto configuration mode that computes an IPv6 address from your Mac. This can be reversed back to a MAC. Even if the Mac were obtained this way, at most it identifies the network card type (such as Netgear) and a number that may or may not be a real identifier that is not directly traceable.


Crack plain RSA given p, q and e How would one find the secret key in a simple RSA encryption when given p, q and e?

You've already been given everything you need to decrypt any messages.

RSA key generation works by computing:

n = pq
φ = (p-1)(q-1)
d = (1/e) mod φ

So given p, q, you can compute n and φ trivially via multiplication. From e and φ you can compute d, which is the secret key exponent. From there, your public key is [n, e] and your private key is [d, p, q]. Once you know those, you have the keys and can decrypt any messages - no cracking necessary!

More details are available here.


How do US government agencies open their email attachments? I suppose the FBI receives email with attachments, like any other government agency: documents, resumes/CVs, etc. I also suppose they are very careful not to get infected, more than the average user, for obvious reasons. If I were to send an email to the FBI, attaching maybe a PDF with my resume/CV, how are they going to open it?

So I wonder if US government agencies are known to use particular procedures or follow particular standards for dealing with emails safely. I also suppose what I'm asking is not secret information, given the large number of people involved (all the people who work in or for the government are expected to deal with emails safely).

While I cannot speak for every government agency everywhere, in highly secure environments, what I have seen [unable to disclose] is:

sandbox email attachments
no attachments but authorised, attributable file upload tools

In each instance, the attachment is inspected and run in an isolated sandbox. The recipient only interacts with the file through this abstraction.

Oftentimes, the content is extracted as text and reconstructed in a structured way, wherever that is possible.


Hashing email addresses for GDPR compliance UPDATED

We have a very unique scenario: We have several old databases of user accounts. We'd like a new system to be able to connect these old accounts to new accounts on the new system, if the user wishes it.

So for example, on System X you have an old account, with an old, (let's say) RPG character. On System Y you have another old account, with another RPG character on it.

On our new system, with their new account, we'd like our users to be able to search these old databases and claim their old RPG characters. (Our users want this functionality, too.)

We'd like to keep users' old account PII in our database for the sole purpose of allowing them to reconnect old accounts of their new accounts. This would benefit them and be a cool feature, but under GDPR and our privacy policy we will eventually need to delete this old PII from our databases.

BUT - What if we stored this old PII in such a way as that it was irreversible. I.e. Only someone with the information would ever get a positive match.

I'm not a security expert, but I understand that simple hashing (eg. MD5) is too far easy to hack (to put it mildly), and (technically) doesn't require "additional information" (ie. a key).

The good thing about MD5 is that it's fast (in the sense that it's deterministic), meaning we could scan a database of 100,000s rows very quickly looking for a match.

If MD5 (and SHA) are considered insecure to the point of being pointless, what else can we do to scan a database looking for a match? I'm guessing modern hashing, like bcrypt, would be designed to be slow for this very reason, and given that it's not deterministic means that it's unsuitable.

If we merged several aspects of PII into a field (eg. FirstnameLastnameEmailDOB) and then hashed that, it would essentially become heavily salted. Is this a silly solution?

MD5 or SHA is not the concern. Hashes can be used for pseudonymization. The problem is that the hash would need to be salted (or peppered) so that data from other sources could not be used to identify the person.

My email is the same everywhere. A hash of it would also be the same. So that means that, in this case, the hash and my email become synonymous. Just like a username and the legal name of a person if paired. If you use a hash in this case, you actually gain nothing in terms of GDPR.

Hashing with a salt (or pepper) makes de-anonymising nearly impossible without knowing the added value. The salt (or pepper) almost becomes the token, in this case.

As always, check with your DPO.


Denying sending email Here's the situation:

Person is denying sending an email.

I downloaded the original source file of the email which has all the digital signature details including IP address et al (in Gmail webmail show original)
I downloaded the same file of the denial email both IP and digital signatures match. This file is downloadable on both ends it's impossible for me to forge they need to match.

do I have a solid irrefutable evidence?

No, you do not have solid irrefutable evidence.  I could have stolen their password and sent the email from their account.

That being said, the key question you should ask yourself is how much proof do you need in the current environment.  If this is office politics, you may not need very much proof at all.  If you're trying to indite someone for selling state secrets, you're going to need a lot more proof.


Google Mail alert message. Hacker from China I have had a red warning box on top of the page when I access GMail. It says that there have been three attacks from China:

IP Address: 117.70.121.33
Location: Xuancheng, Anhui, China

and two others.
Is this common?
Could this be done from anywhere around the world or just from China? I mean, if the Chinese firewall will block hackers e.g. from France, US or Israel to access some computer in Xuancheng, Anhui, China and act as a Chinese attack or the wall is preventing from this.
It seems IMO that attacks from China is the most common place of attack. Is this just a coincidence or purposefully doing because it is not easy to ask Chinese government for permission of logs when using China servers for attacks on EU or US targets.

This is in an email from Google:

derfder,
Someone recently tried to use an application to sign in to your Google Account, --------------@gmail.com. We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:
Tuesday, October 23, 2012 10:06:26 AM GMT
IP Address: 117.70.121.33
Location: Xuancheng, Anhui, China
If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately. Find out how at http://support.google.com/accounts?p=reset_pw
If this was you, and you want to give this application access to your account, complete the troubleshooting steps listed at http://support.google.com/mail?p=client_login
Sincerely,
The Google Accounts Team

Well, there are actually a range of questions in there but the big one is your second last paragraph.

The Internet allows us to be attacked by individuals anywhere in the world.

Access controls help to prevent a lot of attacks, but all of them can be bypassed given enough effort, and this includes the Great Firewall of China along with every other device or application. The only way to be sure is to disconnect your computer entirely, then lock it in a room, and hide the key. And post guards. And watch the guards etc

So this is why security is really a business decision - you can get as much security as you pay for, but if you are a desirable target you need to buy much more security.

Various surveys by companies such as Kaspersky show the apparent sources of attacks, and China is high up there, but so are the US, Eastern Europe, Israel, the Philippines, and a wide range of countries. While some of this data is no doubt correct, some of it is likely to be spoofed by smart attackers routing through machines in other countries.

And the whole issue of getting logs from other countries - it is a nightmare. Many ISP's just won't divulge this info. Some countries block requests entirely.


"Do not enter your password unless you recognize this image" - how does this work? The login prompt for my student loan repayment site has two parts. You first enter your username, then it shows you an image as well as a password prompt. I picked the image when I first made my account from a few other potential images. However I don't see how this increases the security of the account at all. What's going on here?

I presume this to be form of mutual authentication. You're being displayed an image you had selected earlier. This way you can trust the incoming data from being original service provider. I am unsure for the effectiveness of the same especially in an MiTM attack.


How much harm can an attacker do on the Diffie-Hellman exchange? I'm looking at a system that uses an unprotected Diffie-Hellman exchange to negotiate a key for the session encryption.

That Diffie-Hellman is not secure against man-in-the-middle attacks is textbook knowledge, but how much harm could an attacker do if he is only able to modify one or both primes in the Diffie-Hellman exchange and is only able to do passive listening on the rest of the conversation ?

I have a gut feeling that the attacker can probably sabotage the resulting encryption key so that passive listening will work, but I can really argue why the original parties wouldn't notice the intrusion.

Any pointers ?

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

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

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

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

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

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

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


Penetration testing job entry exam What type of hands on tests should I expect in a interview for a entry level penetration tester?

And what do examiners expect a candidate to accomplish (i.e. full compromise)?

The reason I ask is that I went for a pen test interview and I was given a 4 hour exam. I was not presented with any guidelines or expectations. The test consisted of looking at ip-pbx log files for the given scenario:

  We have been approached by a customer who has been advised by their
  telecoms provider that a large amount of phone fraud (for clarity,
  this is where the phone line has been used to generate large call
  costs to the client such as premium rate or international calls) has
  been conducted on their company phone line.

  The phone system utilises a Shoretel Voice over IP (VoIP) gateway.
  From internal investigation by the client, it would appear that the
  fraud was conducted between the 30th December 2011 to 6th January
  2012.

  Our task is to conduct a technical review of the logs supplied by the
  client with an aim to:

Identify how this fraud was conducted.
Identify the source of the fraud (external or internal).

  You will have until 13:00 to submit your report which should contain
  an executive summary of your findings and a technical section
  outlining your finding at a technical level.

You can find the log files here.

I did not have a clue what to do, at least not with pbx and these types of log files.

Is this type of exam common for entry level pen testing positions?

I thought the log analysis for this given scenario was more geared towards forensics and incident response (which wasn’t outlined in the job advertisement) am I wrong?

When it was sent suddenly my career aspirations quickly fizzled into a cold chill, my immediate thought was, O NO... NOT LOG FILES! I can’t imagine anything more soul destroying than this.

If the answer to the question seems subjective then at least this may help serve other graduates in their quest.

I don't like answering these questions because as Poly said they're almost impossible to answer, but this is too long to fit in a comment.

This IS common for a non-specialist IT-Security-related job (as you said, it's graduate-level). You're not a specialist with 10 years of experience.

Don't worry about this, at this stage of your career you'll do almost everything. I'm almost sure that 9 out of 10 IT guys will tell you that in the beginning they worked in many different areas until their career settled and took a clear path.

My advice to you is this: You're a graduate, don't over obsess about final career at this point. Keep it your mind, think of it as a goal, but don't become obsessed. Focus on getting into the working life, gain as much experience as you can, and later you'll have the chance to be picky.

Best of luck.


Will the sever send a 'Server Hello' if ciphers are not negotiated? I know in Server Hello message, the server chooses the strongest cipher that both the client and server support. If there are no cipher suites that both parties support, the session is ended with a handshake failure alert.

If the ciphers are not supported, will the server still send Server hello message and then there is a handshake failure alert or no Server Hello message is sent by the server.

Thanks in Advance!!

The server will respond with a handshake failure alert and will not send a Server Hello message.

This is clearly spelled out in the TLS 1.2 RFC


What action plan a hacker can do to enter an iPhone I am interested by mobile protection for general public, we have all information saved on our phone. I am thinking what action plan a hacker can do with Kali or other to enter an iPhone and read SMS, for example. I found several methods but I don't think there is a method which works:

The first is to steal an iCloud backup stored on a computer and brute force the password. After that, the hacker can read all data stored in the backup.
There is also an exploit iOS MobileSafari LibTIFF Buffer Overflow but it had been patched there is a long time ago...
The last solution I think is to hook web browser with BeeF. I don't know very well BeeF so I don't know what is it possible to do when Safari for iOS is hooked.

I'm not against explaining Hijacking techniques for educational purpose. But please, keep in mind that gaining access to device that you do not own without it's owner permission is strictly illegal

That being said, gaining a remote access to an up to date IOS device (without any physical access to it) is a hard task, even for an infosec guy. It's not something you can achieve by watching some Youtube videos explaining how to use Kali tools.

(Beside this, asking tips on accessing apple device 100% remotely on a public forum is bad.)

But since you're supposed to do this for shaping your information security knowledge, i will assume you own an iOS device and have a physical access to it.
The procedure include 4 steps, you will need to perform your own research, from my point of view it's the best way to learn.

So here we go.

1. Fetching the PIN.
Black boxes and the goliath tool might help.

2. Maintaining the access (Remotly).
You want to access the device from anywhere. Installing a VNC server on your iOS device will be the easiest way, Netcat should be ok as well.

3. Remain Stealthy
Here comes the hard part: not getting caught nor raising alert. Stealthy pushing & installing a handcrafted app that hide your presence would be my way of doing it.

4. Being contagious
Very hard but possible: Stealthy delete the iCloud backup and replace them with the corrupted version you just crafted with the 3 steps above. It should give you access to new iOS devices, if the OS is installed from the corrupted backup (your handcrafted app have a big role in this point).


How was I able to login Whatsapp Web when my Phone was turned off and SIM card removed? I don't have my phone at the moment, since I turned it over yesterday at the shop for a screen replacement.
The SIM card is removed and it's sitting in my wallet now.
When I opened WhatsApp Web a couple minutes earlier today, I was connected to my account and could send and read new messages. This connection continued for around 15 minutes or so, until it stopped receiving signal from the phone.
My question is, how was WhatsApp Web able to receive signal in the first place?

You say WhatsApp web lost signal with the phone, which suggests it still requires the phone to mirror its connection.  Might the repair shop have connected the phone to WiFi?  If the phone is configured to automatically connect to open WiFi, it could connect without setup on the store's part.  I know WhatsApp does not require your SIM card to work, as you can temporarily migrate WhatsApp when traveling and using a new SIM card.
Edit: ran a test where I removed my phones SIM card and connected with WhatsApp web on another device.  I was able to send/receive messages.
Edit2: the phone must be unlocked to allow the WhatsApp connection.  WhatsApp does not need to be running actively (there is a background process on startup).
At a minimum, your phone was unlocked and connected to (open?) WiFi.  It cannot be proven the store was going through your WhatsApp messages, but it is possible they did.


Authentication, authorization in native mobile clients (Android) I am developing native mobile client for store that requires user authentication in order to make purchases available.
I have my web store page, authentication is provided by CMS (OpenCart).
Now I need to implement secure and robust login on mobile devices.
I am using REST API for getting data public data from web site (products, sales ....).
But what is the best choice if I need to provide secure connection between native mobile client and my web server.
I am using "native" to notice that there is no web view or something similar in the app.

There a lot of similar app from popular online stores ( Ali,Ebay, Amazon) all these app use authorization without browser built in mechanisms, I wonder how do they implement this.

What are possible ways to secure user important actions in native client.

Of course I have read a lot of about this, but there no one good solution as well as any article describes available approaches.

Please suggest what is the secure, robust and not very difficult way to do this.

I am grateful for any help in advance.

Without understanding more of your app, there are many correct answers to this question.

One common strategy is to use username/password to authenticate to your API. On successful authentication your API will create and return an auth token. Your app will then pass the auth token on each subsequent call.

The typical format of an auth token is

username + other data + HMAC(user + data, secret known only to the server)

When your server receives the auth token on a subsequent call, it parses the username and the other data (whatever you may want to store), performs the HMAC, and then compares it with the HMAC in the token. If it matches then you have a valid login, otherwise you log the attempt and abort.

This strategy allows the server to be stateless as any important information can be stored in the auth token. If you need to maintain a session on the server, you could use an auth token of the format:

session ID + HMAC(session ID, secret known only to the server)

You probably want the session ID to be a secure random number and not a counter or memory pointer as you don't want the client to be able to guess other session IDs even though the client can't forge the token without the secret.


How can Flash detect my IP address even when I am behind a proxy? I'm new to cybersecurity, but I always knew some basic things, or at least I thought so, until I found out that the Flash app may actually get my real IP address even if I'm behind elite proxy. How does Flash find out the real IP? What is the technique for this and is it possible to secure myself from it without disabling Flash? How can I check if I am in fact vulnerable to this?

It's because flash doesn't actually care for your proxy preferences. You can change that in your flash player settings, but even then, flash applications can choose to try to connect directly and ignore your proxy settings. A proxy is nothing more than a "suggestion" to a program. It is up to the programs to actually follow those settings, or ignore them. A webbrowser doing HTTP by itself will probably honor your proxy settings, but technologies outside, or "next to" the browser (like plugins and WebRTC) may simply do whatever it wants.


How bad is the leaking of Internal IP addresses through external DNS If an external DNS server is leaking internal IP addresses are there any significant security threats associated with this information leakage?

Apart from most the obvious - gaining an understanding of the internal IP ranges in use.

Cisco.com for example: http://www.dnsdumpster.com/report.php?domain=cisco.com

There is probably no great harm from revealing internal IP addresses inside the firewall.  While there are some risks, they seem fairly modest to me.

Here are the risks I can see:

Information gathering. It reveals something about the internal IP ranges in use.  If an attacker were to breach some internal system, this information might make an attacker's life somewhat easier, by suggesting some other internal systems that the attacker could go after.  It might also reveal a little bit about organizational structure.
CSRF attacks. It might also make CSRF attacks slightly easier.  In a CSRF attack, a user inside the firewall visits a malicious website, and the malicious website sends back to the user's browser a HTML document that causes the user's browser to connect to another machine.  If the malicious website knows the address of another internal machine, it can try to trigger a connection to that internal machine and attack it (subverting the organization's firewall).  However, these attacks can also happen even without knowledge of other internal machines (e.g., Javascript can be used to portscan internal machines), so while knowledge of an internal machine's address may increase the risk somewhat, it is not essential to an attacker.

Based on this, I wouldn't stress out too much about trying to prevent internal IP addresses from leaking.  There will probably be other security activities that are a better use of your time and should be a higher priority.


secure notebook options How can I secure my notebook with highly sensitive information stored in a spreadsheet.

I am keeping the following options in mind:

Password protect & encrypt BIOS
Full disk encryption
Password protect the spreadsheet

Is it possible to do 2fa for windows signon?
What about remote tracking & wiping?

Which other options are there to explore?

Bearing in mind there is still an end-user that needs to use this notebook.

This is not a full answer but I want to highlight an aspect you did not mention. Apart from physical security (temper prevention and detection?) and encryption you have to be very careful what you are doing.

That means that no process having direct internet connection (web surfing, chat, skype...) or which has indirect connection (mail) should be able to access any sensitive data. The best would probably to have no internet connection at all. Another option would be to only access the internet through a companies VPN where you hopefully get the needed protection.

Unfortunately you often need direct internet access to at least establish a WLAN connection (because of capture portals) which you can use with your VPN. So one option would be to have a virtual machine and only do any connection from inside this machine.


I only use windows for games. Do I need anti virus protection? I use Linux, and even though I'm not pretending my system is virus-free, it's generally accepted that even an aggressive firewall is not a requirement.

I want to install Windows 7 on a machine which I will use strictly for playing games. Browsing on it may even be discarded, if necessary.

So, for the two to three hours a week I'll be using the OS - making it effectively a console - do I really need anti virus software, or can I do without the annoyance of advertisements, scans etc.?

When you are going to play games you downloaded from the internet, you should definitely get a virus scanner. This is especially a concern when you download pirated copies, because these are bundled with malware from time to time. But even when you stick to legal downloads there is a certain risk involved. There were cases of renowned download portals getting compromised and spreading malware attached to their files.

Note that downloading the games under Linux will not protect you. When you download a Windows-executable infested with Windows-malware, Linux will not care. When you then execute the file you downloaded with Linux on Windows, your Windows system will get infected.

Maybe you think "What do I care? I don't have any important files on my Windows partition, so when I catch a virus, I will just reinstall". Keep in mind that your Linux volumes aren't safe from malware. Just because Windows can't read their filesystem doesn't mean ransomware can't delete them with direct hardware access.


How secure is Windows Auto-Logon? Obviously, if auto-logon is enabled, anyone who can gain physical access to the PC can use the PC. That's not the question.

The question is, when I enable auto-logon for my Windows 7 box, will there be any additional security problems?

Does the setting "Users must enter a user name and password to use this computer." affect anything else? Where/how is the password stored for auto-login?

Note: This is specifically for Windows 7, as I found this little gem regarding XP:

  Additionally, if you turn on automatic logon, the password is stored
  in the registry in plain text. The specific registry key that stores
  this value is remotely readable by the Authenticated Users group.

Disclaimer: This is for my home desktop PC. Not a laptop. Not work related.

Auto login works by storing the credentials in the registry in plain text. Once the winlogon.exe process has finished loading it checks for those particular registry values. If they exist, Windows logs on with those credentials. It's as if a user typed the same credentials in themselves.

It's usually designed to be used in a kiosk style mode, with user accounts that have limited access to the network or local machine.

Is it secure? No. Your user password is stored in plain text in the registry. This was designed for kiosk-style systems for accounts with limited access.


Modsecurity create config file with rules for specific URL I'm starting to learn about ModSecurity and rule creation so say I know a page in an web app is vulnerable to cross site scripting.

The rule in question would look something like this:

SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404

Is it possible to create a config file for that particular page (or even wise to do so?) or better said is it possible to create rules for particular URL's?

Yes it is possible to do so. In mod-security they are having action called chain action like for example,

SecRule REQUEST_URI "/bank/login.aspx" phase:2,chain,t:none,id:105
SecRule &REQUEST_HEADERS:Content-Length "@eq 0" t:none

So you can change your rule accordingly. And google is your best companion for more info.


Server-side man-in-the-middle/eavesdropping: attacks between two servers using unencrypted HTTP I’m new to security, and I’m wondering how man-in-the-middle and eavesdropping attacks between web servers work, rather than between personal devices and servers.

Most questions I see here about man-in-the-middle attacks seem to involve a personal Web browser communicating with a server over an insecure Internet connection. If they’re using unencrypted HTTP over something like public wi-fi, then it’s really easy to intercept and read their communications from packets that they broadcast on the same network, as Firesheep shows.

But how would an attacker perform an attack on the connection between two public Internet servers communicating over unencrypted HTTP?

I know that if HTTP messages aren’t encrypted, man-in-the-middle and eavesdropping attacks can occur. But I’m wondering about actual risk, feasibility, and practicality of such an attack.

Let’s say that there are two servers, A and B.
Server A is a VPS or something, from Rackspace or Linode, under your control.
Server B is another organization’s public web server that is not under your control.
Server B does not support HTTPS; it requires HTTP and session cookies.
Server A needs to intermittently connect to server B on server B’s website: logging in, doing things, logging out.
Server A’s IP address might or might not be public—it’s exposed to server B, in any case. Server B’s IP address is public.

How would an attacker eavesdrop or intercept this connection if they had the resources of an individual? It’s not like the VPS uses a public local network to which individuals could connect.

The big thing I can think of is that an attacker might launch a DNS-spoofing attack against the DNS servers of the VPS company that hosts server A. So you’d have to trust that the VPS company’s DNS servers won’t get compromised, right? Is this required trust recursive to servers outside the organization, all the way to the root server? What kind of resources would an attacker need to attack these servers?

Are there any other methods that a man-in-the-middle or eavesdropping attack might occur between these two servers? What resources would those also require?

There are some other questions about man-in-the-middle attack techniques other than wi-fi interception—although they are broader than this question, which is specifically about unencrypted HTTP between two hosted servers. These other questions include:

“Who can carry out MiTM attacks”
“MiTM attacks: how likely are they”
“Who other than my ISP can perform MiTM attacks”

Something I've seen before, and is talked about in a DefCon talk, is people will setup a proxy on something like your VPS in the example and capture the traffic between the user and the server that's going through the proxy. They could also choose to inject JavaScript or return false data to you if they so desired.

For an attacker to sniff all of the traffic going to a web server, they would need to have remote access to it, or the network it's on for the very least. They'd also need to be able to transfer the collected data to themselves. I've heard of hackers commonly using VPSs to hide their identity whenever they've cracked into a web server and attempting to perform such attacks. This might be where you've got this from.

As for the resources that would be required; A packet sniffer such as wireshark would work. Also an exploit for a vulnerability on the web server would be needed as well.


Can my VPN provider see my browsing activities on SSL sites? I gather they can probably see everything if they want to on non-SSL sites but how about on SSL sites, can they do it?

No, they can't, assuming you trust the certificate on the site.

However, your VPN provider can still monitor metadata that is not encrypted, such as DNS requests and IP addresses of hosts you communicate with. They could at least reveal on what domains you have possibly visited.


Someone logged in server through ssh using my RSA key I just got the warning message from hosting provider that my server make outcoming traffic 1.5G to provide DDOS attack on someone host, and they disabled my VPS temporarily.

When I search through auth.log I saw someone logged in with private key, and the only one key on the server is mine. I can't believe someone could stole private key from my computer. Can the hacker somehow logged in without the private key?

I suspect your key are affected by the issue of weak keys, that was generated using the process ID as seed:
https://github.com/g0tmi1k/debian-ssh

Note that this are only dependent on which machine you generated your keys on, NOT the SSH'ed machine.

There is then a possibility that the attacker predicted your key.
Thats why I suggest regenerating the keys, using a debian version where this issue has been fixed, and then replacing the keys in your VPS.


PC Component Firmware integrity and security I recently bought a new laptop.

If you read the news you must've noticed Vault 6 and Vault 7 leaks (from Wikileaks), which contain rootkits which sit on your Hard Drive Firmware, MBR and other hidden partitions. Since it's out in the open not only state actors should be able to make such kind of hard to get rid of malware.

How do I check the integrity (checksums or similar) and secure the firmware on my hardware components (Hard Drive, Motherboard, SSD, USB Hub etc etc)?

Verifying the absence of something is much harder than verifying the presence of something.

This statement holds true in many things, information security included.

About your threat model...

One central aspect of information security is your threat model, aka. "What are you trying to defend yourself from?" Since you specifically mentioned Vault 6 and Vault 7, I am going to assume that your threat model is a Three-Letter-Agency (or MI\d, if you fancy so).

With such a threat, you again have to make a choice. Do you think you are personally being targeted, or do you worry about mass surveillance?

I worry about mass surveillance

In the eyes of the TLA's, you're a nobody. You're John Smith, completely unremarkable. You may assume that institutions like the NSA, CIA or
ţ͟͡͝h̵̛͢͡é̕ ̷̷̕͡O̴̶n̷e͜͡ ̧̨̛͟w̡h͟͟͠͞o̵̷̵͘͟ ̵̵͢͟͞W̵̛a̷҉̨t̵͢ć̷̴̶͢h̢̛͢͟e̵̴̛͢͟s̡̛͜͡  have infinite budgets to insert custom hardware into every single laptop being sold, but such a thing would not really be feasible from their perspective.

Why so? Because contrary to popular belief, these agencies don't particularly care who you voted for, what YouTube videos you watch or if you download pirated music. These agencies care about threats to their nations, or about information that could further their nation's interest.

Unless you fall into one of those targets, all the information these agencies collect about you is information they can easily gather and process.

This likely includes whom you talk to, what websites you go to, and a bunch of things more that none of us is aware. Why so? Because these kinds of information can easily be gathered at a single point: A TelCo company, an ISP, etc.

No need to put a chip in every single smartphone sold, if all you had to do was putting some machines into Room 641A. Much cheaper, much more effective.

Furthermore, imagine if a TLA had a keylogger installed in every single computer ever sold. The amount of data the TLA would have to process is so immense, that any meaningful and relevant information there was to be gathered would immediately be lost in the immense noise generated by millions and millions of users typing away at their keyboard.

So as a result, I would not really be worried about it. Most of the web is moving to HTTPS-only anyways, so the widespread adoption of HTTPS in recent years has helped a lot.

I am personally targeted

Oh boy, the hand you have been dealt doesn't look good. I don't know why you are targeted - perhaps you are a journalist in a repressive regime - but if you personally are on the list of a Three-Letter-Agency, then things look really really bad.

First of all, a TLA is far more likely to invest a considerable amount of money into watching you than they are to watch John Smith from the last section. This means that you will have to act as if you were John Smith.

For instance, don't buy a laptop on Amazon and have it shipped to your home address. It could be intercepted, have some rootkit implanted and then have it shipped to you in 2+ business days.

Instead, buy a laptop in a large electronics store away from your home address. These stores get quite the amount of hardware, and inserting backdoors into every laptop sold within 100 km of your home residence is a task that asks for quite a considerable amount of financial investment - and even then it's not certain that you - their target - will even buy one of them.

The same goes for individual components, as far as they are user-interchangable. You can buy your own SSD, HDD, optical drive, etc. somewhere in the middle of nowhere. The chance that this specific piece of hardware is backdoored is rather unlikely.

Of course, this isn't the whole story. OpSec is a huge field and I am barely scratching the surface.

What about checking the firmware of hardware I already own?

Basically an impossible task. You would have to have the hardware to dump the firmware of your device, and then have the means to analyze every single instruction in this firmware. Furthermore, you would have to check the schematics of the hardware, and then analyze every chip on the hardware to ensure that there isn't some hidden logic in one of them.

The reason why it's not so simple as just checking the hashsum of the firmware is because you have nothing to compare it to. You can check if the firmware you dumped is the same as the firmware offered for download by the vendor - but how do you know that that firmware also isn't backdoored?

Even if you had the source code, how can you be sure that the compiler used to compile that source code didn't insert a backdoor? How can you be sure that the disassembler you used to view it didn't silently remove the backdoor? How can you be sure that the text editor you used to look at the source code didn't silently hide the backdoor?

It may sound like tinfoil hat talk, but we're talking about targeted attacks by a Three-Letter-Agency. Tinfoil hats are the only appropriate headgear to wear.


Regenerating dhparam periodically Does it increase connection security if I regenerate the dhparam files used with NGINX on our servers periodically e.g. every week?

What issues may arise from this?

Is there any benefit in doing this?

Does it increase connection security if I regenerate the dhparam files
  used with NGINX on our servers periodically e.g. every week?

No, not significantly.
DH parameters are really just a large prime that takes a lot of time to be generated (because it needs to be a safe prime). Additionally there's a so-called "generator", but this one is cheap to generate.
Right now it is impossible to break a DH connection negotiated with a 2048-bit or longer safe prime. Thus if you regenerate your safe prime every week you gain no extra security beyong "unbreakable". However this should not be confused with generating your own proper (strong) parameters once. This is to make an internet-scale Logjam attack much more difficult, but as I already said is optional as the parameters can't be broken anyways.

  What issues may arise from this?

More computational load. Generating the parameters is probably one of the most intense cryptographic computations you will encounter.

  Is there any benefit in doing this?

You gain something like "super-forward-secrecy". With ephemeral Diffie-Hellman, the attacker needs to break each connection individually to recover plaintexts. The per-connection load can be reduced when applying the Logjam trick of doing one giant pre-computation for the parameters and only doing the last step for each connection. If you change your parameters regularly you limit the impact a Logjam-style attack could have. However, running the algorithm required for Logjam is infeasible for DH parameters that use long primes (e.g. 2048-bit or more) .


DAB+ (Digital audio broadcasting) privacy Soon FM radio will be switched-off in Europe. I wish to buy a DAB+ device and read in Wikipedia about it.

I really don't understand what consumer privacy DAB+ offers me. Does the radio channel know that I am listening at 20:00 the program XY? Does it depend on the device I will buy? What's a good choice if I wish best privacy in radio?

DAB+ is a one-way signal transmission. A big, high-powered sender sends data encoded according to the standard, and the small, low-powered receiver receives the data, decodes it and plays the audio stream back.

Does that mean my radio is 100% private?

Most likely, yes. The DAB+ standard describes no signal sent from the radio and received by the base station.

This does not mean that there could not be a "smart radio" that transmits somewhere what you are listening to. It just means that it's not part of the standard.

So if you wish to remain as private as possible with your choice of radio station, don't buy a "smart" radio.


Can a custom return path make SPF redundant My understanding is that SPF can be used to define a set of IP addresses that are permitted to send outbound emails on behalf of a domain. If a mail server that is not included in the set of permitted IP addresses sends an email, the receiving server could perform the TXT record lookup on the from domain and inspect the record to help determine whether it should soft fail or hard fail an inbound email.

E.g.

dig my-site.com TXT
"v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

I thought that this record was basically saying "allow any servers indicated by the TXT record found at spf.google.com or servers.mcsv.net and fail anything else.

Then I came across this: https://www.intercom.com/help/configure-intercom-for-your-product-or-site/configure-intercom-for-your-team/a-guide-to-sending-email-from-your-own-address

  Do I need SPF? No, Intercom handles that for you. Emails sent from Intercom include a return-path header. When a recipient mail server receives one of our emails and checks the SPF record of the domain in our return-path, they will see that our sending IP addresses are authorized senders. This means emails sent through Intercom will pass authentication automatically and you don't need to set up any records yourself.

This confuses me. Doesn't this mean that intercom in this case (also anyone on the internet using the same technique) can send an email that appears to come from my-site.com despite the fact that I have used an SPF record which is supposed to fail anything that isn't in my set of white-listed IP addresses? Wouldn't the person receiving the email see this as being "from" me@my-site.com AND as an SPF pass, even though the sending server's IP address may not have been one of my authorized IP addresses?

Note, I do use DKIM and DMARC as well - but I want to isolate this discussion to just the SPF side of things.

When we're talking about "From" in regards to email, it can refer to two things:

The "From: " header
The "Envelope From" that is exchanged between email servers directly when establishing a connection.
They don't have to be the same.

When your client connects to the server to send email, here's a simplified exchange between them:

client: HELO client.example.com
server: Hello, client.example.com, nice to meet you
client: MAIL FROM: <bjones@example.com>
server: Okay
client: RCPT TO: <csmith@example.com>
server: Okay, go ahead with the message, terminate with a single '.'
client:
From: Junie B. Jones <bjones@example.com>
Subject: Important discussion

Hello, Claire...
...blah...
...blah...
.
server: Okay, accepted for delivery

You'll see above that the "From" showed up twice: first time as part of MAIL FROM, and the second time as From: in the body of the message. Only the first one (called "Envelope From" or "Return Path") is important as far as mail servers are concerned -- the second one is mostly for looks. In fact, it can be missing entirely.

What Intercom is saying is that when they send a message, they will send it like this:

client: HELO foo.intercom.com
server: Hello, foo.intercom.com, nice to meet you
client: MAIL FROM: <someaddr@intercom.com> # <-- envelope-from
server: OK
client: RCPT TO: <somedestination@example.com>
server: OK, proceed, terminate with a single "."
client:
From: Junie B. Jones <bjones@example.com> # <-- cosmetic "From:"
Subject: Mailing from intercom

...blah...
...blah...
.
server: OK, accepted for delivery

Many mail clients will show this as "Junie B. Jones <bjones@example.com> via foo.intercom.com" when displaying the email, to indicate the discrepancy between the Envelope-From and the cosmetic From, but it's considered a kosher practice when it comes to email.

SPF specifically only deals with Envelope-From, and ignores the cosmetic "From:" field:

http://www.openspf.org/FAQ/Envelope_from_scope


How robust is a VeraCrypt Container against disk errors (bit rot)? I am planning to encrypt backup data using VeraCrypt. How safe are the generated containers? My worries is not so much the encryption, but potential data loss due to degrading harddisk media (bit rot) over time.

Currently I have an external USB Harddisk, and store each set of backup data twice, in separate folders, A and B. I do a bitwise comparison between A and B from time to time to proove the data integrity.

I plan to encrypt those backup data folders A and B into separate containers. Here are my questions:

Will the created containers still be bitwise comparable?
How robust will the containers be against data loss, e.g. when a (different) sector in each container fails, will the rest of the data still be
extractable?
Can I purposedly have some extra redundancy in the container?
(I know that this may degrade the encryption somewhat, but as said
this is not may main concern).

Note: I like to have separate containers against having the whole drive encrypted to be able to handle the backup data sets individually.

Will the created containers still be bitwise comparable?

No. Veracrypt stores different containers with different encryption keys, even if you use the same password. So the containers won't be bitwise identical. You'll need to open the container and compare the files rather than compare the container.

  How robust will the containers be against data loss, e.g. when a (different) sector in each container fails, will the rest of the data still be extractable?

Veracrypt stores two copies of the volume metadata, one at the front, and one at the end of the volume. Additionally, you can backup the volume header to make it possible to restore the volume if both embedded metadata is corrupted.

Veracrypt encrypts in XTS mode, which means that data corruption in one block only affects that block.

However, you should consider that modern hard disk are very good at detecting and self correcting for errors. They do this by encoding the data in such a way that there are redundant information to allow the hard disk to recompute corrupted bits, the general technique is called error correcting code.

In addition, if you use a modern filesystem in your host system, like btrfs or zfs, modern filesystem adds additional checksums to automatically detect errors and they can also be configured on RAID configuration so they can automatically make redundant copy when storing files so they can automatically repair errors to protect against media degradation. Due to their design, it's nearly impossible that you'll get silent corrupted data due to media degradation with modern filesystem.

The only practical failure scenario for modern filesystem is bugs in the filesystem implementation and user errors. You have a much better likelihood of accidentally rm -f container.tc-ing your data. And for a catastrophic physical disk failure where the entire hard disk just stopped working, in which a backup on the same device would not be able to help you. To protect against these, you would want to make a backup copy of your data on multiple devices and migrate to a new storage media probably once every 5-7 years.


Why superuser or administrator account should never locked? Why should administrator or superuser account never locked regardless how many incorrect login attempts are made?

What should be done instead to alert the staff to the attempted instrusion?

Most of the time it does get blocked. Not in the sense of blocking off the account, but blocking the IP that tried to connect.

I use OSSEC. If someone tries to log in on ANY account wrongly more than 5 times, the connecting IP will be blocked and I will get an email containing what IP tried to log in.

To prevent from locking yourself out you can whitelist some IP's that will never get blocked.


Multipurpose security token a security vulnerability? Our application has the concept of security tokens. These are cryptographically secure randomly generated strings used when generating password reset emails, as well as email confirmations for other actions. Tokens are single use and expire after a day. The tokens provide two key pieces of information. They identify a specific account, as well as prove that the person holding the token is the owner of that account.

Currently our application does not assign a specific use for each token, a token generated for resetting a password can be used to confirm another action, and vice versa.

Assuming the token is kept secure, what, if any, potential security pitfalls could this have and should our security tokens be restricted to the purpose they were originally generated for (eg. only a password reset token can reset a password etc.)

The sort of problem I can foresee with this is that it's vulnerable to the following sort of attack:

Attacker causes your system to send a password reset email to the user.  Such an email contains a valid security token plus some context, for example:

Telling the user what this is about;
Instructions for the user how to complete with the action;
URLs for the user to click on to complete the action.

Attacker intercepts this email and adulterates it to keep the security token, but alters the context to their advantage.
User receives the forged email, acts on the adulterated context, and thus unwittingly carries out some action that the attacker intended them to do.

Whether this is a realistic or fruitful attack very much depends on the details of your system.  In any case, binding the tokens to the actions that they're supposed to perform removes this sort of risk.


Access point fingerprinting Does someone know of a project or a way to "fingerprint" an access point (a router)? Fingerprinting should be done irrespective of broadcastet BSSID and ESSID. BSSID and ESSIS may be included in the fingerprint, but they should not be the only indicators.

One interesting fingerprint you could use is the clock skew. Since 802.11 APs typically broadcast their timestamp in beacon frames, the beacon frames provide a nice source of the devices clock skew. For more details, see "On Fast and Accurate Detection of Unauthorized Wireless Access Points Using Clock Skews".


How to determine if a google photos file transfer is really encrypted Inspecting packets during a file transfer with an iOS application such as Google Photos. How would one know from packet inspecting if uploading a file is done securely despite being on a public network?

So far I know that a handshake occurs using the TLS protocol after that most of the data is delivered through TCP on port 443 and some Application Data through TLS. Is this normal behavior for an encrypted connection?

Furthermore, I know the data sent is mostly gibberish, but how can one be sure that all the packets are sent using a secure connection? I mean could you not send the data unencrypted on port 443 and having the data just being displayed as compressed data?

Does anyone know more about Google Photos and their encryption practices for downloading and uploading data with both photos and video? I just want to know if it is safe to use Google Photos on a public network.

Could one conclude that it is likely safe to use Google Photos, even on a public wifi? If you consider that to be the case please state why, if not please also give your opinion.

To be certain that the data is sent encrypted, you could decrypt it.

This requires you to either have access to the decryption keys, or to install a certificate and perform a Man-In-The-Middle (MITM) attack on your own device.

Let's assume that you have full control of the device from which the pictures are sent.

The first approach is to inspect the encryption keys while they're being used. This is not as easy as it sounds, encryption software is written to destroy keys as soon as possible. (There's probably some software for this type of inspection, but I don't have experience with this approach, so I can't say how effective it will be.)
The second approach is to use a packet sniffer, and allow it to install a certificate. WireShark has an option for this.
What happens is that the client performs a key exchange with the packet sniffer, and the packet sniffer performs a key exchange with the server. The packet sniffer sits between the client and the server (hence the name "man in the middle" attack). It decrypts what the client sends, then encrypts it again for use with the server.
Note that this is only possible because you installed a certificate and told your computer to trust it. You have effectively lowered your security a bit.


Installing SSL on load balancer and the internal IP I have a server which has an internal IP (Used to access from local) and an external IP (accessed from Internet and placed in the load balancer). And both will use the same URL https://www.abcdXX.XX.com.

I have a common SSL certificate here.

Should I bind the same certificate to both the IPs in the port 443? in the server.
Should I create different certificates and bind them?

If both IPs are answering to the same name, then go ahead and use the same certificate on both.  It doesn't gain you anything to get a second certificate with the same name on it.  There are no security weaknesses introduced by using the same certificate on two IPs on the same server.

The only possible difference is if you ended up needing to revoke and replace one certificate you'll end up revoking/replacing both, but if one cert on your server got compromised, any other certs on that same server are probably suspect too.

Upon re-read, it looks like you're talking about the cert on two separate systems - the load balancer will terminate SSL and pass HTTP back to the actual server?  And the server will have the cert itself to terminate internal connections?

My answer doesn't really change.  The threat environment isn't worsened all that much by you pasting the key into the load balancer over (usually) secure HTTPS, and if the effluent hits the aerator on either system, you don't gain much security or convenience by using different certs.


How does binary code execution vulnerability work on a modern OS? In a modern OS I think that:

the .text section where binary assembled CPU instructions are stored cannot be modified
the .data/.bss section is marked as no-execute so that the information there will only be treated as data, will never be executed by the CPU

So how is it possible for an exploit containing a payload of binary assembled instructions to get execution?

The execution of the Binary Assembled instructions works by exploiting the vulnerability in the Application Program.For example inserting malicious code into a PDF,if there is a flaw in the PDF Software the Code from the Data Section can be executed.

Now coming to your question.As far as i know after 8086,Intel  started employing 4 levels of protection.The inner level is for Kernel Level processes and the outermost level is for User Level Processes.There are separate stacks for both the processes but the Memory space is shared.
A user level process(caller) cannot directly perform a privileged task,it needs to call a trusted code that does the work for the caller.But for the user level process to call the trusted code say  to write a data item X,it should have the permission to do so(indirectly).

There are some exploits commonly called as Trojan Horses that allow the User Level process to use a Trusted Code to do stuff it is actually not allowed to do.

So if the Application program itself has vulnerabilities,combining that with such exploits can get the desired code in execution.


Does DSA need padding? So I read on wikipedia that digital signatures need padding (like PSS) and I know this is true for RSA.
But now I ask myself does DSA also need padding?

The short answer is no or yes, depending on how you look at it.

With RSA, as specified in PKCS#1, the message to sign is first hashed, and the hash value is "converted" into an integer modulo n (where n is the modulus, a part of the RSA key pair). In the old versions of the standard, that conversion is indeed a kind of padding (extra bytes are concatenated to the hash value, and the result is interpreted as an integer modulo n with big-endian convention). The newer padding, named "PSS", is a bit more complex and implies more work than mere concatenation, but we still call it "padding", mostly out of tradition.

Details of the padding turned out to be very important to the security of RSA as a signature scheme (the modular exponentiation of RSA is malleable, which is a problem for signatures, and the padding fixes that).

In DSA, as specified in FIPS 186-3, the input message is also hashed, and the hash value is also converted into a modular integer (modulo q, the size of the subgroup used by the key). This calls for a conversion of "some bytes" to "an integer", which could be called "padding", too (it is no more preposterous than calling PSS a type of "padding"). It so happens that DSA has much fewer requirements for this conversion, so it is defined with a rather simple conversion process: the hash value is truncated or expanded to the length of q (in bits), by adding zeros (on the "left"); then the resulting sequence of bytes is converted to an integer (big-endian convention again), and reduced modulo q (since the sequence was made to match the length of q, this reduction is computationally easy).

So we can say that there is some padding in DSA, but a simple padding with only zeros.


While importing certificates in keystore, do we treat these like CA root certificates? When we need to call an internal domain via HTTPS, Java doesn't allow it because it doesn't recognize the certificate that those domain web servers are sending (probably because those certificates are self-signed given that these domains are internal to the organization).

In that case, we're asked to import those certificates. But isn't the cacert location only there for storing root certificates and not self-signed certificates? I mean, the general procedure is that the certificate issuer's CA certificate is located in cacert and then the signature is verified using this certificate issuer's public key. Is the process changed when a self-signed certificate is received?

Or do I have to become my own Certification Authority which would probably require generating a new key pair, then sign the self-signed certificate with my private key, create a CA certificate containing my public key, and then install this certificate in cacerts?

I think you are slightly confused. Self-signed cert CAN be a root cert. When you are calling your internal domain via HTTPS, in order for TLS handshake to succeed (and, consequently, for communication to proceed over HTTPS) your local service needs to trust the server's CA. For that reason you import that CA into your trust store, thereby trusting the ID certs that the CA will sign. The ID cert is a certificate that the server will present during the TLS handshake.
Let me know if I need to clarify further. Getting confused by X509 is the easiest thing to do:)


What are the implications of running a Tor non-exit relay node? Intuitively, running a non-exit Tor node should bring the benefit of plausible deniability that a packet originated from your device.

Unlike exit nodes however, you would not have to worry about illegal content requested in the clear by your computer.

So it seems that running a non-exit node would have only benefits (not considering the increased traffic caused by this; assuming Tor does not have any exploitable security vulnerabilities in the relay code to compromise the relaying computer).

Does operating a non-exit relay node have any security-wise or legal issues I am not aware of?

Traffic analysis can defeat your plausible deniability. When you relay traffic, there is a packet in for every packet out, but if you're an endpoint the traffic patterns look different - even though they can't see the packet contents.

I think it's very unlikely you'd get any comeback from being a non-exit relay. You may unknowingly forward illegal traffic, so there is a theoretic risk of some legal sanction depending on your local laws, but it wouldn't worry me. It's not traceable to you, and you are not able to decrypt the traffic, so there's nothing you could do to filter it.

Ultimately the risk are minor, but the benefits are minor too. I think most relays are motivated by supporting the tor project. It's a different story for exit nodes where many are motivated by wanting to sniff the exit traffic, and are willing to accept legals risks around this.


How can I track IPs to block malicious users? TL;DR: I want to know should I store both REMOTE-ADDRESS and X-FORWARDED-FOR or either REMOTE-ADDRESS or X-FORWARDED-FOR?

Details...

Here is a few theories to get user's IP

Theory1: If you don't use a load balancer, use REMOTE_ADDR. If you use a load balancer, use whatever it uses. In 99% of cases that appears to be HTTP_X_FORWARDED_FOR. So:

function get_ip_address(){
    $id = '';
    if (isset($_SERVER['REMOTE_ADDR']))
        $ip = $_SERVER['REMOTE_ADDR'];
    else if (isset($_SERVER['HTTP_X_FORWARDED_FOR']))
        $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
    else
        $ip = 'UNKNOWN';
    return $ip;
}

Theory2: There is some other HTTP header information (ie. $_SERVER['HTTP_...]) which might be containing the IP. So:

function get_ip_address(){
    foreach (array('HTTP_CLIENT_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR') as $key){
        if (array_key_exists($key, $_SERVER) === true){
            foreach (explode(',', $_SERVER[$key]) as $ip){
                $ip = trim($ip); // just to be safe
                if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) !== false){
                    return $ip;
                }
            }
        }
    }
}

Theory3: Storing both one of $_SERVER['HTTP_...] and $_SERVER['REMOTE_ADDR']. So there is two variables:

function get_ip_address(){
    foreach (array('HTTP_CLIENT_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED') as $key){
        if (array_key_exists($key, $_SERVER) === true){
            foreach (explode(',', $_SERVER[$key]) as $ip2){
                $ip2 = trim($ip2); // just to be safe
                if (filter_var($ip2, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) !== false){
                    $ip1 = $_SERVER['REMOTE_ADDR'];
                    return array($ip2, ip1);
                }
            }
        }
    }
}

Well honestly I'm confused a little bit. How many column (in the database) do I need to store the user's IP? I mean should I store both REMOTE_ADDR and a HTTP_...? Or just one of them?

Actually I have a query which inserts the user's IP per each page loading in the database. So that query will be executed every time before loading of the page. Surely an INSERT query (everytime for each request, and each user) has a cost. So I don't want it be useless. I mean I want to store a correct/real IP  or at least I want to do the best work which is possible to detect the user's IP * .

* When an user uses a proxy like HSS then detecting him would be impossible. That's why I said "at least".

Ok well, which theory is the best?

You need to know which proxy servers you trust, and which headers to trust (if any) for each of them.

For example, you know your load balancer uses X-FORWARDED-FOR so you can trust the rightmost value that is supplied to your web server in this header.

Your load balancer will also need to know which IPs to trust. For example, it may trust RFC 1918 private IPs. You may also want it to trust certain public IPs if, well... if you trust them.

When trusting them, you would probably want to remove them from the chain of IPs that are candidates for storage.

As soon as you hit the first untrusted IP in the chain, then you should store that as the remote IP for the connection. The reason is because anyone can set X-FORWARDED-FOR within their HTTP request. If this REMOTE_ADDR is not in your trusted list for X-FORWARDED-FOR then you have no reason to trust the header.

This may be complicated if you are trusting arbitrary internet servers with different trusted headers for each.

The above is a generic approach for finding the actual connection that is requesting your page. However, if you are trying to track malicious users you may just want to gather any IP in any header as well as REMOTE_ADDR and then store multiple IPs for each connection. Then if they start doing anything "bad" on your system, you can add a black mark against all of those IPs.

Once so many black marks have been awarded, your system could start blocking connections with that IP in either REMOTE_ADDR or an IP HTTP header. You need to be aware though that a malicious user may try to blacklist other IPs in a denial of service attack. Therefore you are back to my first description of only trusting certain hosts.

Of course, a determined malicious user will always switch hosts when they feel the need to attack your system. e.g. by Tor, by VPN services or via their botnet. It's a tricky thing to accomplish so you may wish to consider other methods of blocking malicious users - e.g. forcing them to sign up with an account before using your system which is verified by SMS. This adds a high enough barrier to block all but the most determined of malicious users.


Stream/block cipher add a simple hash to guarantee integrity The question is simple:

Adding a hash to a message and then encrypt it using a stream cipher / block cipher. Why can't this guarantee integrity of the message upon decryption?

Why it does not guarantee integrity is easier to see in the case of a stream cipher like RC4, where the encryption is a bit-by-bit XOR of the data with a key-dependent stream. Basically, the encryption of message m is: e = m XOR sk, where sk is the RC4 output (a long stream of pseudorandom bits produced from the key k). Suppose that you apply the "append hash then encrypt" method. You start with message m, and you get this:

    e = (m || h(m)) XOR sk

Now an attacker comes by, and he is smart, and he guesses the contents of m (remember: the attacker is after integrity, not confidentiality, so we assume that he already knows the message). Since a hash function has no key, the attacker can recompute m||h(m). From that he gets:

    sk = (m || h(m)) XOR e

Now the attacker has the key-dependent secret stream sk. He then proceeds to encrypt his fake message m' by computing:

    e' = (m' || h(m')) XOR sk

This works as along as m' is not longer than m (it could be shorter). Upon decryption, the hash will match, and integrity is defeated. Fun fact: I know a system for Web-based online banking that was using this construction for integrity, and was widely deployed. Fortunately, it has been fixed more than a decade ago.


Wireshark - How to monitor TLS traffic from a malware? (It does not write into the SSLKEYLOGFILE) I recently found malware that uses TLS 1.2 to communicate with the c2 server.
I wanted to check the content of that but is encrypted. I have tried the method with the SSLKEYLOGFILE but unlike for HTTPS traffic via the browser (in this case firefox), there is no "encrypt TLS" tab in wireshark.
Is there a way to get the decrypted content of the request from the malware?

No. without cooperation from either side, you cannot decrypt the TLS traffic. That is the purpose of TLS. You are in the same position as an attacker of TLS, and TLS is doing its job.
Since you have access to the computer that runs one side of the TLS connections, you can use a debugger to find the session keys in RAM and dump them (i.e. do the same thing browsers do when you ask for SSLKEYLOGFILE). This of course is harder, because the malware is not cooperating.
EDIT: Like Zicar mentioned, if the malware is doing a bad job at being a TLS client, then MiTM-ing it might be easy. If it's not checking the certificate or checking it using the host's trusted root CAs store. Then you don't need to reverse engineer it. If it pins the server cert then you need to modify the malware to pin your own cert instead or skip the pinned cert check to MiTM it. If it uses a client cert, you need to extract the client cert and key to MiTM it.


How secure are Tor circuits? Sometime ago I was talking with a friend about security of different anonimity software kits. The most famous software we talked about was Tor.

While I was talking about the triple secret used in tor nodes, he asked me a very sensible question: Have you ever asked yourself how are the circuits built?

What I immediately thought is that the first connection must be made to a kind of central authority. And what I also thought is that such authority can be compromised beforehand, generating compromised circuits which could lead you to a ... "trap" (i.e. a sniffing exit node).

Am I right? I did not find any explanation un the official docs about where does Tor client connect to make the circuit. How are the circuits built? How secure is it (security: regarding having compromised nodes)?

The Tor client ships with a hard-coded list of "directory authorities": servers that maintain a list of known Tor nodes.  On startup and at intervals afterwards, your client connects to them to get a copy of this list.

Once your client has the list, it builds the circuits itself, selecting entry, middle, and exit nodes more or less at random.  From a theoretical security perspective, it doesn't really matter if some of these nodes are evil, as long as you don't get both an entry node and an exit node controlled by the same evil person: an entry node knows who you are but not what you're doing, an exit node knows what you're doing but not who you are, and a middle node knows nothing.

That said, there are a number of evil exit nodes out there.  The more obvious sort injects advertising, malware, or other modifications into the traffic, but the Tor community is generally fairly good about spotting and removing these.  More worrying is an unknown number of exit nodes that silently record or otherwise monitor traffic passing through them: if that traffic contains readable identifying information (say, an email address), the exit node now knows both your identity and your activities.  This is why you should only use encrypted communication methods (eg. HTTPS) over Tor.

If you've got more questions about the details of how Tor works, there's a dedicated StackExchange site for it.


Maximum limit of nping --rate option nping - Network packet generation tool or ping utility.

There is an option called --rate which send probes at a given rate. What is the maximum rate that can be sent? or What is the limitation of the rate?

According to the source code, it appears that while the software requires only that the rate be a positive integer, the rate is functionally capped at 1001 since the rate is also used to calculate a delay:
1000 / rate

Your actual maximum rate will depend on your machine resources and the network.
A note in the code also suggests that 1000 is a "very high rate" and is used as an extreme test case.


Sending sensitive information via self destructing link in an email I need to come up with a simple way for people within the company to send out arbitrary sensitive information to arbitrary recipients. There is an equal chance that the sender and recipient will be using a MAC or a Windows machine. Assume the sender and the recipient frequently need to share sensitive information, are not technically savvy and are impatient, meaning that anything which is considered to be too difficult to understand or takes more than a couple of steps are not going to be used (and will not be enforceable).

I have found this tool which appears to solve most of my concerns: onetimesecret.com.

It basically allows some text to be entered and then generates a self destructing link which can be shared with other recipients by email. The main concern is that it's hosted by an external organisation and that it only allows transfer of text. I will get around these issues by building our own version which includes a file upload facility and will host on our own servers.

Obviously this is not a silver bullet by any means but it appears to minimise some of the risks of sending out sensitive information via email. My only concern remaining is that it potentially makes sensitive information available over a public facing link which would otherwise only be available if an email account was breached. On the other hand, that link should in theory only be accessible if somebody already had access to the email containing the link. Due to the complexity of the links it doesn't appear to be feasible to brute force them.

So if I use a solution like this and send out the links via email, am I somehow making the file more likely to be able to be accessed than if it were included in the email alone? I cant think of any way, other than by accessing the email containing the link or by brute force, that the information could be breached.

I think that onetimesecret.com it's a very useful service, and it fits your needs.
Of course, you should share the onetimesecret password by a different channel in order to increase the security and avoid the case of compromising the sensitive information if someone has access to the email account.
I have dealt with these situations before and, depending on the context, I have used several tools (and also a combination of them):

You can use a cloud storage (like dropbox or google drive), to store a 7zip protected file with the sensitive information.
FTP server inside your company (You should read about Pure-ftpd in *nix)

I agree with Philipp, encrypting Emails is always the most secure alternative. But it is not always easy to implement this.

An easy way to address your concern and perform encryption, it is by creating an email account in Hushmail.com. The service allows you to set a password at the moment of sending the email (it is even easier than opening onetimesecret). But remember, you must always share the encryption key by a different channel.


How are UUIDs assigned in P2P protocols I am learning about P2P in general (mainly blockchain). I know many P2P protocols uses a distributed hash table for node lookup (kademlia) that maps UUIDs of nodes to their addresses.

I am curious about the most common way of UUID assignment.

Do nodes generate their own UUIDs? This would be dangerous since a naive or malicious node could generate an already existing uuid, right?

Or do some kind of boot nodes generate UUIDs for the joining nodes by wrapping a UUID in a certificate that normal nodes later can verify (since they all trust the boot nodes). The boot nodes would act as certificate authorities. It feels like using centralized CAs goes against the purpose of a P2P network though...

Or are some kind of Web of Trust used, where nodes vouch for each others UUID?

How are UUIDs commonly assigned in a P2P protocol?

DHT nodes randomly generates node ID by themselves.

def generate_id(length):
id = ""
for i in range(length):
    id += chr(randint(0, 255))

return id

def generate_node_id():
hash = sha1()
hash.update(generate_id(20))
return hash.digest()`

Node ID is generated randomly. Node ID is a 160-bit SHA-1 hash so the keyspace is 2^160. It is unlikely that one node has the same Node ID as the other node. Even if a malicious node impersonates another node, nothing will happen.

That node continues to function as usual without facing denial of service. Other nodes will continue to query that node for lookup search as that node has stayed longer in DHT than a malicious node and is known to other nodes. Whereas the malicious node has to propagate his presence in DHT which can take some time.

The situation will look something like same node ID but with two different routing tables. Some new nodes will query that malicious node as they discover him and he may return false responses but as the data in DHT is replicated very quickly, even if a single node is acting malicious that doesn't affect other nodes in DHT. Instead a threat actor signs up thousands of random nodes in DHT to propagate false information. This is called Sybil attack.

Cloning node ID is not really a problem because nodes die very quickly. By the time a malicious node will propagate his presence, the victim is probably gone offline and come back with new node ID. Though BitTorrent spec recommends to keep the same node ID as earlier because your earlier node ID might be still in other's routing table.


DNSSec vs SSL and IPsec Theoretically, DNS cache poisoning shouldn't matter,because everything important is protected by SSL and IPsec.

So why DNSSec was developed?
Aren't the first two protocols sufficient?

SSL and TLS provide transport security, but after DNS resolving. So if the DNS cache has been poisoned the connection will go to the wrong server.

But after the connection has been made and the TTL of the DNS is ie. a day and then the dns poisoning takes place this has no effect anymore, because the client will do no dns resolving (because he already knows where to connect to...).


How to store an user access token on a third party site in the front end I am working on a wordpress plugin that provides a comment thread system kind of like disqus (but different).

In order to login (to post comments) the workflow is like this :

User clicks on log-in on the wordpress blog
A popup opens with the login form on the backend api for my plugin (another site)
The user logs in and using PostMessage I send back an access token.

Now with that access token when he does action like upvoting or posting a comment I'll send a post request to my backend api along with the token and if the token is valid I add the comment/upvote to the database.

But I am not sure how to securely handle the user token : My first thought was to put it in a cookie but then any malicious wordpress blog can run some js to automatically steal all the tokens from users who log onto their websites.

And since all of the logging is happening on the front end of the wordpress blog I don't see how I can store data in a way that the backend api can access it when the user does an action but not a malicious blog.

How can I securely store that token ? I thought about embedding the website in an iframe in order to rely on session variables but I am not sure on how secure that is.

That token should be set by your back end server, not the wordpress site that is using your plugin.

If your server then sets httpOnly when issuing the cookie, requests (for example via JavaScript from the wordpress site that uses the plugin) to your backend would have that cookie included in the request by the browser while the javascript itself (from the wordpress page) will not have access to it.

From the OWASP:

  If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

After all, your question implies that you didn't think your communication model through all the way; this information does never need to be accessible from the scope of the wordpress blog.


Identifying Memorable Composition Rules A single word can be transformed in so many ways to create the password. With any word of length l there are l! different permutations. Appending digits and symbols to the word create alphanumeric password. Even the leet transformations(replacing a with @ etc) can be applied to create passwords. The number of such transformations are enormous but only few are memorable and used. The leak of password database leaks provide insights into most common tricks used by the creators of the passwords. But some transformations might be tricky and not known to the attacker yet, because they might not be popular or might not be available in the leaked database . So my question is "Can such tricky and memorable transformations be identified without depending on the or analysing the breached data ?"

My point is that security through obscurity is not going to help. Some human created passwords might be secure only because the tricks are unknown. Understanding such set of tricks, will eventually lead to better strength meters and therefore better sense of security. It will also help to identify if the humans can create secure passwords at all or not? and end the cat and mouse game between the attackers and us? May be it can also imply the replacing the password scheme for authenticating with some other schemes, I am no expert to tell, but these are my concerns.

No; by definition, you cannot identify a trend without data.

However, anything that you or I or anybody else can come up with can also be thought of by an attacker.  In general, you cannot assume that the attacker cannot or will not find out what method you are using.  This is called 'security through obscurity' and is a common trap that people fall into.


Can a school look through your messages on a personal account if you logged in on your school computer? Is it legal for a public school to scroll through your texts on a personal account of yours if it was on your school computer?

Technically, anyone with administrator privileges can log your keystrokes and duplicate your username and password. They could also copy browser cookies or other data to continue your session.

This is one reason why many security professionals discourage accessing personal or company data on public terminals.

Whether it is legal depends on a number of details.

In the US, if there is a warning or a user agreement that indicates monitoring may occur, it is usually permissible to observe anything that occurs on the machine. Organizations that are highly secure (or paranoid) can install applications like ObserveIT with screenshot capability.

Poking around and stealing credentials isn't usually allowed, however---unless there is justification for an investigation. Schools in the US have complicated rights and responsibilities when it comes to student safety and privacy, so it is best to have a lawyer review the details if the issue is serious.


What are the privacy advantages of a DNS encryption service such as DNScrypt? Privacy experts recommend dnscrypt (for example r/privacy). The only advantage of DNScrypt I can see is that it protects against an attacker sniffing my DNS traffic (I am using a VPN anyway) and man-in-the-middle attack (MITM) not possible.

This is a screenshot of my config (Tomato router):

What are the advantages and risks of DNScrypt? Does a DNS operator such as  cryptostorm.is have the ability to see my DNS traffic?

The only advantage of dnscrypt I can see is that nobody can sniff my
  DNS traffic (I am using a VPN anyway) and man-in-the-middle attack
  (MITM) not possible.

DNSCrypt aims to protect your DNS traffic from not just 'sniffing' (passive) attacks but more importantly active attacks - where the attacker changes the DNS response and maybe point it to the attackers server.

You say MitM is not possible. But it depends where in the process you think you are at at risk. Yes the VPN tunnel is protected (assuming the client is configured to route DNS through the VPN and not the default gateway). In that case you may be correct in assuming you are safe enough for your needs. Remember though the VPN terminator will (in this example) query the DNS for you, so maybe that could be a point of weakness.

  risks of DNScrypt?

Risks, biggest is whether you trust installing software on your clients. Whether you trust the software to actually do what it claims. Is the risk of DNS interception worse than the possibility of the software installed causing some adverse effect on your OS?

  Does the DNS operator cryptostorm.is see my DNS traffic?

I do not know anything about this service, but if any service you use terminates at the service provider you have to assume they can (probably will) record the traffic in which terminates. Therefore if the DNS connection to them terminates there and they use a resolver then they will know what it is you looked up via DNS.


What is the difference between SYN cookie, SYN cache, and SYN proxy? I am trying to understand some techniques regarding SYN flood prevention and there are three terms I couldn't find a clear explanation of.

The terms that are confusing me are:

SYN Proxy
SYN Cache
SYN Cooke

What do these mean and what is the different between them?

Syn-proxy is a propriatary protocol. An appliance will proxy any TCP request but will only forward it to the server if the three way handshake is completely established.

For SYN-Cache and SYN-Cookie refer to the following excerpt from Cisco:

  SYN Caches: Two end-host defenses, called SYN caches and SYN cookies
  (described later), operate by reducing the amount of state allocated
  initially for a TCB generated by a received SYN, and putting off
  instantiating the full state [8]. In a host that uses a SYN cache, a
  hash table with a limited amount of space in each hash bucket is used
  to store a subset of the data that would normally go into an allocated
  TCB. If and when a handshake completing ACK is received, this data can
  be moved into a full TCB; otherwise the oldest bucket at a particular
  hash value can be reaped when needed. In Lemon's FreeBSD example [8],
  the SYN cache entry for a half connection is 160 bytes, versus 736
  bytes for a full TCB, and 15359 entries in the SYN cache are
  supported.

  The SYN cache data structure is robust to attackers attempting to
  overflow its buckets because it uses the initiator's local port number
  and some secret bits in the hash value. Because stacks are a more
  effective data structure to search than a simple linked list, stacks
  that use a SYN cache can have improved speed, even when not under
  attack. Under Lemon's tests, during an active attack a host using a
  SYN cache was able to establish legitimate connections with only about
  a 15-percent increase in latency.

  SYN Cookies: In contrast to the SYN cache approach, the SYN cookies
  technique causes absolutely zero state to be generated by a received
  SYN. Instead, the most basic data comprising the connection state is
  compressed into the bits of the sequence number used in the SYN-ACK.
  Since for a legitimate connection, an ACK segment will be received
  that echoes this sequence number (actually the sequence number plus
  one), the basic TCB data can be regenerated and a full TCB can safely
  be instantiated by decompressing the Acknowledgement field. This
  decompression can be effective even under heavy attack because there
  is no storage load whatsoever on the listener, only a computational
  load to encode data into the SYN-ACK sequence numbers. The downside is
  that not all TCB data can fit into the 32-bit Sequence Number field,
  so some TCP options required for high performance might be disabled.
  Another problem is that SYN-ACKs are not retransmitted (because
  retransmission would require state), altering the TCP synchronization
  procedures from RFC 793.
  The exact format of TCP SYN cookies is not an interoperability issue,
  because they are only locally interpreted, and the format and
  procedures for generation and validation can vary slightly among
  implementations. Figure 5 depicts the general process of SYN cookie
  generation and validation used by multiple implementations.

  To compute the SYN-ACK sequence number (that is, the TCP cookie) when
  using TCP cookies, a host first concatenates some local secret bits, a
  data structure that contains the IP addresses and TCP ports, the
  initial SYN sequence number, and some index data identifying the
  secret bits. An MD5 digest is computed over all these bytes, and some
  bits are truncated from the hash value to be placed in the SYN-ACK
  sequence number. Because the sequence number is about a fourth the
  size of the full hash value, this truncation is necessary, but
  generally at least 3 bytes worth of the hash bits are used, meaning
  that there should still be close to a 2^24 effort required to guess a
  valid cookie without knowing the local secret bits. In addition to the
  hash output, some of the cookie bits indicate a lower bound on the
  Maximum Segment Size (MSS) that the SYN contained, and the index bits
  identifying the local secret used within the hash.

  To validate a SYN cookie, first the acknowledgement number in an
  incoming ACK segment is decremented by 1 to retrieve the generated SYN
  cookie. The valid value for the set of truncated hash bits is computed
  based on the IP address pair, TCP port numbers, segment sequence
  number minus one, and the value from the secret pool corresponding to
  the index bits inside the cookie. If these computed hash bits match
  those within the ACK segment, then a TCB is initialized and the
  connection proceeds. The encoded MSS bound is used to set a
  reasonable-sized MSS that is no larger than what was originally
  advertised. This MSS is usually implemented as three bits whose code
  points correspond to eight "commonly advertised" MSS values based on
  typical link Maximum Transmission Units (MTUs) and header overheads.

  Hybrid Approaches: A hybrid approach combines two or more of the
  single defense techniques described previously. For instance, some
  end-host operating systems implement both a large backlog and SYN
  cookies, but enable SYN cookies only when the amount of the backlog
  that is occupied exceeds some threshold, allowing them to normally
  operate without the disadvantages of SYN cookies, but also allowing
  them to fail over to the SYN-cookie behavior and be strongly protected
  when an attack occurs.


Is it safe to publish something encrypted with a password if you make it insanely difficult to crack? Let's say you have a very important private key that you don't want to lose. You think of posting it to http://pastebin.com/ but then relize that elimanates the point. So you think of encrypting with the help of password key derivation, but that normally isn't enough. You know this because similar algorithms are used to protect passwords on servers, and when those hashes get leaked, although the passwords are safe for a time, the server still tells everyone to change their password. This implies that it isn't safe for them to be public for long periods of time.

A server usually insists on password hashing to take only 1 second or something. Since this is a password for recovery, you don't care if it takes a while. You are fine if it takes a really long time, such as 24 hours, for example.

If you set your password key derivation to take a really long time, such as a day on a typical computer, is it safe to publish contents encrypted with that key publicly? Or will your still be vulnerable to brute force?

The reason for key strengthening is that passwords don't have as much entropy as is expected for the key. The time it takes to break a key is proportional to the number of possible keys. Strengthening algorithms used on passwords compensate for the poor entropy by increasing the proportionality constant. But the gap is so large that strengthening cannot compensate. A password with 64 bits of entropy is very hard to memorize — that's 10 random printable ASCII characters (if you start imposing memorable features, the entropy goes way down) or 14 random lowercase letters, but to reach 128 bits of “cracking difficulty”, which corresponds to the most common key size for symmetric encryption, you'd need a whooping 2^64 — about a century of CPU time.

In your scenario, a memorable password is the wrong method. It would be a password that you rarely use, yet needs to be very strong and thus hard to memorize.

Use a random key, instead of a password-derived key, and print it out. Store the printout in a secure place.

If the software you use requires a password, generate a random password with as much entropy as the key. 20 ASCII printable characters, or 28 random lowercase letters, or something equivalent, give you 128 bits of entropy. If technology progresses to the point that this is breakable, the key you're encrypting will probably not be secure anymore anyway. Since your password has enough entropy for a key, you don't need to strengthen it. Once again, print it out.

Once you go that route, you might as well print out the original key and forget about uploading it. But adding a level of indirection does have advantages. It means that an adversary needs to obtain both a copy of the encrypted key and a copy of the key encryption key. With this separation, if one of the parts is compromised, you may have time to act before the second one is also compromised. You can also store the key encryption key in several separate pieces. There are secret sharing algorithms that allow splitting a key in n pieces such that it can be recovered from any k pieces, but no fewer. If you want to keep things simple, you can generate multiple key encryption keys, upload the master key encrypted with each of these, and split the key encryption keys and dispatch the pieces so that it takes more than a single place to recover the whole thing.


MacOS able to access data without password On a Mac, one can go into recovery mode by turning off the Mac and clicking Command R while turning it on. Then, by typing resetpassword into Terminal, one is able to reset the password without entering the old password.
Why is this not considered a security flaw? It doesn't seem to lock out data, so I can easily go into a someone's laptop, reset the password, and see all their data.

If the disk is not encrypted, there is simply no way to prevent such attacks. Sure, you can make it slightly more cumbersome by requiring the attacker to insert the disk into another computer to modify files, but this is a trivial task that can be accomplished in five minutes.
The antidote to this is encrypting the disk volumes. This effectively blocks access to data, even if you're able to read and write the raw disk volume.


Can DD on its own be used to acquire a hard drive? If a hardware blocker cannot be acquired could an investigator use DD without a write blocker, would that be forensically sound?

The most important part of the forensic investigation is to prove beyond a doubt the integrity of your evidence.

A good way to do this is to compare the hash of the acquired disk image against the hash of the original disk which should have been taken when the disk is recovered from the crime scene. Said hash should most probably be on the chain of custody form.

If a hardware write blocker cannot be used, I would suggest booting the system in question into a live Linux CD that mounts the disk in read-only mode. A forensics live CD like Helix can do this automatically.

Instead of using the standard dd tool, I would suggest dcfldd, a version of dd specifically for forensics use. It has a bunch of features useful for forensics investigation that the standard dd tool does not, such as on-the-fly hashing.