How difficult is it to determine whether an account got hacked or why do games allow account recovery while refusing to lift bans for hackers' deeds? Many games and websites have an explicit policy that the owner of the account is fully responsible for any and all activity from that account and therefore suspensions will not be shortened or removed even if the activity the account was suspended for had been perpetrated by a hacker while he had been illegitimately accessing the account. (Wikipedia is among important exceptions here, though).

This opens up an attack vector to pemanently strip the legitimate account owner of their account. If a hacker simply changes the password of the account, the account may still be reclaimed by its legitimate owner with the help of the site or game's support. However, if the hacker purposefuly perpetrates a serious violation of the site or game's ToS and consequently the account gets permabanned, then the account owner will never be able to use this account again. Apparently, this does happen in practice (example 1, example 2).

What I find perplexing is that these same games, who refuse to lift bans issued for hackers' misdeeds, still provide facilities for account recovery. They even encourage to contact support if the standard recovery facilities (e-mail) fail (example: this vs this).

Therefore, may I have two questions?

Does the policy not to lift bans issued for hackers' behaviours arise from the difficulty of determining whether the account was indeed hacked?
If the above is true, is it more difficult to determine whether the account was used by its legitimate owner on a given occasion than who is the legitimate owner and whether its current user is the legimitate owner (since support does trouble itself with account recovery)?

BTW: Since I used the case of LoL to provide examples: A disclaimer to keep my conscience clear of an accidental misrepresentation of facts: I have feeling that regardless of the official policies LoL support sometimes does lift such bans, though I'm not certain of that.

Does the policy not to lift bans issued for hackers' behaviours arise from the difficulty of determining whether the account was indeed hacked?

Based on the log data a service like League of Legends is going to collect and store, it is impossible to distinguish between multiple users of a single account.

That's not the reason for the policy though. Policies like this get enacted because people like to externalize their problems and, more importantly, lie.

Someone guessed/obtained your password and used your account to test out hacks? Your negligence created problems for other players. The evidence suggests it was you. You can't prove it wasn't. You don't get to have an account if you can't be trusted to secure it.

With or without your consent, your say your brother used your account and went on a racist tirade in-game? That sucks, but damage was done. Even if you weren't the one doing it, you allowed it to happen, and there are consequences for this. You don't get to have an account if you're going to share it or leave it logged in on an unlocked workstation.

At the end of the day they're providing you credentials to their network to access a service they provide for commercial gain. If the provider determines you're more trouble than you're worth because your drama impacts their image or revenue, they're entirely within their rights to not let you participate. What's "fair" is not a factor in this equation. Justified or not, banning one problematic player costs less than giving them the chance to drive away other paying customers through cheating or spree trolling.

But these tales usually fall into one of two categories-- unverifiable or BS. Everybody lies. Cases like this or this or just about everything here are more indicative of what turns up when time is spent actually looking into it.

  If the above is true, is it more difficult to determine whether the account was used by its legitimate owner on a given occasion than who is the legitimate owner and whether its current user is the legimitate owner (since support does trouble itself with account recovery)?

It is impossible to distinguish legit owners from imposters; that's why shared accounts are generally banned on networks. One can try to make some educated guesses at best but it's still weak evidence that is easily falsified (just use a VPN when you want to do some trolling so the geodata doesn't match your established history, then claim it was a hacker). More trouble than it's worth. The ban button is just one click away.


Password relevance in key derivation function I'm questioning the password used in a key derivation function, whether It makes sense to make it unique for every generated symmetric key and why

Key Derivation functions like PBKDF, KDF1, and, HKDF can use a single password to derive a key. To derive an additional key with the same password the common approach is using info as in HKDF which has two steps.
Extract : HKDF-Extract(salt,IKM)->PRK
Expand: DF-Expand(PRK,info,L)->OKM,

IKM is the Input Key Material
OKM is the Output Keying Material
PRK is Pseudo Random Key

The Extract mechanism is important if the IKM is not good random material. The salt strength the PRK. For passwords, this is the case.
With the info one can derive multiple keys ( a python code is included). This is due to domain separation.
The bottleneck is the strength of the password. If one uses a good mechanism like diceware with good entropy then it is beyond attack.
Password-based key generation is usually used for file/volume encryption like Vercrypt or password managers. For end-to-end communication Diffie-Hellman key exchange is used mostly with the ECC version. The established( exchanged) key then used with a KDF to derive a symmetric key.
For encryption, one doesn't need to change a key often. Since there is a good mechanism to reuse a key, the IV/Nonce as in CBC and CTR mode. With the IV/nonce these modes can achieve the standard notion of security IND-CPA.
Therefore, theoretically once can use one good password to secure everything. Practically, this is not preferred. Separating the domains with multiple passwords is better in practice than in turn will require a password manager like keypass.


What are some ways to execute a reflected XSS attach I was wondering how many different methods exist for executing XSS attacks.

In just about every demonstration I see, the attack is triggered in one of the below 3 ways:

By entering the script into an input field. The front-end then uses that input to populate a request, which it is already designed to perform. The script input gets returned in the request's response and then gets executed if the front-end then adds it to the DOM.
By entering the request in the url bar. This works only with GET requests. If one of the parameters has a script for input and if the parameter is visible (as html) in the response the response page will execute it.
By providing an unwitting user with a link. If the user mistakenly clicks the link, they will inadvertently execute the process described in #2.

Are there any other ways it is done? Are there any resources that describe other ways of it happening?

Also, if the website uses session tokens for each login, is there anyway to get that token included using methods 2 and 3? Or do session tokens protect us from these approaches?

Point 1. is more of a (DOM-based) self-XSS issue. And as you said, point 2. and 3. are really the same (the attack happens by visiting a URL).

A GET request via a link is the most common way to execute an XSS attack. The link could for example be send to a victim via email or posted in a forum.

But there are other ways. The defining characteristic of reflected XSS is that input is reflected, meaning that the server takes some sort of value from a HTTP request, inserts it into a HTML context in the response, and the browser then renders that response, thus executing the injected code.

POST-based reflected XSS

Reflected XSS can also be performed via POST requests (which are not protected from CSRF).  Eg:

<form action="https://example.com/vulnerable" method="POST">
    <input type="hidden" name="number" value="[XSS payload]" />
</form>
<script>document.forms[0].submit();</script>

In the same manner, a GET request could be send via a form (by changing the method to GET). An attacker might choose this approach if a POST request is required, or if they think that it is more likely that a user visits a page where they can post scripts, and less likely that they will click on a link to the victim site.

Exploiting Self-XSS

Your point 1. might be exploitable if the site is frameable. Some browsers - eg Firefox last I checked - allow the dragging of text into iframes (not out of them though).

By performing a clickjacking attack, an attacker could get a victim to "enter" the XSS payload and execute it.

Another way to execute a self-XSS would be to simply ask the user to post the payload ("can you post this long, HTML formatted post [containing an XSS payload] to your website?", "Can you upload this harmless image [whose filename contains an XSS payload] to your blog?", etc).

Session tokens as (non-) protection

  do session tokens protect us from these approaches?

If your session tokens are always included in the URL, and the page doesn't reflected any input when the session token is missing (and the session token is securely generated), then that would indeed protect against (non-self) reflected XSS that send a victim a malicious link. In the same manner CSRF tokens protect requests against (non-self) reflected XSS.

However, now you have a new problem. Sensitive data in URLs is strongly discouraged. It can easily leak via referers, when users share links, etc. And once that happens, anyone could have access to that users account.


SSH key passphrase update and multiply locations I have a ssh key which I use to upload code to github. the private key is located on several locations from where I upload/download data.

I wonder how can I update (or expire) old keys after I update the passphrase on some of the locations.
I wish to avoid a split situation where some location use password X and the others are using password Y

Is that possible?

As noted in the comments, you seem to be misusing your private key.

Your private key should only be held locally. That is, on the hard drive of the computer you're currently sitting at.

You mentioned that

  the private key is located on several locations from where I upload/download data

I gather you connect to one of this servers, do some work, and then commit to github. You do not need to have your private key on the server in order to do this. What you need is agent forwarding to your local machine, where your private key is located.

Now to answer your actual question, ssh private key files are just that. When you setup a passphrase for it you are encrypting that file assymetrically with the given pass. If you want to change that passphrase you have to decrypt the file and encrypt it again. Of course, ssh-keygen provides a convenient way to do both steps with a command. As per @raz's comment link:

ssh-keygen -p -f ~/.ssh/id_dsa

Since you have a key file in each server, you will have to do this for each one.

Again, you should only have only one copy of your private key, on your local machine. Keeping it in each server is a hassle to maintain, and could lead to the key being compromised (although it's still hard, you are increasing the chances of that happening).


Unnecessary SSL encryption in API? Im developing my first API but I think I can optimize the server response by eliminating an SSL decryption.

The server recieves POST request with two parameters:

Action (int value)
Data (base 64 encoded)

If action is valid then the data gets base64 decoded. The result string then gets decrypted by the openssl_private_decrypt() php function. The decrypted string is in JSON format.

Is it really needed to have the SSL function if my server already has a certificate? Can I just send the JSON in plain text via the data parameter in the POST request, making it safe for my users to send sensitive data?

EDIT: I misunderstood the question, original answer below

Standard HTTPS will protect everything from evesdroppers on the network; the POST data, any HTTP headers, cookies, even the URL that they are accessing.

If your site has standard HTTPS, then you do not need extra encryption of the content. Yes, you can remove that extra call to openssl_private_decrypt().

Original answer

Even if you're encrypting the content of your POST bodies, what about the rest of the HTTP message?

Here's a sample GET for loading this page (all cookie values changed to X)

GET /questions/224647/unnecessary-ssl-encryption-in-api HTTP/1.1
Host: security.stackexchange.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://security.stackexchange.com/
Connection: close
Cookie: prov=X
__utma=X
__utmb=X;
__utmc=X
__utmz=X.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
__utmt=1; _ga=GA1.X; _gid=GA1.X
__qca=X
__gads=ID=X=ALNI_X
acct=t=X
_gat=1
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

If the HTTP headers on your API include sensitive information like the user's IP address, user agent, auth token, cookies, even which URL they are accessing is sometimes considered sensitive, then you need TLS / SSL to encrypt that.


Why should I bother having a firewall on servers? In the case of a server, the only applications that are running there are the ones that I've setup, so you don't just have random users downloading & running malware.

The only ports that are open to accept connections are the ones from services that I'm running, and want to be able to access.  If there's a zero-day in Apache or OpenSSH, the firewall won't help you.

So, it seems like the only thing that a firewall does is make it harder for me to setup new services (by having to figure out what ports to open).

So, in a server-based environment, where the machines are all under my control, what is there to be gained from having a firewall?

Additional security usually decreases functionality, so it is for you to establish the risk and see if the benefits of a local firewall outweigh the limited functionality.
  The purpose of a firewall is to block based on a port but also based on the source IP.  A server local firewall adds a layer of security that seems redundant to you, but if another layer of security fails, it could prevent malicious activity.

Scenarios this could help you with:

If you want to limit who can ping or make console connections to the server, based on console port and a limited number of accepted IPs
If new software is installed and starts listening on a new port, firewall will prevent connections to this service unless a matching firewall rule is also added
If the server was scanned for services from the outside or inside the network, a local firewall could reduce the results and focus an upcoming attack somewhere else
If you did have a vulnerability so severe as to want to block web traffic to the server, you could be better prepared for this if the firewall is pre-installed and working


Virus suspicion on website built with PHP Codeigniter I have received a website, which uses Codeigniter, to modify. The problem is, sometimes when I refresh the main page, a strange file named "download" with the Windows icon will start to download.

I'm not sure what it is and it made me worried. The file size is 33.4 KB (34,281 bytes) and the type is "File". If it helps, I'm on Windows 7 and I use Chrome most of the time and since it only happens sometimes, I've never seen it in Firefox. That can be a coincidence, though. In fact, this is happening on other computers as well.

This sounds very much like your server was compromised, and someone is using it to spread malware with the help of drive by downloads. Consider taking your site offline, as it might be infecting your visitors with malware.

To make sure that this is actually the case, I would recommend the following:

Ask the person responsible for the site if she knows what this might be. If there is a natural explanation, she should know.
Download the file (preferably on a VM to keep your system safe) and scan it with a couple of antivirus programs. Open it in a text editor to see if there is any reasonable explanation to why it should actually belong on the site.

When (and if) you have determined that it is infact malicious, you will have a lot of work ahead of you. This question explains it well. You will have to figure out how the compromise happend - how did the attackers get in - so you can stop it from happening again. And you will need to completely reinstall your whole system.

I know it is a though pill to swallow, but it is the only thing to do.


How can you access a Facebook account if you know the access token? Facebook discovered a "security issue" affecting 50 million accounts. According to Facebook,

  This allowed them to steal Facebook access tokens which they could
  then use to take over people’s accounts.

I searched but couldn't find anything on how to access a Facebook account if you know the access token, so I couldn't understand this security issue. Can anyone tell me how a hacker can access a Facebook account if they know the access token?

What I find unclear is HOW they stole access token and what the video upload functionality has to do with it.

But that is not your question. You want to know how an access token provides access to the account of another user. This requires some knowledge on how a website authenticates you and gives you access. Session management explained here.

In a normal flow, you authenticate using a password, bio-metrics, etc. In exchange for a valid authentication, you receive a session id which is often stored in a cookie. For every other request, you add this session ID to prove that you are the same user as then one who authenticated successfully. An access token is basically a session identifier. It is provided to a user after successful authentication. The token can have a certain privilege level attached to it. This allows you to get a low privilege access token when using weak authentication such as password, or a high privilege access token when using stronger authentication such as bio-metrics. Probably, the view-as functionality provides you with an access token for a user other than yourself (the person you are viewing as). Due to some bug (unclear to me as well), this access token can be attached to other requests and result in a successful response.

Normal flow:

I authenticate.
I get an access token.
I fetch my profile and attach my access token as proof that I am the person who authenticated.
I receive my profile information.

Attack flow:
 1. I view as my target user.
 2. I somehow receive an access token for this target user.
 3. I fetch 'my profile' but use the access token of my target user.
 4. I receive the profile info of the target user.

The entire concept of tokens, SSO, session is more complex and I cut some corners. A session identifier often refers to a piece of information on the server which feeds access control with user attributes to base access control decisions on. An access token is often self contained, meaning it holds the user attributes possibly encrypted and signed.


recreating CSRF Token after usage Is it a good practice to recreate the CSRF Token once its been used (basically create a new taken after a post request is sent)? Or it an unnecessary measure to take? My current system is recreating the token after each post/delete/put request and currently its causing me some serious trouble with a part of my code where I need to make multiple POST requests one after another, and since the system restarts the token as it starts the POST request, the other requests get "Invalid Token" error.

I think you should only create/change the token on every user login. If you change the token mid-session, it will invalidate all the links the user could have opened on new windows. And you will have lots of confused users.

If you think about it, there's no addition to security by changing the token. If any attacker cannot guess the first tag, s/he will not be able to guess the new one. If the first token is guessable, any other token will be too.


Submit form with token I have a token that I want to use to prevent direct access of some php-files.

Some of these php-files are loaded via AJAX.

The token is used with a session to secure form submission AND to prevent direct access of the php-files.

Here's a diagram that I made to explain it a little bit better:

What is more secure? Version 1 or 2?

Number 2 Is more secure because it is simple, and the most common method of implementing a CSRF synchronization token.  Complexity is the enemy of security.   To be honest I cannot identify a single attack being prevented by measure in #1,  it seems very superstitious, "cargo cult security".  This security measure doesn't prevent an interception proxy like BURP from accessing the PHP file, and further more no security system should rely upon this measure.  XSS is still a  major problem that could undermine this application (and CSRF sync tokens in general).

I recommend reading the browser security handbook,  and A Tangled Web to help understated the Same-Origin Policy and ways that it is abused by attackers.


What stops an attacker from tampering with data sent during the SSL/TLS handshake? On this page, it says the first thing sent is the SSL settings, such as version, and cipher settings.

If the attacker, say, wanted to change the encryption method used, what makes this not possible?

The cornerstone of the security against such tampering lies in the Finished messages. At the end of the handshake, client and server send to each other these messages, whose contents are a hash of the contents of all previously exchanged handshake messages. If an attacker alters anything in one of these messages, then the handshake messages, as seen by the client, won't match what the server saw, and the Finished message contents will differ. The attacker cannot reliably alter the contents of the Finished messages on the fly because they are sent after the switch to the newly negotiated cryptographic algorithm -- so they are encrypted and protected against alterations.

The only way for the attacker to pull off such an attack would be to force the client and server to use a cipher suite that is so weak that the attacker can totally break it right away, and thus alter the Finished messages to match his previous alterations. But decent SSL implementation don't support cipher suites which are that weak (there used to be "export cipher suites" limited to 40-bit keys, but they are no longer supported by existing libraries).

For more on SSL, read this.


How to start OWASP Shepherd using Docker? I have pulled the Security Shepherd Docker image and followed all the instructions for the Docker setup. I believe all steps were successful.

Now I don't know how to run the Shepherd application, while the Docker image is running. I assumed it would be something similar to the VM - connect from a browser to the IP address of the image, but I get a timeout...

How could I start the Shepherd?

It depends of how did you run the container. If you specified -p option, then you mapped ports from your host to the container in order to access it directly on your localhost. I mean, for example, if you put on docker run command -p 5555:80, you are mapping container port 80 to host's port 5555, so you can access to it on http://localhost:5555.

If you don't want to map ports in order to prevent anyone on your network can access to the container through your host, run it without -pand then you can do a docker inspect command to find the container ip address. Because the containers by default are accessible only by the host machine on a specific ip. Docker set iptables on run and allow only to you to access to the container. You can do docker inspect yourContainerName | grep '"IPAddress"' | head -n 1 and you'll get the ip address of your container. Then you can access only from the host to http://<yourResultIpFromBeforeCmd>

Hope it helps.


What is MITM attack in terms of implementation? When I search for MITM in the google most of the results say an unauthorized person positions himself in a conversation between two authentic users for malicious reasons, and there are several types in MITM.

But what I couldn't understand is, do these two authentic users have to be in a local network (LAN) or they can be anywhere on the internet for someone to perform MITM attack?.
Which types are limited to LAN and which MITM types can be performed on the users across the Internet.

Technically, they can be anywhere in the network. But a lot depends on the attacker, their capabilities, and their goals.

Some of the easiest Person In The Middle (PITM) attacks can be done with a fake WiFi hotspot, such as at a coffee shop or airport. These usually require physical proximity to the victim. They are good if an attacker wants to target a specific victim, and doesn’t have the resources for a more advanced attack. They are also effective at pulling in a few random victims. But they generally don’t scale well, and they expose the attackers to the risk of getting caught.

An attack can be launched against a single computer or browser by reconfiguring it to use the attacker’s proxy. This can be persistent, surviving reboots, VPNs, and relocated portable devices. But it requires some kind of access to the victim’s device to change its settings.

An attack on a server’s infrastructure can PITM many victims indiscriminately. These can harvest credentials or credit card data. Lately the technique has evolved into replacing JavaScript libraries to make copies of payment data that pass through them.

Attackers have been known to subvert Tor exit nodes to intercept traffic. It is claimed that law enforcement agencies have used this technique to target criminals on the dark web.

The most sophisticated attacks that have been published have come from national cyberwarfare organizations. These use attacks such as network-infrastructure-located servers that hijack the SYN/ACK TCP handshake with a more rapid reply than the legitimate server (google for FOXACID for a better description.)


Strength of variable-length generated password I am contributing to the Word Sequencer plugin for KeePass password manager, which can generate diceware-style passwords using a high-quality PRNG. Something in particular I'm working on is estimating the strength of passwords generated using the tool. I'm having a little trouble figuring out how to account for one of the configuration options, which can set one of the words in the sequence to have a probability of appearing in the generated password or not; i.e. an option to make the password a randomized length.

For the sake of example, suppose you're choosing 2 words from a wordlist of 8 words for your password (obviously you'd actually want a much larger wordlist/number of words, this is just a toy example). If you always choose both words, then the entropy of the password is:

lg(8*8) = lg(64) = 6

or alternatively:

lg(8) + lg(8) = 3+3 = 6

Now, say that you've configured the second word to not appear sometimes. Thus you have a chance of a one-word password (8 possible) or a two-word password (64 possible) for a total of:

lg(8 + 8*8) = lg(9 * 8) = lg(9) + lg(8)

...which should be a tiny bit more than the previous entropy of 6. This should be the entropy if an attacker was guessing JUST THIS ONE PASSWORD and he or she knows exactly how the password was generated.

But it doesn't actually matter if the password COULD have been 2 words long. If it's only 1 word long, and the attacker just guesses all 1-word passwords, the possibility of a second word doesn't really make the one-word password any stronger. So assuming there is a 25% chance of including the second word, maybe a better strength estimate would be the entropy of the expected value of the password space:

lg(8) + lg(3/4 * 0 + 1/4 * 8) = 3 + 1 = 4

Or, maybe it would be the expected value of the entropy itself:

lg(8) + [3/4 * 0 + 1/4 * lg(8)] = 3.75

So my question is: which method of calculating the expected entropy of this generated password is correct?

Should I treat the random length as adding additional possible passwords, thus slightly increasing the strength of a 2-word password?
Should I treat the random length as possibly decreasing the length of the password, so I take the entropy of the average number of password choices, for a strength somewhere between a 1-word and 2-word password?
Or should I take the expected value of the entropy, again for an in-between strength?
Maybe it's something else entirely?

If in fact the "correct" calculation would decrease the password strength when the option is enabled, then I guess that begs a follow-up question: is there any useful reason to even have this option, if it's just going to reduce the work an attacker must do on average?

Using fewer words from a diceware-style list is equivalent to sometimes allowing passwords with fewer characters. As per the accepted answer to Would allowing shorter passwords sometimes be more secure?:

  The benefit gained by forcing increased length far outweighs the number of possible passwords lost.

The same holds true for shorter diceware-style passwords. So always use the exact length and never something shorter.

EDIT: Note that the problem is not that shorter passwords reduce entropy. They actually increase it. But adding shorter passphrases dramatically reduces the effort to guess the shorter passwords. If your diceware word list has X words and your password will have a length of N, the password has XN possibilities. But a passphrase that is one word shorter has XN-1 or X fewer possibilities. So these passwords will be much more vulnerable than the ones that are just one word longer. The small gain in entropy is not worth the risk to these shorter passwords.

Consider this, if using passphrases that are 1-word shorter improved security, then the argument could be repeated to prove that adding passphrases that are 2-words shorter improved security, and so on. But ever-decreasing length passphrases is clearly a bad idea. So too is shortening a passphrase by 1 word.


How Can I Tell With Certainty If My iPad Has Been Hacked? I suspect the "Phoner" app from the Apple App Store compromised my iPad along with the device's IMEI.

After accepting a phone call on the iPad (I later found out to be a Google-generated listing), I noticed that the call record function that usually required me to push a button to start has turned itself on automatically.  Now every time I place or receive a phone call the record button comes on by itself automatically.

Since this issue started, all email I've sent to certain addresses from my iPad have not been received and I am not receiving email from certain address.

I contacted the Phoner tech support, they state they have never seen a case like this before.

What steps can I take to find out if the Phoner app and/or my IPad have been compromised?

Set up a trap

This requires some social engineering:

Send an e-mail with a shortened link to a mail adress you suspect of being monitored (you could use https://grabify.link/ for instance), make it intriguing.
If your mails are monitored chances are good that your attacker will click on that link, to see what information you want to share.
Via the tracking tools of your chosen link shortening service, you can now track the IP adress of everyone that clicks your link.

While this might not fix the security issue on your iPad, you might get an idea if your device has been compromised.

EDIT: I have not tested grabify myself and cannot vouch for its trustworthiness.


Can Origin headers be sent with get variables or the whole url? An application I'm working on responds to a wildcard Origin header by setting the Access-Control-Allow-Origin to subdomain.app.com if ending with .app.com.

However, if I append .app.com to a GET variable, as below:

Origin: example.com?q=.app.com

it responds with the following:

Access-Control-Allow-Origin: example.com?q=.app.com

This is vulnerable if browsers can be configured to pass the GET variable, or entire url.

I'm wondering if any browsers send the Origin header along with the entire url, or if JavaScript can be configured to allow this. From my testing Chrome / Firefox set the Origin header to the tld only, does anyone know if this configuration is vulnerable?

Origin is a Forbidden header name, and standards compliant user agent should only send the domain name in the origin header. They cannot be modified programmatically in standards compliant browsers. Note that user agents that doesn't try to be standards compliant, such as curl, or very old browsers before the specification was written, may not enforce this restriction.


Why doesn't the official CVE database list the names of the reporters? Why does neither MITRE nor NVD list out the name(s) of the reporter(s) of a CVE? e.g. for CVE-2018-1123, neither MITRE, nor NVD gives credit to reporters. However, for some CVEs, SecurityFocus does list out the names of the reporters.

If an external researcher needs to prove to an independent third party that he/she reported the bug, how will he/she go about that?

The CVE database does allow "Discoverer(s)/Credits" to be recorded, as shown on the MITRE CVE form:

However, the help for that field states:

  Please indicate the individual(s) or organization(s) that found the
  vulnerability or reported the vulnerability to you. This information
  will not be included in the public CVE entry.

Back in 2000, Steve Christey had this comment on the CVE editorial board mailing list:

  With respect to Marcus' comments, it is clear that some vulnerability
  discoverers want proper credit for discovering something, and it is
  becoming a more common practice (consider Microsoft's acknowledgement
  policy and recent SGI advisories).

Which implies that back when CVE started up there was an assumption that discoverers didn't want credit.  Today, that seems strange; reporting vulnerabilities - responsibly - is a respectable job which you can even get paid for.  But 25 years ago, that was far from the case.  People could rightly fear legal reprisals, and reputational damage, if they were responsible for publishing a vulnerability.  For how would they ever have found it if they were not evil hackers?

The CVE process has been one of several agents of change, making it possible to "own" discovery of a vulnerability more easily today.

The common method of attribution is via the announcement; and in many cases, the References field of the CVE (which is public) will point to the original advisory announcement.  (I seem to recall 8lgm had noteworthy 'tude on their releases back in the 90s).  The recent trend of fancy ALLCAPS vuln names with trendy websites is just more of the same.

(This leaves unanswered how to convince a 3rd party (well, 4th -   Discoverer/Reporter, MITRE/CNA, Vendor - those three talk.  You're asking about someone separate from those three, and I don't know the answer to that.)


Is it safe or even common to cache bcrypt checks in-memory In a web application that (as a side effect of implementing the password anti-pattern) stores passwords, one recommendation is to bcrypt to store them (or computationally expensive one-way salted hashes of them).  However, doing this makes the server process spend most of its time doing CPU intensive bcrypt comparisons, since the whole point of using bcrypt is that it takes time to test a password.

My question is this: is it safe to cache (in-memory) the response of a bcrypt comparison? I'm not worried about spending the time once per process, but once for every single request will become a scalability bottleneck.  Bonus points (?) if you can shed some light if it's common practice to do so.

Things I've considered:

If it's in-memory only then it's harder to attack
The persistent store is as secure as before if it's compromised
Lowering the bcrypt load factor makes the password database more vulnerable, if compromised

Password hashing is used for long-term password storage to deal with the case of an unwanted read-only database access by the attacker. This is a realistic threat; such a read access is a common outcome of successful SQL injection attacks.

On the other hand, a common model is to assume that the attacker cannot read the RAM contents of a live server. In that model, there is no problem in caching the password themselves in RAM, which avoids having to touch the database at all: password verification is just an in-memory comparison. Scenarios where an attacker can read the RAM without being able to take full control of the machine are quite convoluted and unlikely to apply.

Caching the bcrypt output does not make much sense by itself, because, for this information to be useful, it must be somehow indexed by the password and the salt (internally, there would be a map "password+salt" to "bcrypt output"), so the attacker who can read the bcrypt output from the RAM should be able to read the cleartext password itself. Still, in a given existing server implementation, it may be easier to retrofit a RAM cache as such a map (in the code, you can plug that in the "bcrypt engine" transparently); as explained above, caching bcrypt output is no worse than storing plaintext passwords in RAM, which is usually fine.


Should I use CSRF protection for GET requests? I've seen several blanket statements on the web to the effect that you don't need CSRF protection for GET requests.

But many web applications have GET requests that return sensitive data, right? Then wouldn't you want to protect those against CSRF attacks?

Am I missing something, or are these blanket statements  assuming that the data the GET request gives is unimportant?

Examples of blanket recommendations gainst using CSRF tokens with GET:

https://security.stackexchange.com/a/90027/5997

  Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are vulnerable.

http://www.django-rest-framework.org/topics/ajax-csrf-cors/

  Ensure that the 'safe' HTTP operations, such as GET, HEAD and OPTIONS cannot be used to alter any server-side state.

The assumption here is that if GET doesn't modify state, it's not worth protecting.
http://sakurity.com/blog/2015/03/04/hybrid_api_auth.html contains a code line that suggests this approach:

# 1) verify CSRF token for all non-GET requests

CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:

  a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

So the CSRF attack will not be able to access the data it requests because it is a cross-site (that's the CS in CSRF) request and prohibited by the same-origin policy. So illicit data access is not a problem with CSRF.

As a CSRF attack can execute commands but can't see their results, it is forced to act blindly. For example, a CSRF attack can tell your browser to request your bank account balance, but it can't see that balance. This is obviously a pointless attack (unless you're trying to DDoS the bank server or something). But it is not pointless if, for example, the CSRF attack tells your browser to instruct your bank to transfer money from your account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Fortunately for the attacker, they don't need to see the bank's response, they just want the money in their account.

As only state-changing operations are likely to be targets of CSRF attacks, only they need CSRF defenses.


Password policies for randomly generating passwords I want to randomly generate a password. I started by using all characters that are typable on a standard QWERTY keyboard. However, many password policies reject passwords with some special characters (for example ^~`'" are characters that are commonly rejected). Other policies require special characters. So far, I have used a strategy that generates a password that includes at least one uppercase, one lowercase, a number, and a not-so-special character (such as a dot or comma), which are not often rejected. Of course, the password is of sufficient length.

However, I have also come across sites which only accepts strings of letters and numbers as passwords.

What are reasonable password policies to support?

I can guarantee you that we could easily find two sites that have entirely incompatible password policies. It'd actually be easy: find one site that requires special characters, and another site that bans them. Done. So there's no one-size-fits-all solution.

I think your best bet is to generate random passwords in a form that'll mostly work for sites - upper, lower, numbers, and a reasonable length. I've used a UUID-type string or even a truncated MD5/SHA1/whatever hash of /dev/urandom in the past. Then give users the option to enable "special characters required [/forbidden]", max length, etc options. A more complex option is to build-in the policies for the weird sites as they come up, but that'd be nightmareish probably.

FWIW, I'm a strong believe that unique passwords (ie, using a password manager) is vastly more important than using strong passwords in most cases (the main exception is when the attacker can perform an offline attack, like a full-disk encryption password). So I would worry more about making the integration easy (and making the password manager itself secure!) than having the strongest possible passwords. I can talk about that all day, happy to expand on it!


How X509 Certificates are used for Encryption I have small doubt regarding the process of X509.
I am aware of OpenPGP Encryption/Decryption, where we generate the public key and private key. We can share the public key to vendors and they can encrypt data with the key and we can decrypt the data using out private key. It's simple and straight-forward for me.

When it comes to X509, I am bit confused. My client wants to use X509 certificate to transfer sensitive information [which's already encrypted using symmetric Encryption like AES] between two people [between client and his vendors]. How X509 works if we can generate the certificate using only public key.

Assume, if I encrypt the data using AES with one random generated key. How do I transfer this data along with key to vendor using X509 so that any third party will not intercept during network transmission.

Could any one please explain? Btw, we transfer the data in SOAP message including Certificate info

X.509 is a format for certificates: a certificate is a sequence of bytes which contains, in a specific format, a name and a public key, over which a digital signature is computed and embedded in the certificate. The signer is a Certification Authority which asserts that the public key is indeed owned by the entity known under that name. By verifying the signature, you can make sure that the certificate is genuine, i.e. is really what the CA issued; and, that way, you gain trust in the binding of name with public key (insofar as you trust the CA for being honest and not too gullible, and as you know the CA key for signature verification, which may entail obtaining a certificate for the CA, and verifying that certificate, and so on, up to a trust anchor aka root certificate).

Thus, X.509 is a way to distribute public keys, by which I mean: a method which allows various actors (e.g. you) to know, with some guarantee of non alteration by malicious third parties (i.e. "attackers") the public keys of other actors.

OpenPGP is a standard format for a lot of things. One of the things which OpenPGP defines is a way to encode a public key along with a "name" (an email address), and a signature over these two. That's, really, a certificate in its own right (although with a format which is not compatible with X.509). But OpenPGP also defines how to use the public key of a given individual (let's call him Butch) in order to encrypt a bunch of bytes that only Butch, using his private key, will be able to decrypt. Technically, this uses a randomly generated session key, used with AES (or similar) to encrypt the raw data, and that session key is what is encrypted with the recipient's public key (generally of type RSA or ElGamal).

Therefore, for your problem, you do not want to "encrypt with X.509". X.509 defines nothing about encryption. What you want is to use a standard format which describes encryption with the recipient's public key and builds on X.509 certificates for the public key distribution. This standard format, coupled with X.509, would be an analogous to OpenPGP. This standard format exists and is called CMS (formerly known as "PKCS#7"). When CMS objects are sent by email, this becomes another layer of standard, which is called S/MIME.

CMS (or S/MIME) is what you need for asynchronous communication: you prepare a blob, to be sent later on to the recipient, like what you do with OpenPGP. If you can make a synchronous communication (sender and recipient are "online" simultaneously), then you can use SSL/TLS (or its Web counterpart HTTPS). In SSL, the server has a public key, which it sends to the client as an X.509 certificate. The client validates the certificate, then uses the public key contained therein in order to establish a session key with the server, and encrypt the data with that session key.

In any case, assembly of cryptographic algorithms into protocols is known to be hard to do correctly, nigh impossible to test for security, and fraught with perils. So don't imagine that you may build your own mix; you really should rely on an existing standard, like CMS or SSL.


Methods for immediate certificate signing I'm an absolute newbie in the enterprise CSR and certificate generation process. So kindly point out any obvious silliness in the question.

Is it possible to completely automate the process of CSR generation + certificate signing by a CA and installation of signed certificate with? From my basic understanding, I believe the CSR submission and certificate signing by the CA has a turnaround time to the tune of days and would also require some manual intervention. Has anyone managed to automate that step? Do CAs expose signing as a web service?

While thinking about it, I can now definitively answer that some CA offers Web API allowing to automate part or all of the certificate generation / signature.

Some concrete example of this are Digicert, GlobalSign, Gandi.

Some other CA may therefore offer the same services, however you need to check:

The available functionality, not all functions available from the graphical web interface may be available from the Web API,
This may also be a paid option. An API key is always required for such operation, and getting such this key may be subject to some fees.


Penetration testing preventive or detective control? I have always wondered if penetration testing is a preventive or detective control. My view is that it is both preventive (preventive as it scans for vulnerabilities, which can be fixed to prevent cyberattacks) and detective (detects any vulnerabilities found on a system). Correct me if I am wrong.

It is always preventative.  Detective controls detect an intrusion in progress.  A penetration test is not an intrusion as it is an intended and approved use of the system, even if the use is simulating a breach.  It is a preventative measure to keep actual attacks from occurring by finding holes that need to be fixed.

The argument could possibly be made that they are also corrective if you characterized it as an attack, since the intent is to make corrections to the system, but I think this is a weak characterization as the entire point of the activity is to prevent a real attack in the first place, thus preventing the attack.


Validating iss and aud for internally signed JWT I have an identity service that issues JWTs that are signed with private key.

I have several resource services that consume that token to determine the claims of the user and thereby to determine the authorization scope. Naturally, the resource service also has access to the public key counterpart that can be used for signature validation.

Note that both identity and resource services are developed and managed by me. Consider that the resource service does not call any other external service with the token, and just use the token to derive the authorization scope.

As the header, and payload of JWT can easily be decoded, anyone with the access to the private key can create a token with the intended aud, and iss. In this scenario, does validation of aud, and iss brings anything additional from security perspective, though every other token validation best practices say to validate aud, and iss? Considering the private key is securely stored, isn't it enough to validate the signature of JWT alone (along with the claims of user, but that is not relevant for this discussion) in this scenario?

The purpose of both security controls are different. JWT signature validation ensures that the token payload have not been modified on transport and was issued by a known sender.

The "iss" and "aud" validation ensures that token have been issued by expected Identity Provider and for expected Client. This also (with validation of "azp", "at_hash" or "c_hash") mitigates against some of the Token Substitution threads, where attacker can use token issued from another session (possessed by attacker) by simply "copy and paste".

Token Substituion threat


Encrypted NAS where only clients know the (decryption) key Is there an implementation of a file-sharing network protocol where the server has no idea what data is being stored, but can serve the encrypted files to clients that will decrypt them on-the-fly (if the client knows the key)?

Yes: Windows EFS at least, can be used that way.

Each file is encrypted with a unique, random key and that key is the encrypted once for each user who has access to the file and the result is stored in the NTFS alternate data stream of the file

So, as long as the NAS supports NTFS, you can use EFS on it and the actual file storage server will never see the cleartext content of the encrypted files.


Wordpress.org pages refresh when logging out of Gmail I've noticed that when I change my Gmail account by logging out of one account and then logging into another, all open Wordpress.org pages refresh. Additionally, when I recently changed a password on a Google account, in my Wordpress.org tab Lastpass asked if it should store the new password.

What is the connection between Wordpress.org, or any other arbitrary page, and Google? I notice that the Wordpress.org pages use Google Analytics and have a Google Plus link in the HTML:

Is that the cause of the refresh and password prompt? Is this something that I as a user should be concerned about?

The short answer is no.

Wordpress has quite a few community-developed plugins that integrate features from Google services onto Wordpress sites that can be found in their "Plugin Directory". Examples from a search for the keyword "Google" on the Plugin Directory.

Since these plugins are not officially developed by Google, odds are that not all of them use the most aesthetic/efficient code. Sounds like that particular plugin has the page refreshing if the session detects a google login change, so that Wordpress can receive the new Google information from your browsing session, which would inform the site/plugin of a new user/no user for the +1 button, adsense info, etc. to associate with.


Would suggesting a random passphrase during sign-up hurt overall security? I've been looking for ways to improve security and security awareness for both internal and external clients and I happened upon the idea of generating a one-time, random "password suggestion" on the registration and password-change screens, similar to the following:

Assuming that:

The password is generated by indexing all 5-8 letter words in a Scrabble dictionary (about 70,000 words net total) and using a crypto RNG service to choose random indexes;
The page is viewed over an SSL connection;
The password is a nonce, i.e. the server doesn't actually save it anywhere;
Users are not actually assigned this password - they can still create their own, for example if they're sitting at a public terminal.

Is this a good idea or a bad one?  I personally like the idea but I'm concerned that my enthusiasm and optimism as a developer might be overshadowing some unintended negative side-effects of a scheme like this.

Should I go ahead with this?  Are there ways that it could be improved and/or other things I need to look out for?

For security, this is very good. You're recommending about 64 bits of entropy in the password, which is far more than 99.9999% users will come up on their own. And not storing the plaintext password is obviously good for security.

For usability, this is mostly ok, but there's a big hole: a lot of users will use that password, neglect to write it down anywhere, and promptly forget it. Copy, paste, forget. So you'll have to use your password reset procedure often, which means it'll have to be lightweight, which likely means it'll be pretty insecure.


Inputting user ID's in URL? I am currently working on functionality that will allow users to reset their passwords. My question pertains to the security in putting user ID's (a.k.a the auto increment ID's from database) in the URL so during the password reset process I can use that ID to fetch their secret questions, their token, and to reset their PW's.

I am aware of validation of the URL string as only these characters are allowed in the URL bar :

'a-z 0-9_-'

also I am aware of encoding and escaping as when I query the DB and append the users ID I run it through urlencode and when I put it into query I run urldecode to get it back to its most natural value (the db value) that I first queried before appending it the URL.

Am I missing anything? I guess one of my fears is what happens if someone enters in another users ID for possibly trying to DOS another user? Keeping in mind I only append the user ID after the user has clicked on the email verification link. Am I going about this correctly?

Any clarifications would be very nice. Thanks in advance.

You are going about it all wrong. Why will you need to send the USER_ID over a GET request to retrieve the secret questions and tokens like you mentioned?

You probably store the reset tokens in a table in the database with a foreign key linking it to the user's data stored in another table. You can simply parse the token sent using GET and retrieve all the information you need about the user.

Also, the way you describe your process isn't very clear. You should ask the user to input the secret question before sending out the password reset link. There is no point in doing it the other way around and not requiring any validation to trigger a password reset can be very annoying for a user if he gets endless password reset request.


How is Facebook not considered spyware? Recently, it was unveiled that Facebook's application in mobile phones (and messenger) have access to data that you didn't consent in their collection.

Data that is completely unrelated to the existence of Facebook's and messenger's applications in the first place.

Data that include all your contacts in your phone and metadata about SMS messages you sent/received.

Now, if an application on the surface does one thing but actually does tracking and spying on you, it is considered spyware at least and malware in the worst.

How come there is no mention that Facebook's applications and network are at least spyware?

Very Simple, Facebook IS spyware.

It is also "Consensual" spyware...yeah, it's spying on you, but you agreed to it (even if you didn't read the agreement before checking the "I Agree" box), and it is probably safe to say, you 'enjoyed' the benefits of it, so most people (still) aren't really complaining about it.

As the public's understanding of just how invasive Facebook has become people are coming to terms with what they will and will not accept.

For the most part what it really comes down to is that Facebook is paying attention to what you do in order to target you with advertising for things you will like and to 'grow' it's network.

Think of it this way, if you like, for decades advertisers choose where to place beer commercials, dish soap ads, and other products based on who they thought would be watching TV. There are more beer commercials on CBS during a football game than on ABC during the news (though sometimes the news might make you reach for a beer...but I digress). Facebook has taken this to a new level.

For my part I am pleased that I don't get bombarded with feminine hygiene ads, but do get ads, and even coupons and invitations to events where the food, music and activities are more likely to be 'to my liking'.

More recently, however, Facebook has gotten into more 'censorship'... and IMHO that is bothersome. How much so? each Facebook user will have to decide for themselves. When you walk into the "mall" that is owned by Zuckerberg he does get to decide the rules...if you don't like them, you can always leave. But yes, he is watching.


Telegram Visibility Into Secret Chat VS Plaintext Background

Telegram Messenger offers an "End-to-End" encrypted channel, with their home brewed MTProto, called Secret Chat.

They have "Link Previews" by default in all modes, but Secret Chats, in which the servers are able to generate a preview and a summary by crawling the link, to display that information to the end user.

Problem

Recently, they added a new option in settings to enable a "feature" called "Link Previews" in which every link in Secret Chats is also crawled and info is displayed. They produced a one-time dialogue inside of my Secret Chats, that prevented me from taking a screenshot of it, saying whether I'd like to enable that or not.

Seeing as End-to-End encryption would no longer apply if they can see my Secret Chat links to crawl them, I'll give them -for the hundredth time- the benefit of the doubt and simply ask how do they do it?

Extras

One option that comes to mind is by crawling the links from inside the Telegram client on the user's device instead of crawling them with their -proprietary, mind you- servers.

That is the least creepy/flawed design I can think of, but even that means they are also able to simply set their client to send the client's Secret Chat log to anyone they so choose; if this  implementation of Link Previews went unnoticed, then I don't see why keylogging would be any different if developers aren't interested in Telegram enough to review its code changes to their Open Source client.

how do they do it?

From here (http://telegram.wiki/tips:linkparsing) it is clear that the links themselves are sent to the server to be parsed.

Therefore, they probably parse locally your secret text on client side to find links (not that hard to isolate links from the rest of the text) and send only those to the server, as is done in any other (non secret) chat.

As far as I can understand from their docs, they do it on the senders side. After you hit send, it goes encrypted to the other side. Therefore, the server side will not be sure if you did sent that link to anyone, if it was on a secret or non secret chat or just fetched the preview and canceled the message sending.

  but even that means they are also able to simply set their client to
  send the client's Secret Chat log to anyone they so choose;

You are right, nothing stops them from doing this if you do not trust that the client does not have a backdoor for that. But that is not related to Link previews. Even without anything like this, the simple fact that they do need to parse the unencrypted messages for displaying it to you is already a point where they could capture and send anything to a third party. The encryption end-to-end is only until it leaves one phone and gets to the other. Not before and after that. You type unencrypted data and read unencrypted data.

What this could add is a possible point of failure, ex some specially crafted link could exploit a bug and leak more than the URL. But if it is well implemented, it just leaks the URL, that you should allow it to do for the sake of using this resource.

IMHO, they should simply not add this functionality to secret chats. I dont think most users will understand exactly how much is not secret anymore when using it.


Can I hook "vssadmin.exe delete" process? I'm studying and listing ransomware family.(like CryptoWall, TorrentLocker, CTB-Locker, .etc)

When I read the features of those family, they do vssadmin.exe to delete shadow copies of victim's PC so that victim can't recover.

So is it possible?
If I can hook vssadmin, the vssadmin process is paused until additional authentication (like face recognition in your laptop cam).

In other words, ransomware are not allowed to delete shadow copy.
So if users are attacked by ransomware, user can recover some files.(even though, from certain date in shadow copy to current data are lost)

Thank you

Yes, but wouldn't you also need to hook wmic shadowcopy delete as well as other ways to do this?


IP Forwarding question I am starting to learn a bit about TCP/IP and I have a question about IP forwarding.

If someone had access to my home network (WiFi password) what are the possibilities that IP forwarding is being applied to all my network traffic (eavesdropping) even though no other machine has been connected to my home router wireless (or at least visibly connected)?

I would like to understand the risk and possibilities of such scenario.

If you do not see any other devices connected to the router, then these possibilities come to my mind:

If the data transfer between your device and the router happens by WIFI, your device is broadcasting radio signals, which can be received by anyone in the range and since they already know the wifi password, they can decrypt it also. you will not find this passive listener as they are not connected to the router. more information here
your own device is compromised, so every time you connect it to the network, it forwards traffic elsewhere.
Your router itself may be compromised, so that it is forwarding traffic elsewhere.

Analyzing the amount of Risk is up to you as it depends on what and how this WIFI network is used. but if this attacker uses your WIFI network for illegal activities then you are in trouble.


If I use a proxy on my gaming console, can someone find my real IP or boot me from a game? Will a proxy work like a VPN or not? What site has working proxy?

A proxy is designed to act on your behalf, so in theory, it should hide your IP, but it depends on a lot of factors including what traffic flows through the proxy.

This should address your worries about being "booted".

Proxies and VPNs perform very different functions, and I leave that research to you. In terms of hiding your IP, they can basically hide your IP equally well.


Storing Old Password History and Information Google, Facebook, Twitter, and several other services still knows the older passwords which we used on our accounts. At times, I can not reuse the same password as I have. Then with Google, if I type an old password by mistake, it tells me when I last changed my password. I think this could be more or less of a security threat over doing any good.

Why would these companies want to keep old passwords and information such as that? How much do we need to worry about them keeping that information, if someone was to break into our accounts?

Security:

It might sound like a security hole to you. But trust me, It is one of the strongest security pattern.
It prevents you from avoiding you to create an old password of yours even in your hurry times. It is really necessary for you
not to re-create your old passwords, since there is always a chance of some people knowing your history(friends or foes, it still
 counts as a threat to your privacy).

Convenience:

You have no idea how useful it is to an user when they are notified that they entered their old password by mistake OR they changed it this
time back,etc., It will really help a user who genuinely typed his old password by mistake.

Getting hacked:

Just by knowing that you changed your password last month will not help an attacker to guess your current password. It is based on
the information that you put out there online.

For example, when an attacker comes to know that you changes your password two days before, he might
check out your blog or social network sites you are involve in. If you put any related info that could lead to guessing your current password, thats when
you are officially busted and it not because of your networks but by you.

Conclusion:

So just be careful with your online data. Update strong passwords frequently and bother less about your old passwords stored by Facebook,Google,Twitter. After all they exist to make money by your usage which means they are desperate enough to secure your identity and information as they secure theirs!


Does the amount of bandwidth available on a network determine how strong a DoS attack should be? Does bandwidth alone determine how many packets a router or server can handle before the server is overran and then goes offline?

Imagine a post office.

It has an entrance, a counter with a clerk who deals with the customers and their packets. The clerk is a multi-tasking talent with a lot of arms to deal with packets on the counter.

The counter has a certain width, so only a certain number of customers can be processed at the same time.

The clerk has a small address book with addresses of where to send the packets. Some pages are blank, and he can input new addresses.

Behind the counter and the clerk are a certain number of shelves, where the assistant of the clerk puts packets until they can be further processed and sent.

There are now several cases for a DDOS / DOS attack in this metaphor.

Case 1 - SW Bug

One mean customer steps forward, leans over to the clerk and shows the clerk the packet with the address "Vietnam" on it - which triggers the clerks PTSD1. This is something only a few people knew about. The clerk starts sobbing uncontrollably, sits in a corner and is of no further use to the post office. It has to close early, until the owner of the office comes, says some magic words and restarts the office.

The word "Vietnam" in this case stands metaphorically for a bug that the mean customer abuses. Since usually only one packet is needed to freeze the office, this might not count as a DDOS, but certainly a DOS.

Case 2 - Bandwidth

The post office has only one door, through which all the customers and the packets have to squeeze themselves, incoming and outgoing ones alike.

If an attacker wants so abuse this, he might gather a lot of unusually big customers and/or packets to enter the post office all at the same time. Now the doors are too tight and new customers can't enter while other customers can't leave the store. This halts the post office, until the clerk puts down a rule at the entrance: "You must be smaller than this to enter".

Everyone trying to enter the office while being too big won't be allowed to enter the office.

The doors here stand for the bandwidth; the more bandwidth you have the more customers can enter / leave at the same time. Since this is pretty dynamically, it's sometimes hard to find the exact point at which the store has to halt.

Case 3 - CPU Load

Whenever a customer comes to the clerk, he has to greet them, take the packet and process it. Usually he has to check if the address is correct, the packet is not purple (purple packets are not standardized packets and therefore bad!). If the clerk is really paranoid, he has to open the packet, look to make sure that no contraband is inside, test if the packet smells like Anthrax, etc.

So depending on the rules for the post office, the clerk has to check a lot of parameters. If an attacker wants to abuse this, he can gather a lot of people with a lot of small packets. The clerk has to process EVERY packet, which can create a lot of overhead.

Because of this, the customers outside start to pile up, and some even start to curse and leave the line, since they don't have all the time in the world to wait in this line forever.

So CPU load usually has to do with processing in this metaphor.

Case 4 - Memory

The clerk works for quite some time in the post office, so he has memorized several addresses. He also has some addresses written in his address book.

A attacker can abuse this by gathering a lot of people and tell them to write unusual addresses on their packets.

So each time the clerk processes one of those mean customers, he has to write down another addresses into his book. This soon gets filled and now he is in trouble. How should he process new addresses? Kick out old ones? He has no idea and maybe stops his processing altogether.

The address book stands for the memory, which is finite.

Case 5 - Connections

The counter has a mentioned width. Since the clerk is a multi-tasking talent, he can deal with 3000 customers at once, but not more.

The attacker can abuse this fact by gathering a lot of people and tell them to try to rush to the counter. Now there are 5000 people, demanding to get their packet processed, causing a lot of stress for the clerk with his just 3000 arms.

Case 6 - Disks (and other resources)

The clerk has to store the packets into a shelf behind his counter. This is the job of his assistant. Some assistants are faster than others, so sometimes it can happen, that the clerk can deal with 3000 customers at once, while the assistant has to slowly move himself and the packet to the correct part of the shelf.

So while the clerk certainly is fast enough, the poor assistant is not. The assistant in this case can be the server disks or other components.

Conclusion:

DDOS / DOS attacks can use a lot of different methods and parameters to stop or slow the service of a server / server-cluster. Therefore it depends on a lot of factors: Which software you use, how much bandwidth you have, the CPU, memory etc.

[1] PTSD is no joke, but it fits this metaphor nicely. I apologize for using it in a jokingly fashion.


Is a computer more vulnerable if wireless is left on when booting? Normally I switch off wireless on my laptop before I shut it down but I forgot to do this last night. So this morning, after I booted up the laptop, I saw the wireless notification on the bottom right was active long before the antivirus and antimalware notifications.

I am aware that having no notifications pop up does not mean the software is not running but I was wondering if at any point my computer is vulnerable, even if it's for a second or two?

I am using Windows 8.1 64-bit on a TOSHIBA Satellite L50-C-22L laptop.

You do not need to be concerned by this. Windows 8 in particular introduced many new security features and technologies which take direct aim at early boot malware. You can read about these in some depth here: https://technet.microsoft.com/en-us/library/dn283963(v=ws.11).aspx

One introduction for example is ELAM - Early Launch Anti-Malware, which gives antivirus vendors the chance to load a low level protection driver at an extremely early stage during the bootup process. You can read more about that here (https://msdn.microsoft.com/en-us/library/windows/desktop/hh848061(v=vs.85).aspx)

What you should take away from this is that anti-malware software starts up in stages. At each phase of the boot Windows gives AV software the chance to load the next set of protection drivers, firewalls, signature based detection modules, ...

The very last and final piece is the user interface component. Just because your AV software is not yet visible immediately after boot does not mean it is not running - it's been running silently in the background for a long time already. Also, Windows 8 has an extremely well designed and almost impenetrable boot procedure. You need not be concerned - there is no significant risk posed by leaving your wireless enabled over boot, and far less of a risk than navigating to a few websites in your favourite browser. Don't worry about it.


Why is information obtained from public records considered a secure way of confirming your identity? Various financial institutions, government agencies, etc., use public records information to confirm people's identities, as touched upon in UPS my choice -- How can I access my public records?  The information often includes relatives, past addresses, banks that have serviced your loans, cars you've owned, etc.

By definition, if the information is obtained from publicly-available records, anyone should be able to look up this information. I understand that it prevents random strangers from casually guessing my information and cracking my account, but I see ads all the time for $40 instant public records background checks.

If someone wants to break into my financial accounts or download my tax returns and steal my identity, what's to stop them from just searching public records themselves or buying a report? Maybe decades ago it was more difficult to search public records because you had to physically travel around and/or make a lot of phone calls. But in an age when almost everything is instantly searchable, how and why are public records considered "secure enough" to confirm anyone's identity?

You ask how and why information about you is "secure enough" to serve as an authenticator.  The answer is, it's not.

Identifiers must be unique, and there must not ever be a need to change an identifier.

Authenticators need not be unique and must be changeable if the authenticator is compromised.  Further, authenticators must not be researchable.

So, example: the SSN is a dandy identifier; it's (supposed to be) unique and seldom if ever changed.  It's a terrible authenticator.  Literally thousands of people have legitimate access to your SSN and mine:  bank, employer, stockbroker, IRS, and others.

Similarly, you cannot (legitimately) change your birth date, mother's maiden name, bank that services your loan of 2005, your first car, and all those other things that people sometimes try to use as authenticators.  And they're all researchable.

That, relying on researchable authenticators, is how the IRS managed to give 100,000 tax returns to scammers earlier this year.


Can non-torrent-supporting browsers run torrent clients like jstorrent.com for Chrome? I'm participating in a discussion on Quora where I argue that browser security means that JavaScript, ActiveX, and even Java applets, aren't allowed to act as torrent clients, even with the end user's permission. More specifically, I would think that opening a listening port would be something that a browser can't or shouldn't do.

Additionally, although websites CAN store data for offline storage, it shouldn't be a large enough amount to hold an entire movie or other large file.

I realize that jstorrent.com is a pure JavaScript torrent client for Chrome, but I'm arguing that it only works because Chrome itself supports magnet links and thus has a "built-in" torrent client.

How accurate is my argument?

I realize that there may be ways to create a torrent client without opening a listening port, but the primary statement I'm hoping is false is "With permissions granted by the user, a web app can do almost anything a non-web app can". Is this now true? I'm pretty sure it didn't use to be.

You are wrong as far as assuming how jstorrent.com works. So I will elaborate a little on that first.

With jstorrent.com you are required to install it as a Chrome extension. Yes, it is only written in JavaScript. But as an extension it is no longer restricted to the sandbox environment it is in. It now has access to powerful APIs that allow it to access your filesystem and more. It also doesn't have the limitations that you would have with storage sizes and more. Additionally Chrome doesn't have a built in torrent client. These are implemented in the extensions. And jstorrent.com cannot possibly run at all as a regular website as a non extension.

JavaScript itself minus a few exploits in the past it is by far the safest browser scripting language available. Browsers intentionally try to lock it down and sandboxed as possible. Where things like ActiveX, Java applets, and Flash APIs are not completely sandboxed and a browser has limited control of them. But you can bypass this JS sandbox such as using a Chrome extension or using an application built with Electron which intentionally removes restrictions to allow expanded application development not possible through a regular web browser experience.

So could another browser support a JS torrent client? If they have an extension system or allow mods to bypass sandbox restrictions then absolutely. Firefox has a torrent client extension as well.

However both have separate APIs and separate ways of doing things. You would be looking at a lot of work to get jstorrent.com on Firefox or another browser.

So in closing, Chrome is not doing anything out of the box to risk your security. You are as soon as you are opting in to install an extension with elevated privileges. And yes, a torrent client could be made in the same way for any browser that has an extension system with the desired APIs available.

Edit: It is worth mentioning there are a few solutions out there where an application runs on your machine and acts as the client. Using web sockets they can transmit that data to a torrent client front end coded only in JavaScript and no extensions required. However, it is important to know the sandbox at this point is bypassed with the installed agent and not the web browser.


Reasons not to preserve the certification path on an intercepting HTTPS proxy In this environment an intercepting HTTPS proxy is used for legitimate purposes and its CA root certificate is installed on all clients. Every HTTPS proxy solution I've seen so far simply signs a new certificate directly with the CA, not preserving any information on the original certification path. After the proxy has made its decision, it's impossible to see what the original certification path was, which would be helpful for further evaluation in both success and failure.

It would be possible for the proxy to recreate the whole path of fake certificates instead of the one fake certificate, as demonstrated in this matrix on row "proposal". Of course, examining these certificates in detail would be rather useless, as they have fake keys, but this would preserve information on their CN, the dates they are valid between etc.

My questions:

What might be the main reason we don't see this?

It's assumed that users won't examine the certificate anyway.
The additional resources this would consume on the proxy.

...or do we? Any examples of such intercepting proxies?
Would there be a better alternative, if we would like to preserve this information for the client?

What might be the main reason we don't see this?

There is not much added value with this in my opinion. As you already noticed these information would be fake anyway. Actually, I find it useful that if somebody has a look at the certificate (most don't care anyway) it would be obvious that this is not the original CA but a local one explicitly provided for SSL inspection.

  Would there be a better alternative, if we would like to preserve this information for the client?

While most end users don't care as long as the browser does not complain, for some it would be useful to get the original certificate and chain, i.e. not a similar one but the real one. This could for example be done by providing a specific URL where the intercepting proxy simply delivers information about the original certificate as was seen by the proxy, i.e. something like https://proxy/give-me-the-original-cert?domain=.... I know of at least one product which has implemented this approach at the request of a customer.


How to intercept XmlHttpRequest with OWASP ZAP I'm using OWASP ZAP for intercepting request to a web application, OWASP WebGoat. My break point is quite simple: 'URL', 'contains', and 'http://localhost:8080/WebGoat/start.mvc#attack/76122667/400&from=ajax'. But it never catches any XMLHttpRequest with that URL while the Developer tool in browser does it well, ie can see that request.

I'm not sure if I am missing any further configuration. Please shed a light on this.

You need to remove the '#' and everything after it.
This is known as the 'fragment' (https://en.wikipedia.org/wiki/URL) and is not send by the browser, so its not present in the URL that ZAP sees.


Signature-based antiviruses Do signature-based antiviruses search for the exact matches of the signatures they have in their database with those of viruses to analyse ?
I ask this question because I wonder if it is the reason why I often read that signature-based only antiviruses are outdated.

There is not much you can do to prevent an AV signature set from getting outdated. Imagine you would want to create a piece of malware with the goal to infect as many people as possible. You certainly wouldn't want it to get detected by any virus scanners, do you? So what do you do? You let all virus scanners you can get run over your malware, see if they detect it, and when they do you modify and obfuscate your malware until they don't.

Now your malware is undetectable... until the AV scanners find out about it and update so they detect it again.

What do you do now? You get the updated virus scanners and again start to modify and obfuscate your malware until they again can't detect it anymore and you again set it free. Then the cycle repeats.

It's an endless cat- and mouse game between AV vendors and black hat hackers. Both have commercial interests. When one stops updating their product to outsmart the other, they would lose a very lucrative business.


Can a SSL certificate have longer validity period than its parent in X.509 chain? When a X.509 certificate chain is composed of
X1, X2 ... Xn and Xn is root CA,
Can a certificate in lower level have longer validity
period than its parents?
I think that lower level should be proper sub-range of high level
at least in practice.

While I cannot find any such obligation in RFC2459,
can I rely on that assumption?

Any comments are deeply appreciated.

This is an historically disputed point.

In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann:

  Although this isn't specified in any standard, some software requires validity
  period nesting, in which the subject validity period lies inside the issuer
  validity period.  Most software however performs simple pointwise checking in
  which it checks whether a cert chain is valid at a certain point in time
  (typically the current time).  Maintaining the validity nesting requires that a
  certain amount of care be used in designing overlapping validity periods
  between successive generations of certificates in a hierarchy.  Further
  complications arise when an existing CA is re-rooted or re-parented (for
  example a divisional CA is subordinated to a corporate CA).

The Microsoft PKI ("ADCS", aka Active Directory Certificate Services) enforces validity period nesting, in that, when it issues a certificate, it will not allow the end-of-validity date of that certificate to exceed that of the current CA certificate (in effect, truncating the validity period mandated by the template if it would lead to such a situation).

Even though, when renewing a CA certificate, it is possible to keep the same CA name and CA key, in which case both the old and new CA certificates can be
used interchangeably as long as neither is expired, on EE certificates issued both before and after the renewal. That is, if the old CA certificate is CA1, the new one is CA2, certificate EE1 was issued before the renewal and certificate EE2 was issued after, then CA1->EE1, CA1->EE2, CA2->EE1 and CA2->EE2 should all validate; this is very convenient to ensure smooth transitions. While the validity period nesting implies that CA1->EE1 and CA2->EE2 will nest, CA1->EE2 and CA2->EE1 might not nest -- and this is fine.

Summary: you cannot rely on validity period nesting, and you should not try to enforce nesting when validating certificates.


How can I convert my encypted PGP secret key for use performing SSH authentication? I wish to covert my PGP key (RSA) to be used performing SSH authentication. After some searching, I found openpgp2ssh, which appears to be an appropriate tool. Everything works swimmingly for my pubkey:

$ gpg --export "$key" | openpgp2ssh "$key"
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC51Cw3ZxO5TSncaDLzQ89SSZAF7Z9cFR5mv4uhmGw3tDfiaAjNFVjp90YNYi2teveb5EjncIK5RMYQefKpvvsawQZ4KJKbrDFrrQbMmIG67A1qopKxn5rF8QsjzYvrlGSi9pnjfZVN+VfTaspomVpwCpe9oxd8ZlKdViABgBV8p0hL6I4Gqm+I37az9apO4wCvlN8XJMia3J1JxIShyLYGfa2ued5rRFYiCEV3/smtrjycEZ8OYLTLhC/vydhXCSYrCxWHxhv213Uho641cttaL2SlPGDX9Uuq3JfjCoC0Y6EN7/+GV2u9R48/QJpUaOjEhLRm8F/LFRuHDFYJmyNgv11DsRAMvh7psGY2196bBYSdrzfZxxCQDdJrNxNzQvIG33JavMXOiBAbAYxaq7DWWlVPcE3fy+VxYPH+XicqxD58qdWapspJhRxEKzQa7IfUULGQHVg31NYWGsN4dkva2XjV35SZf6M3nrfjz4XitiwH0SOxbXBRKUdZhwCnr+5GcsWkax7Ph6QGvWVP6mgpUDBuMQ+znkUVr8tDkmrm5M6PC6x8SOA0ecdjNKB2NK23A6w4V7lsfMvDl4uBMzxRzXOXLIUXunsZ7MQTV5ymtZvk3oYccnXNxtVZGF2Cu9Wfy+6c+XL+z4Zfc6XvPSgtBDOApV3owL86OOoLO5X3HQ==

However, when I try to convert my private key for use, it displays the following error:

$ gpg --export-secret-key "$key" | openpgp2ssh "$key"
We cannot handle encrypted secret keys.  Skipping!

My secret key is indeed encrypted. I'd ideally like a method to convert my PGP secret key into data that standard SSH programs can understand, instead of relying on nonstandard plugins. Is this possible?

There would be no point in converting a public key if nobody can convert the private key too, meaning this program was created with such a conversion process in mind.  You'll notice the error message reads "We cannot handle encrypted secret keys."

I therefore recommend you remove the private key's password using the passwd command in gpg --edit-key.  You should obviously reencrypt both the old gpg private key and the new ssh private key after conversion.

If you're worried about unencrypted key remaining on the drive, then create either an encrypted partition using encfs, truecrypt, etc., or else create a ramdisk.  You should keep the ramdisk small and short lived to prevent the kernel from swapping it, well unless you find some trick for calling mlock.  Any cryptographic file systems should already mlock their data pages.


Is an ARP scan stealthy? If you want to discover the live hosts on your subnetwork how can you exploit the ARP protocol in order to scan stealthily?

Would an arp scan be picked up as suspicious activity?

Could you spoof the source address of ARP requests to remain stealthy?

No, if you wanted to scan a whole subnet your computer is basically sending out packets saying

Who has 192.168.1.0?
Who has 192.168.1.1?
Who has 192.168.1.2?
Who has 192.168.1.3?

and this might be noticed should sufficient monitoring be in place.

A way to circumvent this is to run a passive scan using something like netdiscover. This can listen for ARP packets and output a list of all IPs encountered.


Detect vulnerability based on IIS log Is there any tools to detect website vulnerability/suspicious request from IIS log?
I was asked to do log review. The logs include IIS Log and Event Log. Is there any tools to detect if there's any issue on the app / server from the log ?

As I assume you want a monitoring tool beside the WAF, there are two well-known tools for this purpose:

ManageEngine event log analyzer
Nagios IIS log monitoring


How to detect when files from my USB were copied to another PC? I accidentally gave my USB to my friend and then I realized it had some important files of mine. Is there any way I can know if he got something from the USB?

No logs are recorded on the USB itself around file accesses. At best, you might know if the files were changed by looking at the file timestamps, which can sometimes happen just by opening them, depending on the program opening them.

But there will be no way to determine, by looking at the USB, if the files were copied.


Is there a passive way to verify DKIM implementations (on DNS level) without triggering an actual email event? I wondered if there is a way to verify the correctness/validity of DKIM implementations without actually triggering an email event or sending an email to an external validator. So, remotely, on any domain.

I was thinking about fetching the DNS TXT records (DKIM selectors). But I suppose only the most common can be checked, leaving the certainty of the correctness of the DKIM implementation basically still unknown. Assuming that the DNS server is well configured and does not dump the whole zone file including DKIM selectors using an AXFR request.

Secondly, if we actually did see the full DNS configuration, or managed to get the DKIM related DNS records with 100% certainty, would it be possible to check the correctness of that implementation (partly) without triggering an email event.

Long story short: I'm searching for ways to identify and pinpoint possible mistakes in DKIM implementations.

No. Obtaining the public key from DNS gives you only half of the picture. You also need a signature to verify against the public key, and that signature is only going to appear in an actual email. Without a signature you have no idea if the policy domain's MTA is configured to even sign outgoing mail at all, or with the right key, or with the right selector, and so on.


Should I set up a VPN for these services? I'm developing a personal project with a few people. I need to setup Continuous Integration service, Jenkins, version control service, Perforce, repository manager service, Nexus, and a Web server.

My thinking is, that only Web server needs to be hosted on a public network, while all the other services, including Jenkins, Perforce, and Nexus should be accessed only internally, on our local network or using VPN.

Is this a good use case for Virtual Private Network? What's the best practice?

Is this a good use case of using Virtual Private Network? What's the
  best practice?

It is a broad question and it depends on many factors (size of your team, user locations, network zones, location of DBs, internal network connections among hosts etc).

To put it simply, you should be only exposing your production web server and your other hosts should be only accessible through VPN. You may want to setup an internal dev web server to complete you CI.


Why use an IV when the message length is only one block? I have read that IV's are used with block ciphers in case a sequence is repeated in a message and produces repeated sequences in the ciphertext.
I see IV's being used in cases where the message is very short, though (e.g.  11 bytes in the example on the attr_encrypted Ruby gem README). Does the use of a unique IV also provide protection in this scenario? If so, how?

Now that I can comment I am taking a part of my answer to comment
IV makes your encryption probabilistic and pseudo-random. No deterministic encryption scheme can be semantically secure and they are not IND-CPA, which is a requirement under all modern ciphers. It also allows for streaming mode ciphers to reuse key for many different messages (same as nonce for stream ciphers). Now, if you don't reuse your key at least not for same message and and the message is only one block, then it is OK I think as long as the block encryption is a pseudo random permutation. Repeating key for same message would allow detection of repeated messages (see ECB penguins) which would not be case with semantically-secure scheme with IV. It is notoriously difficult to avoid if you use same key. But it requires people building their own crypto and for InfoSec, it is much better to use state-of-the-art well tested method.

I have read that IV's are used with block ciphers in case a sequence is repeated in a message and produces repeated sequences in the ciphertext.

This is if you encrypt it in ECB mode, i.e. encrypting each block individually. There are ways to encrypt them without using IV to not detect such sequence. But semantic insecurity inherent in fully deterministic encryption scheme still remains if you do not use IV. For example if you use static number in place of IV (or first encrypted block) in CBC mode, you will likely not detect such sequences in the cipher. But you can not only recognize same messages encrypted with the same key but easily detect full block common prefixes in messages.


How to do client side hashing of password using BCrypt? I am migrating an old application which used MD5 hashing to Spring Security with BCrypt encoding of passwords. I want to encode the password on new user creation page, change password page and on login page before it is sent to the network.

I know HTTPS can solve the problem, but I am still instructed to encode the password before sending it over network as per our organizational guidelines.

What could be the best possible solution to do hashing of the passwords using JavaScript?

Just to explain it further, I am using JCryption API for encrypting the password using AES, so the value transmitted over network is AES(SHA1(MD5(plain password))) now I want to replace MD5 with Bcrypt only. Rest of the things remain unchanged. Will this approach work against "Man in the middle attack" ?

I know HTTPS can solve the problem, but I am still instructed to encode the password before sending it over network as per our organizational guidelines.

This really defines your situation.

Basically, you have a simple solution that you should use anyway (use HTTPS), if only because without HTTPS an active attacker could hijack the connection after the authentication step, regardless of any "encoding" and hashing you use for the password (an attacker who is in position to do a Man-in-the-Middle attack will succeed regardless of how much you ritually dance with hash functions and encryption). Then, you also have a guideline that is both idiotic, and administratively unavoidable. Your problem is then: how can you do things properly, and still comply with the "guideline" ?

Note that the guideline makes little sense at several levels. Not only does the lack of SSL makes the protocol vulnerable to hijack; but also any kind of "encoding" does nothing good against passive attackers either. The reason is that if the protocol is "the client shows the 'encoded' password" then a passive eavesdropper will simply look at that "encoded password" and send it himself -- thus, that kind of encoding does not actually improve security in any way. It just makes some people feel more secure because they understand cryptography as some kind of barbecue sauce ("the more we sprinkle everywhere the better it gets").

What I suggest is that you do the following:

First, try to sell the idea that "HTTPS" incarnates the 'encoding'. In other words, by sending the password inside a SSL tunnel, you are already complying with the guideline, since the password is duly encoded (and, really, encrypted), along with the rest of the data.
If the stupidity infestation is more serious and some auditor (let's call him Bob) still throws a fit about your lack of "encoding" then try applying some reversible encoding on the client side. E.g. before sending the password, apply Base64. This means that if the password is "bobsucks", what will be sent (within the SSL, of course) will be "Ym9ic3Vja3M=", and Bob will be happier, because the latter string is obviously a lot more secure.

The important point here is that since the requirement does not make sense, the solution won't make much sense either.


Multiple gateways (Whonix with Tails)? I've been reading Whonix's documentation and threads here to be more anonymous and secure.

For the best anonymity Whonix recommends having two different computers, one being the gateway and the other being the workstation.  On the workstation, for the best anonymity and security, would it be wise to run Tails as a LiveCD or USB, along with the Whonix setup?  I was unsure whether I should run Tails in a VM under Whonix workstation, run Tails as a LiveCD and the Whonix workstation as a VM, or just run Tails/the Whonix workstation.  I assume that would provide the benefits of both operating systems?  I'm not sure.  (I've also had thoughts about running QubesOS and/or corridor as well, but then I had the thought that multiple types of OS's might increase my attack area).  I have my gateway planned and almost setup but I do not have my workstation setup.

(As a side note, when referring to Tor -> Tails over Tails -> Tor for security, does that mean to run Tails as a LiveCD and use Tor browser, or use Vidalia and Tails in a VM? I'm guessing the former. I know Tails > Tor is Tor in Tails, however I couldn't come up with any way to do Tor > Tails without using my setup at the beginning of the post.)

Which configuration that I have mentioned or your own idea provides the most anonymity?

Never use Tor two times in a row!
This will deanonymize you very quickly. A single Tor process will ensure that it never uses the same relay for both your guard and your exit. If you do Tor twice in a row, the first process might select a relay for your guard, and the second process might select the same relay as your exit, effectively turning a highly-secure anonymity network into a cheap one-hop proxy. Because exit relays change every 10 minutes, the chance that you will get a "short circuit" that deanonymizes you increases greatly as time elapses. This is not a problem if you only use one Tor instance.
Put another way, process A chooses relays A1, A2, and A3 such that A1 ≠ A2 ≠ A3. Process B chooses relays B1, B2, and B3 such that B1 ≠ B2 ≠ B3. Because process A and B are not aware of what relays the other has selected, you may find yourself in a situation where A1 = B3!