What is a good algorithm for memorizing a password in a few minutes? Let's say I am following good security policy and picking passwords that are:

Long
Complex (passphrases where possible, otherwise random strings with special characters)
Unique (completely independent for different sites/things)
Changed regularly

Let's also say that for this particular set of passwords, I do not feel comfortable keeping it written down or in a database like LastPass. We are only using good old fashioned memory.

What's an effective way to remember several infrequently used passwords? For example, one could conceive of the following naive algorithm:

When you set a new password, take a sheet of paper
Repeat 100 times:
    Write password on paper (while spelling it with your internal voice)
    Fold that part of the paper so you can't see the password
When finished, destroy the paper

How can this be improved upon? Do you have experience with similar methods, which can be applied quickly at the time of creation of the password, to memorize it?

To restate the problem: You have decided that you will not store a number of passwords anywhere other than your memory. These may be passphrases, or they may be strings of random ASCII characters, or even 4-digit PINs. They are always randomly generated and periodically changed. The passwords will be used infrequently (perhaps once in a few weeks or days), so usage alone will not be able to ensure retention. What do you do to make sure you won't be hitting the "forgot password" link in a few weeks?

As per the good subjective question guidelines, please try to provide answers that are:

In-depth rather than short
Ideally draw on your personal experience
Explain the rationale behind your method (if you know of any research regarding the effectiveness, even better)

Maybe the best way is sticking to an algorithm for your password. You might have two or three algorithms to cover complexity restrictions, you might, for example learn the following algorithm:

For any service:

1. Select a reusable secret string
2. Add some common pattern, ie: the name of the service
3. Add some Caesar like algorithm: a=@ e=3 i=g1n d=|) g=Y1 o=()...
4. Add some logic to alternate the strings you have (one char from 1, and one char from 2).
5. Add some random text depending on the length of the service (add a number every length(name of the service)/2.

Build it up, ie:

Secret password: "algorithmpass"
Service: "stackexchange"
Caesar: "@lY1()rg1nthmp@ss" and "st@ck3xch@nY13"
Alternate strings:  "@sltY@1c(k)3rxgc1hn@tnhYm1p3@ss"
Add numbers every len(stackexchange)/2 = 13: "@sltY@1c(k)3r1xgc1hn@tnhYm12p3@ss"

And that is that's you password, it is very hard to remember but "quite easy" to rebuild it.

The disadvantages are clear: once someone crack your algorithm he get access to all the related accounts. The pretty thing here is that you can make really simple algorithms that build great passwords. Also, the passwords generated can be quite complicated to remember, so you should choose your algorithm carefully to meet day to day usability criteria.


Secure web browsing on unencrypted wifi Is it possible to securely browse the internet when using unencrypted wifi?

Can I securely connect to a home server and route my traffic through that?

What are the risks with using an authorized_key to ssh to a home server and tunnel my traffic through it?

There is an emerging market for secure virtual browsers, which are able to solve this problem by providing a client that connects securely to a browser running remotely in a secure container. Some of the companies in this market are:

Authentic8
Menlo Security
Spikes Security
Ntrepid

Some of these solutions are enterprise focused or require hardware. I prefer Authentic8; but, I'm biased.


How can the nmap tool be used to evade a firewall/IDS? Some techniques are used to secure the operating system against network attacks e.g.: firewalls, antivirus software, an IDS like SNORT, etc. To take advantage of the nmap tool, is it possible to deceive the intrusion detection system by evading detection?

There are various ways that comes handy with nmap to evade the basic rules of firewall or Intrusion detection system.

1) Packet Fragmentation:

This option evade pattern matching detection technique. Since packet reassembly can be quite processor intensive, it's common for admin to disable it.
In snort, fragmentation reassembly functionality is disabled by default.
Usage: #nmap -f <other options>

2) Decoy Scan:

We can add some random hosts either from the attacker's subnet or from victim's subnet while scanning the target.
In firewall logs, there will be multiple hosts along with the attacker's IP making it difficult to trace the attacker.
Usage: #nmap -D <ip1, ip2,...,ME> <other options>

3) Spoof source IP address:

Attacker can spoof the source IP address (from the victim's subnet) so that it'll appear to IDS/firewall that it's legitimate user and will be passed.
Usage:#nmap -S <spoofed ip> <other optins>

4) Spoof source port:

Attacker can spoof the source port no. while scanning the target to bypass the rules in the firewall that allow requests from few ports (ex. Port 53).
Usage: #nmap --source-port <port no> <other options>

5) Scanning Timing:

There are various timing options included in the nmap to send successive packets. It can be used to evade some of the rules in the firewalls or IDS.

T0: Paranoid (Waits 5 minutes between sending each probes, not detected by IDS/IPS)

T1: Sneaky (waits 15 seconds)

T2:Polite

T3:Normal

T4:Aggressive

T5:Insane (easily detectable)

-Usage: #nmap -T<0-5> <other options>

There are other options like Data-length appending and Badsum which can also be used. IDLE Scan is the best that I'll suggest for evading the firewall.
Although, all the methods mentioned above claim to evade the firewall/IDS, but if rules are set properly your scan can still be detected.


How to make my wireless internet or WiFi device secure for personal use? Sometimes I have seen that my internet packets are being consumed after all I did not use it but my device is connected and ready for use. So it is due to some other reasons or someone is using my internet packets. I want some suggestions to make my internet connection more secure.

Well, WiFi internet security is one of the major issues that the users are always complaining so I am going to share some quick tips to make your internet connection secure.

In the first step you need to open your router setting page you can only do that by typing “192.168.1.1” in your browser page and then enter your user name and password which can be given in the user manual of the internet router, usually each routers have different access.

Step 2. Create a Strong Password:
After logged in to your account all you need is to change your default password and to make it secure. Generally to change your password there are default values admin and password. Once you have done this your device will be automatically disconnect from the other devices.

Step 3. Change your SSID name of Network
Generally SSID name of the connection is defined as “default” or at the name of your internet brand for e.g “cyberetnet”. The change in the user name does not make your internet connection more secure but it can create difficulty for the others to know about the network they are connecting too.

Step 4. Enabled your network encryption:
Well, this option will prevent the other computer in your area to use your internet connection. All you need is to enable the encryption of your network.
In order to enable this feature you have to login to your wireless router security setting configuration page and choose its security method. For the older devices WEP is more reliable and for the other devices you choose WPA2.  To make a strong passphrase use small, capital, numeric and special characters to make it difficult for the other users.

Step 5. To Filter the MAC devices:
Every laptop, cellphone and other WiFi enabled devices have its own IP addresses and to prevent other users to use your device you can put the IP of only those devices which you wants to connect and others can’t connect to your device.
Almost every MAC address is hardcoded in network equipment, so one address will only allow one device to connect. If the attacker want to attack for spoofing first they have to find the MAC address of the device in which the network in connected and it very difficult for them to find.

Step 6. Upgrade your Router’s firmware, time to time: For this purpose you should have to check the manufacturer site time to time for the latest updates of your firmware. To find your existing firmware version you can check the router’s dashboard at 192.168.*.

All the above steps mentioned are enough to make your internet connection completely secure and safe from attackers.


Prevent shell script inside image file Recently, one of my website was hacked by someone who uploaded an image (shell.gif) to my server.

I have put server side validation to check file extension + mime type of the image. However, they are still able to upload shell script using gif extension again.

Is there any better way to validate image file programmatically if they have any shell script signature beside two methods i mentioned above?

The mistake isn't how you validate the file.  You should never execute any file that is uploaded.  Full stop.  If an uploaded file is supposed to be an image, then the only thing you should do with it is present it to an image processing program to be opened.

In a sense, the entire desktop paradigm of guessing the correct program to open a file by looking at its name and/or contents is a terrible idea, and absolutely must not be used by servers,
with untrusted data.


Why don't we need a WPA handshake on a ARP spoofing MiTM attack? On wireless network running under WPA2 protocol, the communication between a client and the AP is encrypted using a session key (calling it that way, but if there's a more exact term I'd be glad to edit it) that is exchanged between them during the 4-way Handshake (which checks if said client is in possession of the PSK).

This session key is unique for each client connected to the AP. I'm assuming that statement since when an attacker is sniffing a network, he needs to have the handshake of each client if he wishes to decrypt every clients communication with the AP. So even if you're connected to said network, you won't be able to decrypt someone elses communication with the AP, since your session key is a different one (unless you happen to capture the 4-way handshake of the other client).

During a MiTM attack using ARP spoofing, you are already connected to the AP, but you don't have the other clients session keys. Once you poison their ARP cache, they will start sending the packets meant to be sent to the AP to your machine. The question is, since they still believe they are talking to the AP, won't they encrypt the packets using the session key that they exchanged with the AP during connection?

I ask that because experimenting (on my own network) I didn't need the 4-way handshake to see the decrypted traffic on the attacking machine, which I believed I'd need. I was wondering if maybe the session key is attached to the MAC address, so once the victim starts talking to your MAC, even though it believes you're the gateway, it will not encrypt the traffic with the session key it was using before.

Firstly, in order to do ARP poisoning you have to be connected to the wireless network you're going to poison responses on. You may already know that, but your question doesn't indicate that you know that's a requirement, so I wanted to make sure that it was clear. As for your answer:

Simply put, ARP poisoning works because ARP works. The only thing that changes is that the value of the responses sent by the attacking machine are faked. ARP replies are implicitly trusted, and because they expire, they need to be refreshed periodically. Attackers leverage this implicit trust to send fake responses. If the details of the 4WHS were needed for ARP, no one (real or attacker) would be able to communicate ARP replies.


Got warnings last night from a SQL injection attack - What were they trying to do? In sum, they tried 10 different commands. The site is ran on Wordpress, but has a security plugin that, "blocked a page visit to your site."  I'm curious as to what they were trying to go after though.  Also not sure why most have the "7e7b2eab8e" in it.

The commands were from 185.222.209.222 which seems to have quite a lot of reports on it, but also seems to be a VPN.

Said commands were:

  The offending parameter was "v" with a value of "7e7b2eab8e AND
  (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT
  (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM
  INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)"

.

  The offending parameter was "v" with a value of "7e7b2eab8e') AND
  (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT
  (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM
  INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND ('bNUG'='bNUG".

.

  The offending parameter was "v" with a value of "7e7b2eab8e) AND (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND (2851=2851".

.

  The offending parameter was "v" with a value of "7e7b2eab8e' AND (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND 'dyyf'='dyyf"

.

  The offending parameter was "v" with a value of "7e7b2eab8e AND (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)-- BfVf".

.

  The offending parameter was "v" with a value of "7e7b2eab8e%' AND (SELECT 7904 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT (ELT(7904=7904,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND '%'='".

.

  The offending parameter was "v" with a value of "(SELECT 2340 FROM(SELECT COUNT(*),CONCAT(0x716b787a71,(SELECT (ELT(2340=2340,1))),0x71766a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)".

.

  The offending parameter was "v" with a value of "(SELECT CONCAT(0x716b787a71,(SELECT (ELT(7364=7364,1))),0x71766a7871))".

.

  The offending parameter was "v" with a value of "7e7b2eab8e) UNION ALL SELECT NULL-- AxsE".

.

  The offending parameter was "v" with a value of "7e7b2eab8e) UNION ALL SELECT NULL,NULL-- ggeG".

It would appear that they were primarily testing to see if you were vulnerable. The reason I say this is that the bottom three inputs don't actually reach out to any tables, and are purely testing whether they can get an input back from the server via an injection attack.

My guess is that they were targeting the information_schema schema in the top inputs since it's standard on all MySQL instances, and they know it will be there (as opposed to trying to guess what schema/table names you use for your non-system tables). Once they confirm they can get information back from information_schema.character_sets, they can start looking at what tables/schemas you have on the database, and select/update/delete from those.

If you're confident that all the inputs on your site were properly sanitized before the attempted attack, I wouldn't worry that much (keep in mind that an attacker may patch up any holes once they've got persistent access). If you're not confident in this (or don't know what input sanitation is), then how much do you trust the security plugin to catch every possible instance of SQL injection? Your answer to this question will indicate whether you should consider the system compromised.


Extract SquashFS filesystem with shsq magic number for a few days I was trying to extract the filesystem of a router firmware. Checking the image that the vendor provides I can see a SquashFS flag on it:

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------
52          0x34        uImage header, header size: 64 bytes, header CRC: 0x1A27096C, created: Tue Nov 27 06:52:32 2012, image size: 3448768 bytes, Data Address: 0x80000000, Entry Point: 0x8023A000, data CRC: 0x584BBD98, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
116         0x74        LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 2445108 bytes
983092      0xF0034     Squashfs filesystem, little endian, non-standard signature,  version 3.0, size: 2463170 bytes,  637 inodes, blocksize: 65536 bytes, created: Tue Nov 27 06:51:11 2012

Once extracted the file and checking it with hexdump I found the folowing magic number shsq:

00000000  73 68 73 71 7d 02 00 00  00 00 00 54 03 00 00 08  |shsq}......T....|
00000010  1c 71 b7 a0 12 71 b7 19  1f 73 00 18 03 00 00 00  |.q...q...s......|
00000020  38 72 10 00 c0 02 01 cf  54 b4 50 d4 0c 1f 10 00  |8r......T.P.....|
00000030  00 00 00 00 00 01 00 2c  00 00 00 02 00 a2 bf c2  |.......,........|
00000040  95 25 00 00 00 00 00 b6  95 25 00 00 00 00 00 be  |.%.......%......|

This is not the first time I found this header, but I couldn't find a solution for extract it.

Things I tried so far:

All versions of unsquashfs and firmware-mod-tools.
Modify the header for a known one that the unsquash tool could recognize.
This patch http://sandeen.net/wordpress/computers/uncompressing-cisco-x2000-firmware-images/

You can find further information of this issue in this link but without solution:

http://forums.modem-help.co.uk/viewtopic.php?t=9668

How to achieve this?

It would really help if you could provide the model of the Router and the firmware versions, you're looking at. I know some router manufactures like to to make slight modifications to their FS tools (read SquashFS). It's also possible that the extracted image is encrypted or compressed again in a different format. Did you look at OpenWRT site?


Malicious proxy and HTTPS I am curious about security of proxy servers. I read a few threads and all of them were overly general or missed the point I am interested in, the devil is in the details.

SCENARIO

The malicious agent has a proxy server and HTTPS traffic goes through it, e.g. a client making connection to an HTTPS protected website.

MY QUESTIONS

What is the span of the HTTPS protection? Does it protect traffic
between client and destination or is it only in between proxy and
destination?
Is it trivial for the malicious proxy to directly sniff critical data? With trivial I mean not using significant computational power. With critical data I mean things like secrets or passwords not metadata like IP addresses and so on.
Do SOCKS and HTTP protocols make difference in the difficulty of such attack?

Other factors should not be assumed, or assume worst case scenario.

What is span of the HTTPS protection? Does it protect traffic between client and destination or is it only in between proxy and destination?

With a HTTP proxy the client requests a tunnel to the server (using HTTP CONNECT request) and then creates an end-to-end TLS session between client and server over this tunnel. A non-intercepting proxy will only forward the initial handshake and the encrypted data.

An intercepting proxy though might terminate the TLS connection from the client at the proxy and create a new one between proxy and server, thus having access to the decrypted traffic. Of course the proxy cannot use the original server certificate, thus the client must somehow trust the certificate generated by the proxy. This is either because the proxy is trusted and has its CA in the client (i.e. corporate proxy, local antivirus) or because the client has explicitly ignored the warning that the connection is not trusted.

  Is it trivial for the malicious proxy to directly sniff critical data. With trivial I mean not using significant computational power. With critical data I mean things like secrets or passwords not metadata like ip addresses and so on.

No, since a non-intercepting proxy will only see the encrypted traffic and the certificate of an intercepting proxy will not be trusted by a proper client.

  Do SOCKS and HTTP protocols make difference in difficulty of such attack.

There is no practical difference, its only a small difference in the initial data between client and proxy (i.e. HTTP CONNECT vs. SOCKS handshake).


Hardening Tor/proxy chain by choosing the relays' countries Tor is in fact just a proxy chain consisting of 3 proxies. A good enough reason to do the paperwork can be enough to deanonymize a user (the link is valid assuming all the relays' ISPs store logs). Thus Tor users' need to worry about their anonymity highly depends on their threat model. (blowing up the WTC is most likely more motivating to do the paperwork than DDoSing your competency's site)

Once, I've read something about making a proxy chain distributed over countries that don't have a good political relationship in some very downvoted (because of the rest of the question) question here.

But the idea itself is interesting. If you've used Tor and for some reason the US government wants to have a friendly talk with you, using a proxy in countries with bad political relationship with the US, such as Russia, would make the paperwork really hard.

A good example of this US-Russia relationship is the Sci-Hub lawsuit:

  Elsevier claims that Sci-Hub illegally accesses accounts of students
  and academic institutions to provide free access to articles through
  their platform ScienceDirect. The case is complicated by the fact
  that the site is hosted in St. Petersburg, Russia, making it difficult
  to target within the US legal system. [Source: https://en.wikipedia.org/wiki/Sci-Hub#Lawsuit]

Question (I admit this might be somewhat discussable/subjective): To what extent do the country choices affect users' anonymity (of course assuming you haven't hacked all the nuclear silos)? Is there any known case of paperwork beating a Tor circuit?

Note: I'm talking about knowing the user's Tor IP address only, nothing more. Not confirming their identity, but finding it.

... rather about chaining proxies through countries that don't have a good political relationship to make the paperwork a hard thing.

What paperwork? The nodes only know what other nodes are talking to it.
The way to 'reverse' a Tor connection is either by

Infecting the PC through Tor like the FBI did
Running / compromising an exit node and looking for identifiable info in the exit traffic
Running time correllation on the infrastructure used for entry and exit

The only paperwork i could imagine is with #3 but you only need to monitor the entry like this so the intermediate nodes don't matter. The likely opponent, state actors, will probably opt for the first two options. Infecting is easier and more reliable than tracing.


School's computers auto-login and can run .exe's Before this semester, to use any computer across campus, you had to log into Windows with a username and password.

This semester, when the computers start up they auto-login to an account (with let's say the username "Dogs").  They are always logged in as this account; the Log off option is disabled in the start menu.

I just checked that you can run an arbitrary .exe under the "Dogs" account by downloading the AutoHotKey binary and writing a "Hello world!" script.  It is very easy to write a simple keylogger in AHK although I have not!

AutoHotKey is just my example test.  I'm worried that a arbitrary .exe can be executing in the background.

Is there some security that my simple test is not hitting which makes my campus setup safe?  Or should I be worried about typing my Facebook password in?

Your school lacks some of the most basic requirements for security. Never use credentials for remote logins on a system you're not in complete control of and have full knowledge of its level of protection.

Shared computers such as libraries, schools, etc. should never allow access to USB devices for boot, autoplay or execute access. All devices should be scanned automatically when devices are connected. Users should have very limited access and if files are allowed to be downloaded and saved, they should be temporary and not allowed to be executed.  It is not difficult to secure a workstation. What is difficult is to get the person in charge of it to make an effort if they have not already. I would report what you have found but I would not report that you have tested the system with AHK and I would remove any instances of anything you have put onto the system. Being a good samaritan is not always healthy.  And, there is nothing on FB that is so important that you cannot wait until you are on a secure system to access it.

I would not make any effort to fix what you perceive as possible issues. You are not paid to support that system and depending on policies, you could be putting your liberty at risk. It is a tool for you to use, nothing more. Report your concerns and let the school deal with it.


Strategies to store/remember very long password? If future proof encryption is - in theory - possible it will require long password.

What are some of the strategies for storing or remembering very long - in this case rarely used - password?

For instance at one point Wikileaks shared the raw encrypted diplomatic cables with the community to prevent shutdown the password later leaked out. If I am right the password was very long string of random characters. Isn't storing such password securely equally challenging as storing the secret?

How about using a long verse from a Bible, the declaration of independence or similar "static" text that will be around unchanged in 100 years? What do you think of such strategy?

The virtue of a password is to make it possible for humans to remember it. If you want to store the password, then you are not talking about remembering; at which point you may forget this "long passphrase" business, which becomes just a nuisance. Store a random key which needs not be that long (16 bytes will be plenty in practice, the ultra-paranoid will go to 32 bytes, aka 256 bits, which is provably total overkill).

Also, a long verse from the Bible is a very poor passphrase because there are about 31000 verses in the Bible, thus making 31000 possible passphrases -- less than 15 bits of entropy, which is pathetic. As usual, it is not length which matters, but randomness; not what the password is, but what it could have been.


Patching Mac DMA attack I want to know a few things about the blackhat attack that attacks thunderbolt. Is there anyway to wipe or patch a currently infected computer? I am not  versed per se in THAT level of security. I was considering using veracrypt, but I understand the DMA attack works on the firmware update system, not the disk and can be used to get passwords. Can someone explain this to me? I have a late 2011 macbook pro and mac os 10.10.2 If it's possible to patch it, is there anyway to prevent it from working again? MY plan (at least so far):

Veracrypt use. I know how to use veracrypt eetc.
Possible 2fa with this? Yubikey or just a password program with yubikey.
Secure key chain access. Network etc.
 ETC ETC.
OTher things as well that I can't think of as of this writing, because I know the restoration procedure of my computer. It takes forever.
All started from a new clean machine etc.

But what about anything else? Basically I want nothing to work except the hard disk and I want to secure the efi boot partition (And anything else) so that NOTHING WORKS (hardware or other wise) unless you open the computer or have both the firmware passcode and the hard disk passcode. I am interested in physical security as of now. Is there a solution or workaround now?
Thanks!

In a word ... no.  These attacks bypass your OS and anything running on it.  If you are interested in physical security, you need to add hardware that protects these devices or by a secured computer.


What is protection ring -1? Due to the Lenovo firmware ThinkPwn bug I'm trying to understand privileges and rings.

If the kernel is Ring 0 and SMM (System Management Mode) is Ring -2, what could be in between that is Ring -1?

The "rings" nomenclature (0-3) you usually see these days started with the requested privilege level field in segment selectors as part of the design of x86 protected mode.

Back in the day, it was possible to make exclusive sections of the memory space called segments. In "real mode" it was necessary since you only had 20-bit addressable memory. When protected mode came along it still offered segmentation, but also privilege levels. Levels 0-2 are "supervisor" level and can do most things. Rings 1-2 cannot run privileged instructions but this is the only real limit; otherwise they are as privileged as ring 0.

Ring 3 meanwhile is "user mode". If you have your segment selector set to point to this ring, you require the help of the kernel via some system call interface in order to do anything requiring privileged CPU or memory access.

These days, it's pretty much required in 64-bit x86 to not use segmentation. However, segment selectors are still there - all segments just overlap and cover the entire address space.

So, the original purpose of ring 0-3 was to isolate privilege between user mode code and the kernel and stop user mode code walking all over system control structures.

Then virtualization became a thing on x86 and Intel/AMD decided to add hardware support for it. This requires a piece of supervisor (hypervisor) code to set up some control structures (called VMCS) defining the virtual machines and then call vmenter and handle vmexit i.e. conditions on which the virtual machine needs help from the hypervisor.

This piece of code is referred to as "ring -1". There is no such actual privilege level, but since it can host multiple kernels all of which believe they have ring 0 access to the system, it makes sense.

System Management Mode is another beast with special instructions. Firmware (your BIOS) sets up a SMM handler to handle System Management Interrupts - configurable depending on what the firmware wants to be notified of. When these events are triggered, the OS (or even hypervisor) is suspended and a special address space is entered. This area is supposed to be invisible to the OS itself, while executing on the same processor. Hence "ring -2", since it is more privileged than a hypervisor would be.

You'll also hear "ring -3" mentioned here and there in reference to Intel ME or AMD's PSP. This is a second processor running a separate firmware (Intel I believe uses ARC SoC processors) capable of doing anything it likes to the primary system. Ostensibly this is to provide IPMI/remote management of hardware type functionality. It can run whenever there is power to the hardware regardless of whether the main system is powered on or not - its purpose, as I say, would be to power on the main system.

From a security perspective, the lower ring you can get yourself into, the more undetectable you can make yourself. The bluepill research was about hiding from an OS the fact it was truly running in a VM. Later research has been done on SMM persistence. SMM persistence for example would potentially allow you to reinstall your malware even on a complete wipe of the hard disk and reinstall. Intel ME potentially opens up an always on persistent networked chip to install malware on the main target.

I've stuck to Intel chips here but you should be aware other platforms work differently. For example, ARM chips have "supervisor" and "user" modes, amongst others.


How to analyze server crash dump after recent patch update? I want to know, if there a way I can identify on windows systems an event / log  generated  due to patches incorrectly installed / or corrupted in the process. Is there a way I can process or look into these logs.

What you are asking for how to do crash dump analysis for determining the source of crash. There are number of techniques though i describe the basic one.

First you need to install Windows Debugger (WinDbg.exe) which is installed with windows software development kit.
Second part is to configure WinDbg with Microsoft symbol server.


Linux/LUKS/Full Disk Encryption: How can I mitigate SSD/flash media security security risk caused by unreliable physical deletion? Firstly, I do not think my question is answered by SSD full disk encryption as I am not looking for a binary "is FDE secure" - nothing is perfectly secure; rather I am looking for possible solutions to the specific SSD/FDE encryption conundrum.
Theoretical attack model: My computer's root disk (all mounted partitions) is an SSD that has been encrypted using LUKS (let's assume V1) with a 6 character dictionary word as a password.
I'm aware that LUKS doesn't use passwords directly to (en/de)crypt data, rather it stores the actual key (or "Underlying Key") in a header located at or near the first (logical) sectors of the drive. It encrypts the Underlying Key with the password (salty hashed several times etc.); thus knowledge of the password becomes the only way (assuming no crypto breakthrough/software bugs/side-channel attacks) in which the Underlying Key and consequently the disk can be decrypted.
The weakness of this first password is supposedly protected by LUKS deploying password strengthening techniques (the aforementioned salted hash). I do not have a high degree of trust that these techniques will really hold off a well-funded and determined adversary. It is not completely implausible that well-funded specialists possess classified hardware that can perform some silly large number of [insert hash function here] ops/second. My example in the brackets is perhaps a shade far-fetched, but hopefully, it communicates my concern; I know that a password of a certain length derived from a true entropy source is impractical to brute force (even post-quantum) I'm not a cryptographer; I cannot mathematically demonstrate it; however I know it to be true as surely as I know that I cannot fly.
Going back to the attack scenario, I decide to upgrade my password to a stronger one. I fire off a crypsetup command (I'm on Arch), wipe the old keyslot, write the Underlying Key encrypted by a salted hash of the new password into said keyslot. So, password changed? Maybe. The drive reports that the logical sectors have been set to zero but the opaque drive controller and its antics means there is a complete disconnect between logical and physical sectors. To my knowledge there is no reliable way of confirming this using commodity hardware, without degrading the lifespan of the drive by, for example, repeatedly writing zeroes to the disk, like grenades, hoping that one of them will hit the target and actually zero out the Underlying Key ciphertext encrypted using the old password.
It is known that SSD and flash drives in general deploy a technique called wear-leveling to increase product lifespan. These products also use other 'optimisation techniques' that create unpredictability and opaqueness with respect to the state of the physical media: The device is not honest with the OS/BIOS about what physical sectors are actually being altered. In other words- if I tell an SSD drive to write zeroes to the first 10k sectors, it may not actually overwrite the first (by physical location) 10k.
Back to LUKS- this potentially creates a (well-known/acknowledged) risk that the Underlying Key, encrypted using an old password could be physically 'lurking' in the SSD media and readable assuming a sizeable budget and a serious data forensics specialist.
I'm aware that LUKS supports storing the header on a separate disk- perhaps a thumb drive that, given the tiny space requirement- could be cost-effective to physically destroy it with thermite plasma and a sander and replace upon every password change.
ACTUAL QUESTION
What specific methods, steps or tools can I use to mitigate the risk that the Underlying Key (encrypted by an old- let's assume weak or compromised- passphrase) that has been wiped/deleted/discarded/etc by LUKS is actually lurking on the flash storage because the drive's controller never actually overwrote the bits at a physical level?

Withdrawn in favor of better information
Edit for additional Research
I went looking for some more detail and found some interesting results.
Discard/TRIM support for solid state drives

Solid state drive users should be aware that, by default, TRIM
commands are not enabled by the device-mapper, i.e. block-devices are
mounted without the discard option unless you override the default.
The device-mapper maintainers have made it clear that TRIM support
will never be enabled by default on dm-crypt devices because of the
potential security implications.
Minimal data leakage in the form of freed block information, perhaps
sufficient to determine the filesystem in use, may occur on devices
with TRIM enabled.
By default the LUKS header is stored at the beginning of the device
and using TRIM is useful to protect header modifications. If for
example a compromised LUKS password is revoked, without TRIM the old
header will in general still be available for reading until
overwritten by another operation; if the drive is stolen in the
meanwhile, the attackers could in theory find a way to locate the old
header and use it to decrypt the content with the compromised
password.

Milan Broz's blog (2014)

Ciphertext device without using TRIM from Figure 2 would be just black
box (all sectors have random data characteristic, disk was wiped
before use).
Conclusion?
If there is a strong requirement that information about unused sectors
must not be available to attacker, TRIM must be always disabled.
TRIM must not be used if there is a hidden device on the disk. (In
this case TRIM would either erase the hidden data or reveal its
position.) If TRIM is enabled and executed later (even only once by
setting option and calling fstrim), this operation is irreversible.
Discarded sectors are still detectable even if TRIM is disabled again.

In specific cases (depends on data patterns) some information could leak from the ciphertext device.
(In example above you can recognize filesystem type for example.)
Encrypted disk cannot support functions which rely on returning zeroes of discarded sectors (even if underlying device announces such
capability).
Recovery of erased data on SSDs (especially using TRIM) requires completely new ways and tools.
Using standard recovery tools is usually not successful.
If you decided to turn on TRIM for your device... You have been warned
;-)

Luks, Issuing & Allowing Discards (2017)

The first thing to check is that discards are enabled on your
encrypted device. If don't see allow_discards on your encrypted device
fstrim will not work on any volume within that device.
Example encrypted device missing the discard option:
dmsetup table --showkeys
cr_ata-XXX-YYY-partZ /dev/disk/by-id/ata-XXX-YYY-partZ: 0 12345 crypt aes-xts-plain64 XXYYZZ 0 8:3 4096

Assuming you've encrypted root ("/") we'll check if the fstrim command
works:
fstrim / /: 185.6 MiB (194564096 bytes) trimmed
If there's stdout indicating there's some number of bytes being
trimmed, it's working.

My take on this is that the SSD encryption risks are quite different as a function of whether TRIM is used or not.
Keep in mind that there will be other variables depending upon which SSD manufacturer, model, and interface.
Personally I'm inclined to stick with an HDD for encryption and avoid the issue entirely.
Thanks for the question, I learned some new things!


How important is patch management? Problem

I'm trying to sell the idea of organizational patch/update management and antivirus management to my superiors. Thus far, my proposition has been met with two responses:

We haven't had any issues yet (I would add that we know of)
We just don't think it's that big of a risk.

Question

Are there any resources available that can help me sell this idea?

I've been told that 55-85% of all security related issues can be resolved by proper anti-virus and patch/update management but the individual that told me couldn't substantiate the claim. Can it be substantiated?

Additional Information

1/5 of our computers (the ones on the building) have Windows update turned on by default and anti-virus installed. 4/5 of our computers are outside corporate and the users currently have full control over anti-virus and Windows updates (I know this is an issue, one step at a time).

The claim can be substantiated by checking the successful exploit rates against (e.g.) Secunia databases, or by checking the latest, say, 100 security advisories from Microsoft TechNet (the management loves Microsoft sources :-) ) or e.g. US-CERT.

Every time there's an exploit for something that was known at the time the exploit took place, that's a vulnerability that patching would have avoided.

A very effective display can be done by installing Secunia Personal on any given computer.

You will almost certainly (I'm not kidding you!) find several vulnerabilities:

that can be exploited by a crafted email. That is: every mail they receive could potentially contain the exploit.
that can be exploited remotely. That is: connect that laptop to the hotel's WiFi, and more often than not the occupant of any nearby room (in case of workshops abroad, very often a colleague or competitor) can pwn your laptop. Maybe they won't. But they could.
that can be exploited remotely on a server. That is: your web site might already be yours no longer. If it has a private area, and maybe sensitive document for the sales force... "How would you like it if some cracker were to leak this information to the highest bidder?".

Just explain to them in layman's terms what exactly a vulnerability that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system could mean for their business.


Freelance web app tester law on breach after scan If I was to do a web app test on a companies site and I didn't spot something and the company was breached via the app I tested what come back could I possibly have ?

How could I protect myself legally ?

Pentest reports should never give assurance. You can't state that a webapplication is secure, you can only state you didn't find anything or that you did find things. It's important you do not make yourself liable and that your contracts are waterproof as to ensure you do not imply that you guarantee the security of the application.


Can this bug on Tails Linux/Tor Browser be unsafe? I noticed some images only will be loaded if they are before cached.

That is, if I open the browser it won't load directly. But if I first load the image individually on the browser and later I open the site then it will load.
This happens for every page saved in my pc.

Here is a gif. I hope it explain better:

Any risk if I keep using Tor Browser?

That is not a bug.

This is part of a temporary fix for an IP leak vulnerability discovered in Firefox related to its file:// handling. See the blog post and the bug on the bug tracker. The behavior was added in 7.0.9 and will likely be changed to a more complete fix when the vulnerability is made public. Until then, the behavior you are seeing is a stop-gap measure to protect from IP leaks.

This temporary mitigation works by blocking embedded resources in resources loaded from your filesystem, while still permitting loading a resource directly. In fact, their temporary solution for the inability to click links is to load the link directly. This is what you are seeing. An embedded image does not load, but when it is opened directly by itself, it displays fine.


Best Way to hash passwords in database We have a user table where we store the user passwords. Now what we do is that we have a static salt, that we append to plaintext password and do a SHA-256 of the complete text and store in DB.
We have created this approach 5 yrs back. But now with so much computing power, is it safe to use SHA-256(With the approach I mentioned).
Or should I use any other approach? like HMAC? or anything else

I had to do exactly this same migration some months ago on a production database.
We did that in two steps.

we added an extra password column that would contain the PKDBF2 hash in Crypt format
then we modified the login logic so that when a user logged in (and we received their plaintext password), if the PKDBF2 field was not NULL, the routine would verify against that. Otherwise, it would check against the old hash column, and - if the plaintext hash matched - insert the information into the PKDBF2 field.

Our users did not notice anything. After maybe a week we also sent a mailing to customers that had not an updated PKDBF2 hash requesting they log in, and update their information while they were at it.
What was noticed was that we also added updated password  strength checks (if your password was not strong enough, or its hash had leaked and was available on online databases, a warning would be given and a password change was strongly suggested. If the password was not policy compliant, the change was not an option). Due to a mistake, the checks were added later, so the most assiduous users were able to slip by a potentially unsecure password. Nonetheless, they got hit with the update at the next mandatory password change six months later... the last ones are being processed now, I think.
After, if I recall correctly, six or seven weeks, at the end of July, about 70% of our customers were updated. At that point the logic was changed again and the old hash was disabled, the column dropped. People trying to log received a message that their password was not correct, or had been obsoleted, and they needed to apply for the "Recover password" button.
Then about 10% of customers, more or less, turned out to be "dead" -- they are currently scheduled for removal in accordance with privacy regulations. Those with no business recorded were deleted immediately.


Dom xss posibility question? I have this snippet of code :

<script type="text/javascript">
        $.extend({
                getUrlVars : function() {
                        var vars = [], hash;
                        var hashes = window.location.href.slice(
                                        window.location.href.indexOf('?') + 1).split('&');
                        for ( var i = 0; i < hashes.length; i++) {
                                hash = hashes[i].split('=');
                                vars.push(hash[0]);
                                vars[hash[0]] = hash[1];
                        }
                        return vars;
                },
                getUrlVar : function(name) {
                        return $.getUrlVars()[name];
                }
        });

        $(document).ready(function() {
                //Getting URL var by its nam
                var langVal = $.getUrlVar('lang');
                $('#lang').val(langVal);
        });
</script>

And I want to know , how secure it is.Is there any danger of dom xss and if yes , then how?
Thanks

In its current state, your code doesn't have a DOM XSS vunerability. $.val sets the value of a form element, which cannot be used to inject JavaScript code into a website.

The innerHTML property or document.write are examples for methods that are vulnerable to DOM based XSS.

You should read up on this topic on the OWASP website. There's also a talk here about this topic (if I recall correctly, it was mostly about a tool to detect DOM based XSS, but also has an introduction to the topic).


securely and conveniently transfer a single file from a desktop to a mobile computer I posted this question on "Software Recommendations" previously. I think that my security concerns will be better addressed here.

I am searching for a convenient way to securely transfer a single file from a desktop computer C_D to a mobile computer C_M. C_D runs Linux, C_M runs Android.

A method is secure if a file does not leak to a third party ("confidential") and computers see only the transferred file and nothing more ("least privilege").

A convenient way requires only simple configuration. The file transfer usually is the first and last transfer between C_D and C_M, and a complex configuration process would not pay off. The ideal "configuration process" is when I pick a file and select a connector which the other computer is connected to. Let's denote this requirement as "convenient".

What I thought up so far. An important fact to keep in mind is that to make a transfer "confidential", I need to make sure that the computer I connect to is not a computer belonging to a malicious person standing few meters aside. I can do this by manually typing a password, but typing a password is not "convenient". I can do this by connecting the computers with a "visible" link, for example, a cable. Transfer schemes follow.

Radio (wireless) link. For example, Wi-Fi, Bluetooth. It is not shielded, so it is not "confidential" without typing a password.
Optical link.
2.1. Infrared communication is not shielded, so it is not "confidential" too.
2.2. A video camera of one computer pointed to the screen of the other one. I guess that it is more "confidential" than the previous scheme. I don't like that the screen is visible to bystanders. QR Code is an implementation of this scheme for small files.
2.3. A light emitter of one computer inserted into a hole with a light sensor in the other computer, and the gap where the light may escape is covered by rubber. It can be manufactured, but I never heard of such technology in consumer electronics.
Cable.
3.1. Ethernet. It is present in almost every device nowadays which is "convenient". It requires configuring a network server of some sort (for example, FTP, HTTP), which is not "convenient".
3.1.1. LAN. As I said, it is very likely that C_D and C_M were never connected before, so a LAN would require a configuration. Low on "convenient". Note that this LAN must be isolated from other networks, otherwise the scheme is not "confidential".
3.1.2. Internet. Is not "confidential" unless a network server is protected by a password. Take into account that at least one computer, probably both have no global IP addresses.
3.2. USB.
3.2.1. C_M serves as a MTP storage over USB. I discovered that even the internal flash memory of C_M is accessible. Contradicts "least privilege".
3.2.2. I suppose that other protocols over USB exist, but I never heard of any one that fits.
Moving a flash memory device between A and B. Wiping the whole partition containing the file by the Unix program "shred" satisfies "confidential". Low on "convenient". For example, I discovered a smartphone where you need to disconnect a battery in order to change a microSD card.

Final thoughts. I did not expect this task to be such a hassle. A solution suggested on "Software Recommendations" requires that I write a script that starts a FTP server to transfer big files. OMG.

There's various android apps that support SSH/SCP/SFTP. Since that is encrypted, you'd be on the safe side. Very likely, your favourite third-Party File Explorer does that already. You can, also, install an SSH server on the android phone and go the other way around. SSH will allow you to verify the fingerprint of the other side's cryptographical authenticity. So no man-in-the-middling. That was easy!

Of course, these connections depend on networking, but considering you can usually use Bluetooth to tether and thus, set up a network, that should universally work – both locally as well as over the internet.

  Radio (wireless) link. For example, Wi-Fi, Bluetooth. It is not shielded, so it is not "confidential" without typing a password.

I won't be going into security of wireless links here, but it's not universally true that those are unencrypted. Still, your desire for confidentiality is warranted, since an access point has to decrypt the over-the-air traffic.

No communication in this world is "shielded", by the way, aside from quantum cryptographically secured connections. The word your looking for is "easy to eavesdrop".

  Optical link. 2.1. Infrared communication is not shielded, so it is not "confidential" too.

... and you show me the pair of devices that still have infrared transceivers in 2016....

  2.2. A video camera of one computer pointed to the screen of the other one. I guess that it is more "confidential" than the previous scheme.

It's certainly not. Optics of cameras have a minimal focal length, and since the speed of this method would be pretty low, and you don't want to dedicate both your C_M and C_D for hours to copying files, you'll be creating larger loopholes for people that want to sniff.

  I don't like that the screen is visible to bystanders. QR Code is an implementation of this scheme for small files.

exactly.

  2.3. A light emitter of one computer inserted into a hole with a light sensor in the other computer, and the gap where the light may escape is covered by rubber.

That sounds like you'd actually want fiberoptic networking :)

  It can be manufactured, but I never heard of such technology in consumer electronics.

Depends on what you'd consider "consumer". SFP PCIe cards and SFP 1000Base-SX transceivers can be bought used for very little money nowadays, but it'll be hard to attach those to a smartphone.

If you want to use a screen or the flash LED of your smart phone: Screens have an update rate of let's say 60 Hz. Let's assume you can code 8 bit each time – then you get 60B/s. That'll be extremely slow.

  Cable. 3.1. Ethernet. It is present in almost every device nowadays which is "convenient". It requires configuring a network server of some sort (for example, FTP, HTTP), which is not "convenient".

Aside from your linux system making it extremely convenient to have such. As mentioned faaar above, SSH is available on any linux distro as standard package, and will let cryptographically and/or password-authenticated users access your computer or transfer files. totally convenient.

  3.1.1. LAN. As I said, it is very likely that C_D and C_M were never connected before, so a LAN would require a configuration. Low on "convenient".

Yawn. That'd be true in 1996... nowadays, we have Bonjour/avahi/Windows Networking... things work out of the box as soon as you're on the same network, and you only have to care about configuring either side to use something well-encrypted. For example, many chat clients can be used with end-to-end encryption, and there's Bonjour auto-detection built into clients like Pidgin.IM and so on.

  Note that this LAN must be isolated from other networks, otherwise the scheme is not "confidential".

encryption. It doesn't cost you anything. this is not the early 1980s.

  3.1.2. Internet. Is not "confidential" unless a network server is protected by a password. Take into account that at least one computer, probably both have no global IP addresses.

Whatever applies to network in general applies to internet, too.  You wouldn't want unencrypted file transfers even in a LAN.

  3.2. USB. 3.2.1. C_M serves as a MTP storage over USB. I discovered that even the internal flash memory of C_M is accessible. Contradicts "least privilege".

That's something that you should be able to modify if you roll your own Android. However, I don't know of a single case where access restriction has been implemented – there's simply little demand. Also, plugging your phone directly into a foreign PC is practically the most physical access one can get – the "holy grail" of security loss.

  3.2.2. I suppose that other protocols over USB exist, but I never heard of any one that fits.

Networking! Simply emulate a network interface. Android phones call that mode "USB tethering". Then run a chat client, an SSH client, an SSH server, an FTPS server, whatever you like.

all in all, it feels like you've never heard of encryption, which is the ubiquitous and simple solution to your problem.

Frankly, I'd just take my files, encrypt them, and send them via email (if small enough) or just use encrypted email (there's good email clients for both Linux and Android that support PGP).

If the files were to large to be sent via email, I'd really just push them encryptedly via any other method – probably simply via Bluetooth, or as a file dropped onto a network share. Don't act as if those are hard to set up – in fact, with most linux distros, it should be pretty easy to just share a folder.


Notifying Website w/Security Hole As a hobby, I find security holes ranging from XSS to SQLi to LFI etc in random websites I find. (I don't exploit them). I've decided to to do a little more; I want to create a volunteer group composed of hackers who will find holes and report them to the website.

I'm finding two "issues":

Although I don't exploit the holes, could I get in legal trouble for reporting the hole to the website?
Where could I find fellow non-malicious hackers?

The group would be entirely volunteer based and would be completely non-malicious.We would not take on clients or do tests on request. Sites would be entirely random; no specific sites would be targeted and the test would be conducted without the site's consent or knowledge. If a hole is found, the site is notified. If not, we would move on.

Should I be concerned about anything else?

I apologize if this is the wrong site to ask, but I have no idea where to go...

You could read the latest IT Security's blog post which talks about a similar topic. It's a interesting read and you might find some answers, even if your scenario and the one they are analyzing are a bit different.

The point is, there are many possible consequences to bear in mind when hacking a website that requests to be hacked, if you want to hack a website that doesn't request to be hacked and then notify them, you should probably be even more careful.

Of course, I am no lawyer, so for any more specific questions I suggest you to talk to one.


Can I detect web app attacks by viewing my Apache log file? I occasionally get clients requesting I look at their access_log file to determine if any web attacks were successful.  What tools are helpful to discern attacks?

Yes you can, apache log gives you information about people who visited your website including bots and spiders.
patterns you can check:

someone made multiple requests in less than second or accepted time frame.
accessed secure or login page multiple times in a one minute window.
accessed non existent pages using different query parameters or path.

apache scalp http://code.google.com/p/apache-scalp/ is very good at doing all the above things


unravelling of https sessions by corporate web proxies? Like many people I work within a company that deals with internet access of its employees by providing a proxy server.

Although i got the idea that a https session encrypts, from peer to peer, all the traffic between my browser and the server at the end, I have been told by one of our sysadmin that all my https connections are somehow « deconstructed » or « unravelled » by the corporate ssl proxy. And, by this way, consequently, my employer could easily see and read all my web access including all my https sessions.

Is it true?  °_°

While I can't say if it it is exactly true in your situation, it is definitely possible and probably likely given your IT guy said it is.

A guess would be all machines in your network have a trusted certificate installed that allows your corporate proxy to MitM your TLS connections. Essentially, you are connecting to the proxy securely and since you trust the proxy's certificate it doesn't alert you. The proxy then connects to the outside normally.

Reasons this is useful to the company are substantial. They can now be aware of ALL traffic passing through their network and it makes it easier to spot malicious activity. That or otherwise unauthorized activity (porn, drugs, etc.).

This question comes up a lot in regards to privacy. Just remember the company OWNS the network. Don't browse personally on it.


Security risks using tmpfile() for sensitive data in PHP What are the primary concerns when storing sensitive data in PHP's temporary directory via tmpfile()? For instance:

Could this data be recovered from HDD by a malicious admin?
Could the admin easily change the tmp directory to a permanent storage location?
Could the data be easily copied to another location during the initial write process?

My web application stores encrypted user data, but I have to encrypt it so that it can be streamed over webdav. Storing a decrypted copy temporarily seems the easiest approach. Otherwise I may have to invent some block based encryption and decrypt data on-the-fly.

The data must be assumed to be flushed when it is written to a file. In theory it might stay in the buffers and never be flushed, but you can't rely on that and you have no way to tell if it did. The temporary file location might be a RAM-mounted disk (like tmpfs in Linux), but you probably don't have access to that information and, again, you can't rely on that being the case. The worst-case (and most likely ) scenario is that it is written to the hard disk, in which case anyone with raw disk read privileges, like the admin, could then search through the raw sectors of the hard drive and examine the data. This isn't as hard as it sounds, I've recovered deleted text files before using a simple chaining of the NIX tools dd and grep.
I don't think that's an issue. The file created from tmpfile() should be auto-deleted when you close the file, regardless of where it was created. (At least, so says the manual and experience.)
Sure. The admin could monitor the temporary directory and makes a copy of any file he sees created. This should be doable at the user-mode level, and it is certainly doable at the driver level (if they wrote a file-stealing driver and put it in the filesystem stack) if they are very dedicated to swiping every temp file.

As a rule of thumb, any data that needs to be encrypted should not be written to a file unencrypted. File contents aren't under your direct control, and unencrypted data needs to be.

Encryption should be possible on-the-fly with standard encryption schemes. It might be a bit more complicated than doing one big encryption call, but it should definitely be possible using any competent encryption library.


How Should WiFi Passwords be securely stored on IOT (embedded) devices? Some devices need to store and (re)use a password (not the hash) like your mobile phone using home wifi, SmartTV, etc;

How should they store the password on their flash storage? So that a person who has physical access to the chip can not retrieve it?

If the PKI method is used, then the private key also needs to be around for the device in order to decrypt the password and use it to join the network. And that private suffers from the same problem.

Also, having some kind of master key means that once one device's master key is read, then all devices data can be encrypted using the master key.

How is this commonly implemented at present and ideally how should it be?

For Windows 7 and above, Microsoft enabled Protected Processes via the RunAsPPL=1 registry change. This protects the LSA from being dumped by even the SYSTEM account. The LSA (lsass.exe process) contains secrets including the WiFi keys and the machine credentials. In order to access these secrets again, the current-logged-in user must have his or her screen locked and unlocked, logged out and back in, or the machine rebooted followed by a successful login. I have tested and verified that tools such as WirelessKeyView will not work when lsass is protected in this way.

This sort of protection is still provided in software (and can be bypassed through kernel or driverspace technology, which has even been seen in the wild with malware such as Uroburos) -- but it is sufficient for many environments and certainly much better than no protection at all. For a hardware equivalent, many are looking at Intel SGX to provide a secure enclave. If the IoT manufacturers can leverage Intel SGX, or a similar technology, then that would be the best location to store shared secrets, such as WiFi passwords, credentials, and cryptographic key material.

N.B., part of this discussion was taken from a talk given by Thomas Dullien of Google -- http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-he-is-compromised -- https://www.youtube.com/watch?v=kG2sISGNZmk


Stream/Block encryption using XOR and Hash function? Could a hash function like sha1 or ripemd-160 be used for secure key generation in a stream/block cipher? Obviously a repeated key like "abc123abc123abc123" would be bad, and a one time key pad would be impractical for large data... but what if one used a hash function to derive new keys from the origional password like:

DUMMY CODE:

$password = "secure password here!";
$round =0;
while(true){
$key = sha1($password . $round);
$data = READ 40 BYTES OF DATA HERE
$result .= XOR($data,$key);
$round++;
}

Not that i am going to use this for anything, but just curious, what would be secure/insecure about this method... thanks...

There are definitely problems with this scheme.  First, it seems to be deterministic -- every time you encrypt a new stream with the same password it starts with $round=0.  Thus your stream is like a one-time-pad that's being used repeatedly -- the many time pad which is easily attackable by XORing encrypted streams together and exploiting patterns in underlying plaintext.  Granted, this could be easily fixed by doing something like $round = generate_random_80_bit_number() and then appending this 80-bit number to the start of your ciphertext.

I'm somewhat worried about the cryptographic hash functions being based on a Merkle-Damgard construction which are susceptible to extension attacks.  The reason HMAC isn't H(K ++ m), but H(K1 ++ H(K2 ++ m)).  I haven't fully worked out the details on how to exploit your scheme having sequential round numbers, but could imagine attacks on the MD construction and using sequential rounds appended to the end of a common prefix.


Using SSL-port (443) for non-SSL traffic, bad idea? We have a webapp that is build to use SSL for certain (but not all) types of requests. The webapp is using multiple subdomains, the number can change. This combination of features makes that the webapp requires a wildcard SSL certificate.

The webapp is used by some people, but not by a whole lot of them. We would like to keep the webapp running for those who use it, but has been determined that, at this point in time, it is not economically justifiable to pay for the wildcard certificate.

Since the webapp has no build-in method to drop the SSL-requirement (or more precisely, the webapp expects 'SSL-traffic' to be comming in through a separate vhost listening to the same subdomain), I thought that the easiest solution would be to just disable the SSL and keep (unecrypted) traffic running over port 443.

My big question is:is it a bad idea to run non-SSL traffic over port 443 (and why)?

That doesn't sound terribly easy to me.  Clients (and I assume we're talking about browsers here) expect http traffic to be served over port 80, and https traffic over 443.  In order to change this to http over 443, that's going to require that you change your URL scheme to http, and then explicitly specify the port on each URL.

So, for an https URL like this:  https://example.com/some-resource you will have to change it to: http://example.com:443/some-resource.

It seems to me that if you want to remove the SSL requirement, it would be easier to leave http running on port 80 so the only change you have to make to your URLs would be to remove the s from the scheme.

If you're wondering if you can serve http traffic directly to a client that is making an https request, allowing you to leave the URL the same, no, that should not work.   The client is going to try to initiate a TLS handshake and when it doesn't get a TLS response, the connection will fail.


Can a Meta Tag be Spoofed? (Is a Metatag Sufficient to Declare a Page is Protected?) Background
I am working as a front-end developer, and I have very little security experience. We are working with a very obscure backend setup, using a 4D database and WebClerk on top of it.
WebClerk allows for logged in users. All pages are actual .html pages, with specific WebClerk code which is processed on pageload (similar to PHP). To tell if a page is protected, it uses a custom meta tag in the head. When the page is being read in by the server, it checks to see if the security meta tag exists, and if so, does a logged in check, and then pushes over to an error page if not.
Question
Is a meta tag secure? Can it be spoofed?

Anything provided by the client to the server can be altered by the client, including any HTML content/tags.

Look at products like Burp Proxy to give you an idea about the power available to the client. It allows you to manually intercept responses then inspect and edit them before sending. It's a very common tool for hackers (and security pros) to use.


As a student, how do I safely and responsibly disclose a serious security issue in a school environment? I am a student at my local school.

About eight months ago, I stumbled upon a security hole that could allow any user to discover any student's ID in the entire district, and I am aware that the IT department has a tendency to keep student IDs as confidential as possible as the ID is the only unique identifier bound to a student.

When I originally found the problem, I was suggested by my computer science teacher to just lay low and not report it to anybody. However, eight months have passed, the IT department has not done anything to fix this issue.

I have finally built up the courage to responsibly disclose the security issue to management. The reason I have feared reporting is that I must tread very carefully, as one wrong step could land me in hot waters and possibly suspended for "hacking." And at this point, I have no idea who else has found this exploit other than myself.

Again, I was not actively searching for security holes; rather, I simply stumbled upon one.

What is the best course of action to take in responsibly disclosing the security issue while minimizing the risk of being punished for it?

I have many years experience working within a college ICT team. This is what I would recommend based on my experience.

I wouldn't go to management, they won't care or a non-technical manager will overreact and take the issue on as a personal mission. Additionally if you are worried about being accused of 'hacking' it is non-technical management who are most likely to do that.

I would recommend documenting the security flaw and submitting it to the ICT service desk.

If you do not have access to the service desk as a student, then email them directly or just chap the door of the office and explain the situation to them and they will advise you on how to proceed. (Chapping the door is probably the best option) They will probably just raise a ticket for a technician to have a look at the issue, it will go through the escalation procedures from there.

Do not be worried about about bringing this issue up with them, even if it turns out to be nothing, most teams will be happy for the proactive reporting of these kind of flaws. From experience I can say that most in academia be it support staff or academic staff only raise faults with ICT when it affects them personally.

I have discovered faults in the past, only for a member of staff to tell me that the fault in question has been there for months. My response was always the same, "Well why didn't you raise a ticket with ICT to fix it?"


Change ettercap default port Guys does anyone know how I can change the port that ettercap runs?  I need it to run on port 8080.
When I try to run sudo ettercap -G it presents me with this error:
ERROR : 13, Permission denied
[/build/ettercap-gsX8lN/ettercap-0.8.3.1/src/ec_capture.c:capture_getifs:114]

Can't open raw Bluetooth socket: Permission denied

Being that I have root, as a solution I thought of changing the default ettercap port, does anyone know how to do this?

I am assuming that you are using Kali or another Debian based distro. All of ettercap's config files are found in /etc/ettercap/ by default. However your question does not expand on what would be running on 8080. ettercap is a network layer recon and exploitation tool. It doesn't really run an application on a certain port. If you are trying to redirect traffic to a web service running on port 8080 that would be another issue. If purely launching the graphical interface is giving you the issue above, you need to add sudo to the beginning of your command or give privileges to your current user to run ettercap by using groups and such. Please explain your issue in more depth.


Theoretical DKIM Question I have been playing around with sending emails via telnet using text commands.

Theoretically...

Say I send an email from a typical mail agent that adds a dkim signature from a@a.com to b@b.com.

If I grab the message source (just including the headers listed in the DKIM-Signature header and the body)  from b@b.com and send it as the "data" of a telnet session email from a@a.com to b@b.com, should the dkim pass?  Or is there some mechanism that stops an email in dkim that stops an email from being sent twice with the same exact headers & body?

In DKIM the senders MTA signs the message and some headers using a private key only known to this MTA. The signature was explicitly designed to survive redistribution of the unmodified mail.  This kind of redistribution is what you are doing with telnet.

In other words: the DKIM signature is specific to the mail itself and not specific to the process of sending the mail. This is different from SPF which cares about the actual process of delivery only by checking the senders IP address against the claimed sender in the SMTP envelope but does not care about the actual content of the mail.


Will it matter if I give to someone the IMEI or Serial number of my device? Just as the title says, if I have for example a pocket wifi will it matter if I give the IMEI or serial number to someone who ask for it? Or maybe a crucial device that can affect your health like implantable medical devices?

It is because I've watched a movie before and it involves a person providing the serial number (Am not sure) to the hacker, and the hacker because he knows the serial number of the pacemaker (Am not sure again) he is able to stop the heartbeat of the person.

Knowing the serial number of a pacemaker won't allow you to magically stop it.

Now, the IMEI is sometimes used for things it shouldn't really be used like authenticating you on WhatsApp (a weakness of the app). Thus, it's not recommended to go around publishing it (OTOH for instance the manufacturer will require you to provide it before giving support…).


Full Disk Encryption with random keys TrueCrypt encrypts and decrypts a disk with a password which is converted into a pseudo-random key with the PBKDF2 function.

Other FDE programs use random keys that are stored on the disk. Where exactly are these random keys stored? They have to be accessible after the computer starts and before the OS is loaded in order to decrypt the disk.

The random keys are encrypted and can be decrypted with the password that the user chose. Why are random keys used for FDE? If someone is able to get the password, the hacker would get the cipher key anyway. There would be no difference between random keys and pseudo-random keys.

In full-disk encryption you usually have a key hierarchy. A Key Encryption Key (KEK) is derived from a user password, as you stated often this is done using PBKDF2 (alternatively nowadays more preferred is scrypt). The KEK then is used to encrypt the Disk Encryption Key (DEK) which is actually used to encrypt the storage media.

I am not entirely sure if TrueCrypt really uses the password derived key to encrypt the disk. However, coming to your first question: Where exactly are these random keys stored? Every FDE solution has one tiny part of the disk which is not encrypted and where the DEK is stored in a secure manner (encrypted, see process above). This is the reason why attacks such as the Evil-Maid can work. On boot, the system needs to start a minimal environment which prompts the user for his password, derive the KEK and decrypt the DEK. It then checks whether the DEK is actually correct (probably by decrypting a fixed known pattern). If so, the disk decryption starts and the system continues its boot procedure.

Your next question: Why are random keys used for FDE? Imagine you don't use random keys and instead a fixed-pattern-key that for example is time based. An attacker only has to identify the appropriate setup time and can reduce the amount of keys to brute-force largely!

  If someone is able to get the password, the hacker would get the cipher key anyway.

That is true, this is why we need strong passwords, strong cryptographic primitives to derive the keys from them and strong keys that encrypt the disk. The first two are essentially to make brute-forcing the KEK take as long as possible. An attacker will eventually be successful, after all it's a brute-force. However, we want him to not even try because it would take far too long and the information stored on it by then probably outdated and worthless. Alternatively we include penalizing actions, i.e. an increasing timeout on false password entry, or a forced wipe after a specific number of tries.

The key encrypting the media must be random and hard to brute-force, as otherwise an attacker could easily target that key instead of the KEK derivation process that is designed to be slow.


How can we beef the security of our Windows Server 2012 R2 against ransomware? We have a MS Windows Server 2012 installed. After the attacks of last week, I was wondering how we could improve the security of the server against ransomware/cryptoware.

We did install the latest updates from Microsoft.

What else can we do?

The basics for protection against ransomware is :

Update frequently (OS, AntiVirus, ...)
Don't open phishing / infected emails which usually convey the ransomware (user awareness)
Backup, backup, backup (and check them!)

The majority of the ransomware risk is cancelled by a proper backup strategy. If your data are safe in some offline place, they can crypt whatever they want. It's surely a hindrance to go through the restore procedure, but it does not cost more.

Some basic techniques might also help, email filters, macros scanning/disabling, using a least privilege policy for your user.


inherent drawbacks of browser based OTP solutions? We already have two sorts of OTP generators in place: (a) as hardware (token) (b) as software (e.g. Google authenticator, RedHats freeOTP)
Now I saw browser based solutions like SecureAuth OTP which is available as Chrome app. [ <- correction, thanks JulianKnight for the hint ]

Are there any inherent drawbacks or risks having the otp creation within a browser, as opposed to the above mentioned solutions?

There are some potential additional risks from using a browser-based tool.

The main one probably being the security of the storage - where are the OTP settings stored and how secure is that.

The second being that browsers are already quite complex and so may have vulnerabilities over and above a bespoke tool.

Without a doubt, generally hardware tokens are considered more secure as they tend to be very heavily tested. Though there have been some notable failures of course and that requires recall and reissue.

Software tokens are always likely to be only as secure as the platform that hosts them so you should bear that in mind too.


Why do I see "Secret key is available." in gpg when it is not? My master key is offline and I have subkeys on a Yubikey.
As expected, I see sec# when listing keys when using the online system:

gpg -K
sec#  4096R/2FFA7695 2016-02-01 [expires: 2020-01-31]
uid                  NAME <EMAIL@ADDRESS.COM>
ssb>  2048R/EA7CCF1B 2016-02-01
ssb>  2048R/1E8DA9B9 2016-02-01
ssb>  2048R/5BA60C24 2016-02-01

However, when I go into edit mode, gpg indicates that the Secret is available:

gpg --edit-key 2FFA7695
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/2FFA7695  created: 2016-02-01  expires: 2020-01-31  usage: C
                     trust: ultimate      validity: ultimate
sub  2048R/EA7CCF1B  created: 2016-02-01  expires: 2018-01-31  usage: S
sub  2048R/1E8DA9B9  created: 2016-02-01  expires: 2018-01-31  usage: E
sub  2048R/5BA60C24  created: 2016-02-01  expires: 2018-01-31  usage: A
[ultimate] (1). NAME <EMAIL@ADDRESS.COM>
[ultimate] (2)  [jpeg image of size 1234]

gpg>

Tested with several recent versions of GnuPG.
Am I misunderstanding this message?
Is this just another example of gpg's horrible UI or a bug?

Tested with several recent versions of GnuPG. Am I misunderstanding this message? Is this just another example of gpg's horrible UI or a bug?

GnuPG isn't completely wrong here, a secret key stub is well available for all of the keys (the # in sec# indicates a key stub, as the > in ssb> indicate keys on smart cards).

But you're also right with the "horrible UI", and this can very well be considered a bug. There will be valid technical reasons GnuPG assumes the key to be available internally -- but it shouldn't reveal this misinformation to the user. I might have agreed with printing such a line for card keys (well, those keys are somewhat available), but not if only the (useless) private primary key stub of an offline copy exists -- you cannot do anything with it anyway. Better only pay attention to gpg -K's output, which has (as described above) a far better indication what exactly is available.

I even removed all subkeys for a test (and only the primary secret key stub remaining available), the same message is still printed (and there is no way to make the key stub available). In fact, addkey will fail with a message of the key not being available:

Secret key is available.

pub  8192R/0x4E1F799AA4FF2279  created: 2012-12-25  expires: never    usage: SC
                               trust: ultimate      validity: ultimate
[list of UIDs, no subkeys]

gpg> addkey
Secret parts of primary key are not available.
gpg: Key generation failed: secret key not available


Custom publickey authentication I'm working on a REST account management system over https that should support both username/password and username/publickey authentication schemes. I.e. when a user registers an account, they may chose to additionally upload their ssh public key; all subsequent requests would then not require a password anymore.

I wouldn't want to depend on the server having a filesystem for OpenSSH to store its keys on - this is why I can't simply have sshd running and have it deal with auth.

So, the plan is for the client to sign some message using the user's private key (i.e. openssl dgst -sha256 -sign ~/.ssh/id_rsa ...). The server, having the client's public key, would then verify that the expected message is correctly signed.

The question is now, what to sign? As far as I understand, OpenSSH uses a session identifier, which among others is based on the computed shared secret between the client and the server.

I don't want to invent my own crypto, so I was wondering if I could reuse the https connection shared secret for that. Or is this already considered "inventing my own crypto"?

The thing you want to guarantee here is freshness, so having the client sign some nonce - any nonce, as long as it's fresh - will work. Ideally, that signature should also be bound to the channel, but the signature and nonce are being transmitted inside the encrypted channel, so maybe that's enough.

Ideally, though, you're right, signing the TLS shared secret would accomplish both. I'm just not sure how easy that is to actually implement.

Using TLS client authentication would be better still, because TLS does all of this for you. Client certificates would be my first choice, but if you're hell-bent on using SSH keys, TLS raw public key authentication might do the trick.


Does the random presence of a common password sequence within a larger password weaken the password? I have a somewhat basic understanding of how entropy relates to password strength - generating a password with a truly random selection from some set (whether that's characters, or a set of dictionary words, or whatever else) gives increasing entropy as either the size of the set and/or the number of selections increases.
But in some cases, simply generating a password with a certain entropy doesn't result in a password that's strong 'in the real world'. For example, let's say I want to randomly generate a password that's 8 characters long. I take a truly random selection from the set of all uppercase and lowercase letters, numbers, and special characters, and the result I get is:
password

That's just as likely as any other output from a random selection, and assuming a valid generation it has the same entropy as something like '@gm%Kj$9'. Despite that, it's clearly not suitable for use as a password, as any even remotely competent malicious actor would be into the system almost immediately. Chances are a random person would pass that check on literally their first try.
It's clear that entropy alone can't necessarily be relied on for a strong password. My question, then, is how the random chance of generating common password strings within a longer password impacts the strength of that password against real-world attacks, using whatever techniques password crackers might commonly employ - or if it has any impact at all.
Let's say I realise that an 8 character password isn't that strong, and decide instead to generate a 16 character password using the same truly random generator with the same set. I have four systems I need to protect, so I generate four passwords (that will all be used, I'm not going to select from them again afterwards manually as that would influence the entropy). The four passwords I get are:
al#k2j$9gjKDm5%l
*g3RpasswordnG&4
password%G@fDnBv
Nf!hFm$xpassword

All four of these have the same entropy and are just as likely as the others to be returned from a truly random generator - however, three of them include the sequence 'password', which on it's own would be incredibly vulnerable. One has that sequence in the middle, one has it at the start, and one has it at the end.
Are any of these passwords more vulnerable to real-world attacks than the others, despite having the same entropy?
Note: I've looked at this similar question, however I think this is a slightly different case as we're not 'adding' a common password to the end of our randomly generated one.

If you're picking uppercase and lowercase letters uniformly at random, that's log2(52) = 5.7 bits per character, so 5.7 × 8 = 45.6 bits for an 8-character password. And the answer to the worry that you have a 2-45.6 chance of randomly choosing password (one in thirty-something trillion) is that you probably shouldn't worry too much that you have about a one in thirty-something trillion chance of picking password.
More generally, yes, there is a probability that random selection will, by chance, pick the very first password an attacker is likely to try, or the second, or the third, and so on. As long as we make that probability acceptably low this isn't something to worry about.
There's seven billion people in this planet, which is about 233. If each of them has a thousand passwords each—about 210—that's 233 × 210 = 243 passwords, and if they all do 8-char passwords from a 52 letter alphabet (45.6 bits) that'd mean there's something between a 1/4 and 1/8 chance that somebody will pick password at least once. That might be a reasonable argument against recommending 8 upper/lower letter passwords to humanity at large, but only because it's modestly likely one lone person in the whole wide world might be bit by one of a thousand random passwords they choose. (Well, actually it gets a bit worse once you consider longer password cracking dictionaries.)
8 upper/lower letters is cutting it much too close, though, because of computing power.


How does client verify the certificate provided by the server which is signed by different intermediate CA I am creating a c++ secure client-server application using openssl library. I am still not clear about some aspects of the SSLHandshake procedure

I have enabled Mutual TLS in-order verify the both the peers are trusted. I have 2 set of certificates and private keys. Both the sets have the same root certificate but different intermediate signers.

root CA ---> Intermediate CA1 ---->domain certificate1      (set 1)

root CA ---> Intermediate CA2 ---->domain certificate2      (set 2)

I have set the SSL_set_verify with VERIFY_PEER_CERT in both applications. I have not set the verification depth.

Server's call stack

Server gets the root CA and add it to the trusted certificate store
Server then get the PEM encoded certificate string in following format

  -----BEGIN CERTIFICATE-----
  Domain certificate 1
  -----END CERTIFICATE -----
  -----BEGIN CERTIFICATE-----
  Intermediate certificate by CA1
  -----END CERTIFICATE -----

 Server reads the Domain certificate 1 from the PEM string and call the SSL_CTX_use_certificate
 Server reads the Intermediate certificate from the string and add it to the extra_chain_certs using SSL_CTX_add_extra_chain_cert

3.Server loads the private key

Client's call stack

Client gets the root CA and add it to the trusted certificate store
Client then get the PEM encoded certificate string in following format

  -----BEGIN CERTIFICATE-----
  Domain certificate 2
  -----END CERTIFICATE -----
  -----BEGIN CERTIFICATE-----
  Intermediate certificate by CA2
  -----END CERTIFICATE -----

 Client reads the Domain certificate 2 from the PEM string and call the SSL_CTX_use_certificate
 Client reads the Intermediate certificate 2 from the string and add it to the extra_chain_certs using SSL_CTX_add_extra_chain_cert

3.Client loads the private key

Both parties will follow the SSLHandshake
I need some clarification on the following.

Will the client/server completes is certificate chain using trusted certs and extra certs?
During SSLHandshake what shall the peer present? Only the domain certificate or the whole chain?
Will the SSLHandshake succeed because peer's intermediate CA is not present in local certificate store?
Does only having the root CA in store enough to verify the certificate chain presented by the peer?
If I am to create multiple clients from the same application, can I use the same context initialized with set 2 to connect multiple servers which are signed by same root CA?

Will the client/server completes is certificate chain using trusted certs and extra certs?

Yes, SSL_CTX_use_certificate will load the certificate and SSL_CTX_add_extra_chain_cert will load the chain certificates and both are sent to the peer during the TLS handshake.

  During SSLHandshake what shall the peer present? Only the domain certificate or the whole chain?

Certificate and chain.

  Will the SSLHandshake succeed because peer's intermediate CA is not present in local certificate store?

Since the peer sends the chain certificates up to the trusted root it is not necessary to have the peers chain certificate known up front, i.e. the handshake will succeed without.

  Does only having the root CA in store enough to verify the certificate chain presented by the peer?

Yes, see last point.

  If I am to create multiple clients from the same application, can I use the same context initialized with set 2 to connect multiple servers which are signed by same root CA?

It is not really clear for me what this means. But the same context can be used for multiple peers, i.e. to create multiple TLS sessions.


Should we use different usernames for each website, to achieve better anonymity? I have big problems trying to remember different usernames for each site. Chrome remembers only passwords, so I should install a password manager, however it's crazy you have to do that in order to do something so  basic as different username for each site.

If you have same username each site, you are easily googleable and all your accounts can be linked and thus de-anonymised.

It's clear one should use different password for each site. How about usernames, is password manager the best solution? Can chrome do it by itself?

I am not sure about Chrome, but I have a feeling it was able to remember my username for most sites.

As for anonymity, it really depends on what you mean. Anonymity in the strictest meaning is actually a misnomer. To achieve anonymity, you could not select any username at all. Anonymity means not even two of your posts on the same site can be linked together. So you would not register at all.

Pseudonymity is when you have an identity for certain purpose, that can't be linked to your real identity. There are many "levels" of pseudonymity, you can have one pseudonym for everything on the internet, just not under your real name. You can have different pseudonym for each site or even each user you communicate with. The last one meaning if you send me two messages, I can tell both are from the same person, but if you send a message to my friend, we can't know, whether both were from the same person or not.

Whether you choose to be anonymous or pseoudonymous and at what "level" or type of pseudonymity depends entirely on what you are trying to achieve. Do you care that people can link the identities together? Are you worried you may leak your real identity or clues and you don't want that to "spread"? Do you want people to be able to recognize your username? It is up to you and your preference.


OCSP: What is "hackedirl.files.wordpress.com"? After I ticked that my browser (Firefox) must require OCSP:

I got a window pop up (several times! And it still pops up.. ~randomly ~about a few 10 minutes): http://i.stack.imgur.com/NYdoe.png

I didn't visit this site, nor any wordpress domain!

$ host -t any hackedirl.files.wordpress.com
hackedirl.files.wordpress.com is an alias for lb.files.wordpress.com.
$ host -t any lb.files.wordpress.com
lb.files.wordpress.com has address 72.233.2.56
lb.files.wordpress.com has address 72.233.69.13
lb.files.wordpress.com has address 72.233.104.107
lb.files.wordpress.com has address 72.233.127.222
lb.files.wordpress.com has address 74.200.243.250
lb.files.wordpress.com has address 74.200.244.58
lb.files.wordpress.com has address 74.200.247.35
lb.files.wordpress.com has address 74.200.247.186
lb.files.wordpress.com has address 76.74.254.118
lb.files.wordpress.com has address 76.74.254.122
lb.files.wordpress.com has address 76.74.255.116
lb.files.wordpress.com has address 76.74.255.122
$

Should I start thinking of a clean reinstall of my PC?

hackedirl means HackedIRL -> Hacked In Real Life

It is a name used by sites of the Cheezburger network (fail blog and others) - just a funny name, nothing to do with hacking.

The reason you see all these IPs is that Cheezburger network uses the wordpress platform for the content of its sites and wordpress does load balancing and redundancy using DNS.

Moreover, as this tool can verify that all the certificates of the multiple servers are fine.

hackedirl.files.wordpress.com uses the same certificate with all other wordpress sites, it is issued to *.files.wordpress.com. The OCSP responder mentioned in the certificate is

  Authority Information Access:
                  OCSP - URI:http://ocsp.godaddy.com/

The error you see means "The OCSP server experienced an internal error." as you can see here.

I don't know exactly why it fails for you, but a packet capture would be usefull. All is working fine here with that site and the OCSP request.

EDIT: Looked further into the source code, and here is what really happens:
This error will be presented if any of the following conditions holds true:

the http server session is not created, for whatever reason
the http client session is not created, for whatever reason
the http request with mime subtype "application/ocsp-request" is not made correctly
the response from the ocsp server is very large
the response has a flag set that says that it an internal error happened server side

So, my guess is that you have some connectivity problems of some sort, and you are unable to contact http://ocsp.godaddy.com/ successfully.


What security concerns should one bear in mind when hacking open-invitation websites? There's a couple other questions already addressing legalities, ethics, and liabilities of hacking websites with open invitations.

What are legal/ethical concerns to bear in mind, when hacking websites with open invitations?

I think I accidentally DoS'd a website. What should I do?

These got me to thinking:  How good of an idea is it, from a security standpoint, to be hacking these websites at all?  Sure, they offer a great potential learning opportunity for those who wish to exercise their skills.  But what threat could they pose to such individuals, many of whom may be playing with fires they do not yet fully understand?

Donning my tin-foil hat, some particular risks come to mind:

The site could be a honeypot, run by government or other entities looking to gather information about active (or would-be) hackers.
The site could be set up by a black-hat as a honeypot to gather a list of interesting, hackable amateurs to target.
A third-party black-hat could potentially access the site's logs and farm them for data about interesting, hackable amateurs to target.

Are these concerns realistic?  What's the likelihood that any or all of these could come true?  Are there other ways that one's own systems could be getting put at risk (from a standpoint of security compromise, not legal matters) when being used to hack these sites?

In what ways should one try to mitigate these risks?  What might be some good alternatives, if the risk is deemed too much?

They definitively can be honeypots. It's very interesting to know how people get in, so you can use the same techniques yourself or to identify them.

Some of these projects are just to learn more about security, but it is definitely plausible that these systems can get abused. After all they are meant to be vulnerable.

I did a similar like school-project where I faked an open sendmail relay and just piped all the incoming emails to a python script that got all the destinations out, generating my own spamlist. I think in the end after about 3 weeks I had close to 300.000 different email addresses.