How safe/secure are banking applications on Android phones?

Interesting question. In short I would say it is safe at least as your laptop/desktop are safe.

Explanation: mobile OS are far more advanced in their security architecture than your good old windows OS is.

Having said that it really depends on your device, OS and how you use it.

For example devices I would consider safe without any hesitation are unrooted iOS devices and Android Nexus devices. I would say most of these are much safer than most PC's are.

If you root/jailbreak your device you are greatly increasing the risk since you are breaking the defense mechanisms of the OS.

If you allow installation of applications from untrusted sources you are increasing the risk

If your device is not a high end device which gets updates on a timely manner you are at bigger risk (this is why Nexus devices are the safest among android devices)

If you connect to open public WiFi networks you are increasing your risk.

Additionally I would recommend to use the default keyboard and not some 3rd party keyboard. Not because I think 3rd party keyboard on the market are malicious (Apple and Google perform security audits on their markets) but because they might be logging your input for "good" purpose like word completion - but you cannot be sure they are doing it in a secure manner which will prevent your passwords from leaking who knows where...


This is probably far-fetched (and admittedly speculative), but I'll post to hopefully stimulate ideas in others:

In traditional software design, code paths dependency was clear and not dynamically determined.  As such, any security [static] analysis that relied on source-sink trace analysis was "easy" to do. (E.g. finding a code path via static analysis that uses user input in a SQL without having passed through a cleansing function; or user input reflecting back in output opening to XSS; or password making it to log files in cleartext).

However, with modern design patterns like IoC as well as dynamic nature of some languages like JavaScript, source-sink analysis becomes inherently "hard" since sources and sinks aren't [yet] connected at compile time.

So one thing that a JIT compiler could, theoretically at least, do is identify new source-sink paths that are created, and either perform at least some rudimentary type analysis, or perhaps generate an event that a security monitoring app could trap and perform in-depth analysis at runtime.

The hurdle here is not just JIT-based source-sink identification in inexpensive way, but also that security type analysis on top of it is [currently] is prohibitively slow (AFAIK).  But perhaps some rudimentary type analysis may be done at runtime in at a reasonable performance expense.


Javascript and jQuery not secure over https

I serve my entire site over https, jquery included.

The trick is to use a CDN for jQuery that supports https, or deploy the code to your own site and include it from your domain. In code, for example:

<script type="text/javascript"
        src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>

Works fine and will show up as a secure element.

Now, is that actually secure? Well, I generally trust Google APIs as a CDN and the content I have is not that crucial - however, if I wished to ensure I had total control of the jQuery deployment, I could just host it myself:

<script type="text/javascript"
        src="https://mysite.com/static/js/jquery.min.js"></script>

Both will work fine. Bottom line: you do not have to deploy jQuery from the CDN, however, if you want to, at least one of them supports https (others may, I looked no further).

An aside to consider - one of the reasons for accessing code from the CDN was to always have the latest version of the jQuery code. Deploying it yourself, you do lose this immediacy - you also gain a slight buffer against breaking updates, although hopefully that shouldn't be an issue.


Actually there is a way to mark a string element as "unsafe" and it is called prepared statements. A prepared statement is a piece of SQL code which is hardcoded in the application source, i.e. a "safe string", but with a few place-holders for parameters: each place-holder really means: "when it comes to executing this SQL statement, use the argument string, but take care that the argument may be 'unsafe', i.e. may contain anything in a potentially hostile way".

That's exactly the mechanism you are looking for: a way to mark parts of a SQL statement as "unsafe" and thus warranting some extra automatic "resafing".

Some people use manual, non-automatic methods to "make strings safe", with functions such as mysql_really_really_espace_string_this_time_I_said_please(). These manual methods are deeply unsatisfying, inefficient, and occasionally fail because they rely on some PHP-provided method to be fully aware of all the details of the syntax of statements accepted by MySQL, a distinct software package, potentially upgraded separately, and written by distinct developers who do not necessarily synchronize with PHP developers. With prepared statements, the "escaping" (or equivalent mechanism) occurs deep within MySQL itself, and we can assume that MySQL, at least, agrees with itself, avoiding these problems.


If you want to hide that stuff from your ISP check out the different VPN providers out there like PrivateInterNetAccess or BTGuard. There's a ton of others out there too. It's not that expensive and you get an encrypted tunnel to the VPN provider. Now you just have to trust the VPN provider :)

Another thing you can check out is tailsOS. This is a virtual machine that will route all of your traffic through the tor network. On the tor network you don't really want to use any of your personal accounts because anyone can setup an end node and anyone can sniff on that end node.

The NSA and the other TLA's out there already have access to google, facebook and god knows what else so if you send email through google they will have it no matter how many VPN's you use.


What steps can I take to identify what type of compromise of my computer has occured

Alright, so I'm not going to outline an entire incident response procedure, but I will give you a place to start.

Download and run this tool.  It is basically an in-depth snapshot of running processes on your machine.  If you do have something running on your machine, 9.5 chances out of 10 it will come up in the hijackthis report.  Now I will also say that if you're new to this type of thing, the resulting report i fairly hard to process, but if you're on other forums talking about this, than they're going to want to see that report.

Also, i recommend that you take a look at the proposed answers to this question which outline some general steps that one can take to mitigate threats.  Like the responses there say, the only foolproof way to make sure you're not infected is to start from scratch;  Wipe the disk and start over.

One last comment, if you do happen to find out that you have x or y rootkit/malware you can then research for the tool that removes it best.  I know there have been a bunch of times where kaspersky rootkit removal tools have saved my rear-end.  But I must again caution that if you remove one entity it does not mean that you've solved your problem.  When you are able to remove malware you have no way to know if that's the initial attack, the result of a bigger issue, or the only case of malware on the machine.


Why is it wrong to *implement* myself a known, published, widely believed to be secure crypto algorithm?

The reason why you want to avoid implementing cryptographic algorithms yourself is because of side-channel attacks.

What is a side-channel?

When you communicate with a server, the content of the messages is the "main" channel of communication. However, there are several other ways for you to get information from your communication partner that doesn't directly involve them telling you something.

These include, but are not limited to:

The time it takes to answer you
The energy the server consumes to process your request
How often the server accesses the cache to respond to you.

What is a side-channel attack?

Simply put, a side-channel attack is any attack on a system involving one of these side-channels. Take the following code as an example:

public bool IsCorrectPasswordForUser(string currentPassword, string inputPassword)
{
    // If both strings don't have the same length, they're not equal.
    if (currentPassword.length != inputPassword.length)
        return false;

    // If the content of the strings differs at any point, stop and return they're not equal.
    for(int i = 0; i < currentPassword.length; i++)
    {
        if (currentPassword[i] != inputPassword[i])
            return false;
    }

    // If the strings were of equal length and never had any differences, they must be equal.
    return true;
}

This code seems functionally correct, and if I didn't make any typos, then it probably does what it's supposed to do. Can you still spot the side-channel attack vector? Here's an example to demonstrate it:

Assume that a user's current password is Bdd3hHzj (8 characters) and an attacker is attempting to crack it. If the attacker inputs a password that is the same length, both the if check and at least one iteration of the for loop will be executed; but should the input password be either shorter or longer than 8 characters, only the if will be executed. The former case is doing more work and thus will take more time to complete than the latter; it is simple to compare the times it takes to check a 1-char, 2-char, 3-char etc. password and note that 8 characters is the only one that is notably different, and hence likely to be the correct length of the password.

With that knowledge, the attacker can refine their inputs. First they try aaaaaaaa through aaaaaaaZ, each of which executes only one iteration of the for loop. But when they come to Baaaaaaa, two iterations of the loop occur, which again takes more time to run than an input starting with any other character. This tells the attacker that the first character of the user's password is the letter B, and they can now repeat this step to determine the remaining characters.

How does this relate to my Crypto code?

Cryptographic code looks very different from "regular" code. When looking at the above example, it doesn't seem wrong in any significant way. As such, when implementing things on your own, it might not be obvious that code which does what it's supposed to do just introduced a serious flaw.

Another problem I can think of is that programmers are not cryptographers. They tend to see the world differently and often make assumptions that can be dangerous. For example, look at the following unit test:

public void TestEncryptDecryptSuccess()
{
    string message = "This is a test";
    KeyPair keys = MyNeatCryptoClass.GenerateKeyPair();

    byte[] cipher = MyNeatCryptoClass.Encrypt(message, keys.Public);
    string decryptedMessage = MyNeatCryptoClass.Decrypt(cipher, keys.Private);

    Assert.Equals(message, decryptedMessage);
}

Can you guess what's wrong? I have to admit, that wasn't a fair question. MyNeatCryptoClass implements RSA and is internally set to use a default exponent of 1 if no exponent is explicitly given.

And yes, RSA will work just fine if you use a public exponent of 1. It just won't really "encrypt" anything, since "x1" is still "x".

You might ask yourself who in their right mind would do that, but there are cases of this actually happening.

Implementation Errors

Another reason why you might go wrong implementing your own Code is implementation errors. As user Bakuridu points out in a comment, bugs in Crypto code are fatal in comparison to other bugs. Here are a few examples:

Heartbleed

Heartbleed is probably one of the most well-known implementation bugs when it comes to cryptography. While not directly involving the implementation of cryptographic code, it nonetheless illustrates how monstrously wrong things can go with a comparatively "small" bug.

While the linked Wikipedia article goes much more in-depth on the issue, I would like to let Randall Munroe explain the issue much more concisely than I ever could:

https://xkcd.com/1354/ - Image Licensed under CC 2.5 BY-NC

Debian Weak PRNG Bug

Back in 2008, there was a bug in Debian which affected the randomness of all further key material used. Bruce Schneier explains the change that the Debian team made and why it was problematic.

The basic gist is that tools checking for possible problems in C code complained about the use of uninitialized variables. While ususally this is a problem, seeding a PRNG with essentially random data is not bad. However, since nobody likes staring at warnings and being trained to ignore warnings can lead to its own problems down the line, the "offending" code was removed at some point, thus leading to less entropy for OpenSSL to work with.

Summary

In summary, don't implement your own Crypto unless it's designed to be a learning experience! Use a vetted cryptographic library designed to make it easy to do it right and hard to do it wrong. Because Crypto is very easy to do wrong.


How do I run a security check on my WordPress server?

Here are some guides:

General WordPress hardening: http://codex.wordpress.org/Hardening_WordPress

More in depth including some server stuff: http://wpsecure.net/secure-wordpress/

If your server itself is secure, most problems are user related, meaning your plugin or theme has malware.

You can run a malware checker: http://wordpress.org/extend/plugins/wordfence/

It's very advisable that you remove plugins, revert to default theme , back-up and clean the DB and do a fresh install.


How to forward HTTP/SOCKS proxy on same port to SOCKS server?

If you want to run any program through proxy server without setting proxy (with network api-hooking) you can use to ProxyChains .

If you want to forward your website or any protocol on specified port and accessing without proxy (Transparency) you can use to DeleGate .


Is Aria2 downloads detectable by web servers?

It is not much known about this specific site and how it works. But from your description I will assume that they are streaming the video to a flash based video player  while you watch.

In this case there will be a significantly different traffic pattern between online viewing a video and downloading a video: in the first case small segments of the video will be loaded (only what is watched within the next minute or so) and downloading all parts will take around as much time as the length of the video. In the second case instead the whole video will be downloaded at once within a time considerably shorter than the length of the video. Additionally the user agent of the downloading client might be different and it might also not send any cookies inside the HTTP request, probably contrary to the intended online viewing.

It is unclear if the providers of the online course will actually look at such details to find out downloads they consider illegal. But if they want to detect such downloads I'm pretty sure that they could achieve this.


Yes, if you're watching the traffic, you can still tell which address a person is connecting to whether or not you can see the contents of that traffic. That's the nature of IP packets. There's no way around it. Then it's just a matter of doing a reverse-lookup on the destination IP to see it's owned by Facebook or Twitter.

You can shift the problem elsewhere by using a VPN to connect to some "safe" location, perhaps at work, perhaps at a datacenter. If all your IP traffic is tunneled over that VPN, then someone watching the tunnel can't tell what sites you're visiting.

However, someone watching the traffic at the far end of the tunnel, perhaps at your datacenter or at your office, is again able to see the traffic and make usage judgements just as your ISP can now.

Tor works on the same principle as a VPN, except that with Tor, the VPN is to some unknown endpoint somewhere out on the Internet, following a series of unpredictable hops that's difficult to trace.


Is it possible to create a pfx file without import password?

Yes, it is possible:

openssl req -x509 -newkey rsa:4096 -keyout PrivateKey.pem -out Cert.pem -days 365 -nodes

openssl pkcs12 -export -out keyStore.p12 -inkey PrivateKey.pem -in Cert.pem

  Or is it possible to remove the import password from pfx file that
  I've already created?

Yes, it is possible:

openssl pkcs12 -in old.pfx -nodes | openssl pkcs12 -export -keypbe NONE -certpbe NONE -out new.p12

Conversion from .p12 format to .pfx format is possible by just renaming the file.

Hope that helps!


What risk analysis methodologies should I use?

I suggest reading Krag Brotby's Information Security Management Metrics book for coverage of most of the relevant risk analysis frameworks that are usually tailored to a specific kind of risk (e.g. financial analysis for information security management programs or risk management programs could use ROSI, ALE/SLE, VAR, cost-effectiveness, etc).

I also suggest looking at FISAP and IIA GAIT


Why hasn't the one-click attack taken over the world?

You don't describe the attacks you envision in detail but regarding classical drive-by-downloads:

Browsers like Chrome and Firefox get automatically updated since a long time, i.e. they don't rely on the user to update the browser anymore. Also, browsers got better sandboxes in the last years so that the impact of an attack got less severe.
Same is with OS like Windows which also more and more enforce updates.
To attack lots of users the attacker needs to make users visit a site spreading these attacks. Modern browsers have builtin blacklists so that once such attack gets found the site spreading the attack and maybe similar sites gets blacklisted and the user cannot visit these sites anymore and thus cannot get attacked.
Major attack vectors like Flash and Java got closed, either by disabling the relevant plugins forever or at least for most sites.

In other words: there are less vulnerabilities now, they are harder to exploit than in the past and it is harder for an attacker to infect lots of users without being detected and quickly blacklisted. These things together make drive-by-download attacks much harder to do and much more costly for an attacker. The attackers therefore move to different ways to attack users: while attacks via web went down in the last years attacks via mail actually increased.

Also, even in the past where drive-by-downloads using Flash, Java or ActiveX where kind of easy, the sites spreading drive-by-downloads where quickly blacklisted by the browsers and by antivirus products or the sites were taken down. Thus these attacks were never as omnipresent as necessary to hack almost everybody.


Security on Ubuntu 12.04 LST Server for Business App

First of all:

create a user to run your PHP code as who has no more user rights than needed, including being jailed within his user context
configure suphp
get a hardening guide for ubuntu and follow it thoroughly
configure apparmor
limit user access and have a remote logging tool set up
implement auditd for sensitive folders
set up SSL with a valid certificate (443) if your app handles sensitive information

For MySQL preferably you have a table to which you can only add records. Every record has a field "deleted, to which your user mysql application user can have access. This record can be set to True or False. Your user can insert rows but cannot delete any, he can also only update those fields within a record which should be updated. Deleting can be done by setting True or False (your application needs to account for this).

Use as much stored procedures as possible, off-load as much database logic to your database as you can.

Configure a WebApplication firewall and HIDS.


Technically, not as stated. AES-256 requires a 256bit key. SHA-512 will output 512 bits so unless you chop off half of the digest it will not work.

A better solution is to use a standard and well tested key derivation function such as pbkdf2.

Don't roll your own crypto unless absolutely necessary. Use vetted constructions.


How to prove to friend I have solution to puzzle (without revealing it)?

You can use a zero-knowledge proof to demonstrate that you have a solution to a general class of problem. (For example: "I can efficiently find the prime factorization of any number. I won't tell you how I do it, but I'll prove my ability by quickly factorizing any number you throw at me.") However, here, the solution is how you solved the problem; it's tautological to say you can't show how you solved the problem without giving away how you solved the problem.

You could secretly but provably declare your solution via cryptographic commitment. For example, you publish a hash of your solution and then later publish your solution. That allows you to prove that you had the solution for at least as long as the hash has been public. However, it only becomes clear that the secret you committed is a valid solution after you make the secret public. (This approach will allow Paul to compare his (non-)answer with yours -- simply compare hashes, using a standard format -- but it will not prove anything to Ollie.)

For Ollie, you need some way of demonstrating a solution to a different problem that maps onto the actual problem in some provable way. I briefly considered some kind of fully homomorphic encryption, but I don't see how you could homomorphically demonstrate the problem in a way that 1) doesn't allow your friend to decrypt it and 2) still allows your friend to verify the result. For example, consider an attempt at an iterative zero-knowledge proof with a homomorphic scheme that can encrypt (Enc) with a public key and decrypt (Dec) with a private key:

Show your friend Enc(1), Enc(5), Enc(6), and Enc(7) in a random order, and separately show Enc(21). At this point, your friend may stop these steps, demand the private key and verify that you are not lying about the values of the numbers. (This prevents you from using the wrong values, since you'd probably get caught if you played enough times.)
Perform the necessary mathematical operations on the first four encrypted values to produce 21. (This step gives away the necessary operations, which is suboptimal, but it does not reveal which values go with which operations.) At this point we can no longer give your friend the decryption key, or else he will be able to view the entire solution.
Perform a homomorphic equality test of the result from step 2 against the Enc(21) from step 1. This produces an encrypted boolean.

There is no way to allow your friend to decrypt the boolean without also allowing him to decrypt every other value, which would reveal your solution entirely. Therefore, there is no way to verify to your friend the correctness of your solution.


For proxying, it is possible to use Burp for android: https://systemoverlord.com/blog/2014/07/13/passing-android-traffic-through-burp/

(this second set of instruction assumes you are using an emulator)

http://resources.infosecinstitute.com/android-application-penetration-testing-setting-certificate-installation-goatdroid-installation/


Someone is trying to access my mail account, what safe actions can I take?

As far as I can tell, gmx does currently not offer 2FA. That is unfortunate but not necessarily catastrophic.

Do you have to use the address to send e-mail? If not you might be able to get around the problem by just forwarding incoming mail to another account, preferably one with 2FA enabled. After you set up a forwarding rule, you can put a really, really long and secure password (50+chars) on the account and save it somewhere safe.

Otherwise you'll probably have no real chance to secure the account itself.

You are currently using passwords with a length greater than 20 chars, I hope? If not, start doing so immediately. Use a password safe so you don't have to memorize them.

Also, please get the gmx security team involved. Probably it's just skiddies or bots (I had an attack like that on an old address I don't use anymore) but if not they might be thankful for a hint.

Note that I mentioned using a long password and not one drawing from a large character set.

The complexity of the character set does not by itself make your password better. Length runs circles around complexity while juggling chainsaws.

See this relevant xkcd comic for a visual explanation.


Custom extensions to commonly used ciphers?

You are right in that SHA-256 only is a bad choice for password security. But, adding "secret steps" is not a good idea in cryptography, because there will be a time these secret steps will be public. Instead one uses random salts or much better uses algorithms specifically designed for this class of problems.

In the case of passwords I recommend to read the Password Storage Cheat Sheet at OWASP to find out how to do it properly. See also Is my developer's home-brew password security right or wrong, and why?.


Windows Certificate Services: Is it possible to enroll a SmartCard certificate AND have key archival?

The client-side CSP (the Smart Card CSP in this case) must support key archival for key archival to function:

  CSP support for key archival operations
  In order to securely transmit and archive private keys, CSPs on CAs and domain member computers must support symmetric and asymmetric encryption. Additionally, support is required for generating exportable keys, either by manually submitting a certificate request and selecting the option to allow the key to be exported or by using the CRYPT_ARCHIVABLE flag with the CryptGenKey function during programmatic key generation.

Source: Troubleshooting Key Archival and Recovery

The idea of smart cards (vs software private key storage) is that the private key never leaves the card. However, according to the authoritative Brian Komar, Smart Card CSPs can support the CRYPT_ARCHIVABLE flag:

  If a smart card fails, the encryption private keys stored on the smart card are lost. If the smart card cryptographic service provider (CSP) supports key archival (through the enabling of the CRYPT_ARCHIVABLE flag), the private key is archived at the issuing CA.

Source: Windows Server 2008 PKI and Certificate Security book

That said, I would strongly recommend not exporting the smart card private key in the first place as this undermines the security provided by a solution that uses smart cards.

I don't know what your requirements are, but there are broadly speaking two functions for certificates: signature and encryption.

If you are using your smart card certificate for the encryption of data, you might be better off archiving or backing up the symmetric encryption key used to encrypt the data instead. This could be achieved through the use of a 'Data Recovery' certificate also stored on a smart card, which is used to encrypt backup copies of the symmetric encryption key. The legacy Microsoft Encrypting File System is a well-documented example of a system that operates in this way.

If you are using your smart card certificate for the signature (client authentication, digital signatures etc), I would again recommend avoiding key archival completely:

  Private keys that are used for signing should never be archived or recovered because the potential for more than one person to possess and use a private key introduces non-repudiation issues.

Source: Active Directory Certificate Services PKI Key Archival and Management


Is hashing schema information for client when generating SQL queries more secure?

It would be security through obscurity so no, it wouldn't improve security. It's been shown time and time again, if your only defense is that "nobody knows the mechnanism in place, then all it takes is for one person to stumble across it and, within minutes, hundreds of people will know.

It MAY make things harder, but it just takes one witty person to deobfuscate your scheme.


Difference between Form Post Response and Authorization Code

I think I found some explanation here: https://auth0.com/docs/protocols/oauth2#how-response-mode-works

form_post: This response mode is defined by the OAuth 2.0 Form Post Response Mode specification. A successful response is 200 OK and the response parameters are embedded in an HTML form as hidden params. The action of the form is the redirect_uri and the onload attribute is configured to submit the form. Hence, after the HTML is loaded by the browser, a redirection to the redirect_uri is done.

For example, a response might be:

HTTP/1.1 200 OK
<html>
 <head><title>Submit</title></head>
 <body onload="javascript:document.forms[0].submit()">
  <form method="post" action="https://my-redirect-uri.com/callback">
    <input type="hidden" name="state" value="klsdfY78FVN3sl6DWSjsdhfsd8r67832nb"/>
    <input type="hidden" name="id_token" value="eyJ...plD"/>
  </form>
 </body>
</html>


Does HTTP protocol interpret contents of cookies and query strings in URL, whereas it doesn't interpret message bodies?

Let us try to answer the questions one at a time:

  Is it correct that putting user passwords ..., while web applications do? Does HTTP know to look for user names and passwords or for other specifics in message bodies?

At the HTTP level, the body is an opaque stream of bytes. But it is common to use HTML form answers to give passwords for form authentication. Then, it is not processed at HTTP level, even if it uses an encoding which is mainly (if not only) used during HTTP exchanges.

  Since user passwords can also be put into cookies and URLs as query strings (although bad idea), I was wondering if these two ways are also at the web application level not at the HTTP level? Does the HTTP protocol also not interpret the contents of cookies and query strings of URL? Does HTTP specify server to look for user names and passwords or for something else in cookies and query strings?

The query string is a representation of a mapping field => value, where one field name may be used more that once. The interpretation on the meaning is left to the application.

The content of a cookie is also an opaque bytes data which can only be interpreted at application level. The HTTP protocol only specifies how cookies are exchanged.

  In summary, does HTTP protocol interpret contents of cookies and query strings in URL, in the same sense that it doesn't interpret message bodies?

Definitely not. At the HTTP protocol level, the content of cookies, query string and body are all opaque.


Deprecation of SHA1 code signing certificates on Windows

I've now found an example of an actual download that was signed using an SHA-1 certificate after 1/1/2016.  I downloaded KeePass 2.31 using Edge on Windows 10.

Edge tells me that "The signature of this file is corrupt or invalid."

If I right-click and select "run anyway", or double-click the file in Windows Explorer, SmartScreen blocks the file:

Ticking the checkbox and clicking Run Anyway allows the file to run normally.  The UAC warning then shows the name of the publisher like it does with a properly signed executable.

Clicking "Run Anyway" when SmartScreen blocks the file removes the "Mark of the web" from the file.  Double-clicking the file a second time in Windows Explorer no longer blocks the file.

The Digital Signature Details dialog in Windows Explorer also says the signature is OK.  It does this even when the file still has the "mark of the web" (i.e. before using the Run Anyway button in the SmartScreen filter):

The file actually has dual signatures.  The first uses SHA-1 for the signature and the second uses SHA-256 for the signature.  But critically, both were made using an SHA-1 certificate.  That is what Windows 7 and later find fault with for downloaded files.  Also, both signatures are timestamped with SHA-1.  Windows 10 will have a problem with that for downloaded files starting 1/1/2017.

It seems that the Digital Signatures Details dialog does not take into account whether a file has the "mark of the web".  It says "this digital signature is OK" for both the signatures on this file.  So to really test whether your files are properly signed, you need to download them from your website like your customers would.

Testing the same download in a virtual machine snapshot of the original Windows 10 that hasn't been updated since August and another snapshot of the 1511 release that hasn't been updated since November produces no warnings.  If I then have the 1511 VM check for and install updates until it says it's up to date, then I do get the warnings shown above.  I did note in my previous answer that the SHA-1 deprecation is pushed out through Windows Update.  So it looks like this is a very recent update, perhaps a post-1/1/16 update.  Make sure your PC has all the latest security updates before testing your download.


The thing about brute forcing a TOTP token is that you have to guess right at the right time.  So, if you don't want to lock a user out after x failed attempts (which is common practice) you can slow failed attempts down to the point where the odds of getting the TOTP right are statistically insignificant.

For example: 6 digit TOTP token has 1,000,000 possibilities.  But the correct key changes every 30 seconds (in the standard implementation of TOTP) so window of success is not how long it takes to exhaust the entire token space, but how many tokens the attacker can get through in a given period divided by the tokenspace, and its still only a chance at success.  Make it impossible to get through the token space in 30 seconds and you reduce the attack to a gamble.

Example: the attacker gets one guess per second.  They can only get through 30 guesses of any given token so the odds of success are basically random.  Using the Bernoulli process of random variables (chance of failure times number of guesses), 24 hours of attacking this way (86,400 guesses) yields only an 8.2% probability of success. At 10 days, it rises to 57%.  So, simply convince your user to change their password, or find some other way to block the attacker (by IP, etc) before that percentage gets very high.


How can an attacker abuse a distributed system?

This post is going to serve as a repository of references possibly related to the problem. Once there is a substantial answer, please copy the contents into it and ping me or the mods. Please feel free to edit this answer to refine the list.

As I've said, CiteSeerX yields nothing useful (its search system isn't exactly top-notch). However, this query on arXiv gives the following results:

Bing-Rong Lin, Ye Wang, Shantanu Rane. On the Benefits of Sampling in Privacy Preserving Statistical Analysis on Distributed Databases.
Wenbing Zhao. A Byzantine Fault Tolerant Distributed Commit Protocol
Petros Maniatis, Mary Baker. Secure History Preservation Through Timeline Entanglement

Search through Google Scholar:

P.Liu, J.Jing. Architectures for Self-Healing Databases under Cyber Attacks
B.Bhargava, L.Lilien. Vulnerabilities and threats in distributed systems (apparently a neat overview)


Can I securely share an HMAC key over a TLS connection?

It's redundant. This is no different, conceptually, from sending an unencrypted API key over a TLS connection.

That said, an HMAC won't prevent all types of attacks against such a protocol. An attacker in the middle can replay and/or withhold messages of their choosing, for one.


How to decrypt a message using only session key?

To encrypt a file for a recipient:

$ gpg -ea -r foo@example.com < file > file.gpg

To get the session key for an encrypted file when you have the private key of the recipient:

$ gpg --show-session-key < file.gpg
...
gpg: session key: `9:901D6ED579AFF935F9F157A5198BCE48B50AD87345DEADBA06F42C5D018C78CC'
...

To use this session key to decrypt the file, without needing the private key:

$ gpg --override-session-key 9:901D6ED579AFF935F9F157A5198BCE48B50AD87345DEADBA06F42C5D018C78CC -d < file.gpg

This information was obtained by simply having a look at the man page for gpg:

--show-session-key
   Display the session key used for one message.
   See --override-session-key for the counterpart of this option
   ...
--override-session-key string
  Don't use the public key but the session key string.


WhatsApp is an open protocol, anyone can message anyone.
Just deleting the message would have been good enough


Blocking insecure iPhones from accessing ActiveSync

Remember that even a device with local encryption may have no passcode lock, and may be backed up via iTunes to an unencrypted volume. If that volume is on a laptop, then it's just as portable and losable.


For a single certificate, a PEM encoded format is common, this is the text/base64 one that is delimited by:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Most systems should accept .crt and .pem extensions for this file type, the former is slightly preferable for a certificate, .cer may work too.

PEM is an encoding of data using base64 for the data, the underlying binary format is referred to as DER format. Certificates in DER format are often named with .der, but may be named with .crt or .cer too.

PEM and DER are encodings, the extensions .der and .pem are sometimes used, regardless of the type(s) of the encoded data. Sometimes the extension indicates the nature of the data (certificate, key, CRL), but not the encoding...

When MIME is involved (as it will be with HTTP, and email attachments), the MIME type is also an important consideration, some clients may rely on, or prefer this, to determine the action for a file.

The PEM format has delimiters which indicate the nature of the data, and lends itself to "bundling" multiple PEM encoded objects in a single file. This is often used to provide multiple related certificates e.g. a CA chain (but not everything will process all certificates in such a file), or a cert/key pair.
PKCS#7 or CMS (Cryptographic Message Syntax) is the preferred way of encapsulating things, notionally it's for signed and/or encrypted messages, but it's valid for it to contain no message, just certificates.

I recommend you:

make your certificate available in a PEM encoded file with a .crt extension
check the web server MIME mappings are present and correct
optionally create and make available a .p7b file containing the cert and CA chain, this will allow clients to update/install anything missing from their local intermediate CA cache and enable proper verification the chain

Unlike PGP, and presumably related to the different design and distribution mechanism, it's not common to publish a certificate fingerprint, though you can do so, and you may also publish your SKI (Subject Key Identifier) to be thorough.

If you're not familiar with OpenSSL use, this reference site or this online tool and command reference should help with converting. Do not under any circumstances upload a .key or .pfx file ;-)


Does a PGP signature provide integrity verification?

Signatures and Fingerprints

  Simply put, do PGP signatures provide file integrity verification in addition to file identity verification?

Yes, they do: but without further investigation, they only verify whether a given key was used to sign; not whom it belongs to (read on below)!

  If I've verified a file's PGP signature, are the MD5 and SHA1 sums of the file more or less irrelevant, as I've already verified integrity?

Yes, unless you haven't been able to verify the ownership of the key, but the other person provided you with the correct fingerprints in a secure channel (by meeting, (video) phone call, ...).

  If I've verified a file's PGP signature, are the MD5 and SHA1 sums of the file more or less irrelevant, as I've already verified integrity?

In fact, OpenPGP also uses hashing algorithms like these (whereas it hopefully shouldn't use MD5 any more, which is considered too weak our days). But digital signing adds information on who signed the software (if verified correctly).

Verifying Key Ownership

Unless you directly signed the software issuer's key, all you know is somebody signed the software. There is no primary certificate authority in OpenPGP, everybody can add a key with arbitrary names, it is up to you to decide which to put trust in. This is usually done by meeting and exchanging the key's fingerprints, but depending on your level of paranoia you might be fine with verifying the key fingerprint against some they put on their website (which then should be transmitted SSL-encrypted together with a reasonable certificate, of course).

Then, there is the concept of the web of trust, which allows to build trust paths from you to the issuer without meeting him directly, by trusting others in-between that together form a chain of certifications (this can actually be compared to the intermediate certificate authorities of X.509). A very short explanation can be found in this answer: What is the exact meaning of this gpg output regarding trust?.


Criminals could potentially use the information that was compromised to steal your identity.  They could then use this information to take out loans or open lines of credit in your name.
To mitigate this, you may want to lock your credit report.  Congress passed a law in 2018 making it free to do so.  By locking your credit report, banks and lenders will be unable to view your credit report without your authorization.  Without being able to view your credit report, they'll be unlikely to give a loan or line of credit to someone impersonating you.
For more info, see the page below on the FTC site about freezing your credit report:
http://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs
Links to pages at the web sites of the three major credit bureaus for freezing your credit report:
http://www.experian.com/consumer/security_freeze.html
http://www.transunion.com/securityfreeze
http://www.equifax.com/help/credit-freeze/en_cp


How to use RSA private key for TripleDES encryption?

You don't!

RSA and 3DES are two completely different encryption algorithms with completely different properties. For a start, RSA uses a key pair (encryption and decryption key, respectively; this is known as asymmetric or public-key cryptography) while 3DES (because DES) uses only a single key for both encryption and decryption (called symmetric cryptography).

If you don't know exactly what you are doing (and not to be disparaging, but based on your question, I get the distinct feeling that you don't), you really shouldn't be doing encryption on your own. There are just far too many ways to mess up, in ways that puts data at risk, even when using well-known and time-proven algorithms like these (let alone if you are designing something entirely of your own).

Instead, you should delegate the task of data secrecy and authenticity to appropriate libraries, perhaps through Python's TLS support (same as your web browser uses when connecting to a HTTPS server), and just ask for a secure pipe to the remote system. The odds of getting that wrong are vastly smaller.


You could use JovalCM.com but I honestly don't see why OpenSCAP or ovaldi would also not work. OpenVAS supports integration of ovaldi in its checks if you set it up in the advanced configuration.

SCAP requires credentials and the output from OpenVAS is also suspect (e.g., lots of false positives, false negatives, and other errors) when performed without credentials and proper configuration. CIS-CAT is one good, commercial alternative to these tools, but there are even better ones. My favorite is Symantec Control Compliance Suite.

My suggestion is to implement as much of a security baseline as you can from:

https://adsecurity.org/?p=3299 (Secure Windows Workstations)
https://adsecurity.org/?p=3377 (Securing Domain Controllers)


TKIP key length and initialization vector size


How to authenticate and forward SSH traffic

Your use case of shielding your GitLab server from outside traffic is commonly solved with a firewall. A firewall can easily be installed locally on the GitLab that will block all incoming traffic except the traffic from the local network. Also a firewall can be installed in front of the GitLab server.

This traffic should still be authenticated using the normal ssh keys used by GitLab.


When, during authentication, should I ask for an OTP token?

From a security perspective, it makes sense to ask at the same time -- that way, an attacker doesn't know what they got wrong. With some services (e.g. Google), the OTP has another option to send a text message, so from a UX perspective, putting it after the password cuts back on spurious texts.


UNC paths:

\\myserver\resource

The types of attacks that use this is sending a word document with an image embedded in it using a UNC path as the reference

\\192.168.0.1\image.jpg

Your machine will try to authenticate to the share to get the image and in doing so pass along the NetNTLM hash.


...  which is then encrypted by the Private Key of the issuer. ... the signature after decrypting it?

It is signed with the issuers private key, not encrypted. Note that with RSA this might look the same, but with ECDSA it works differently.

I want to understand what data is used to create a Hash which is then encrypted by the Private Key of the issuer. Is it certificate contents like CN, Serial no etc?

Everything from the certificate (tbsCertificate) is covered by the signature and thus included in hash, excluding only the signature itself. To cite from RFC 5280
4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.

...

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

I mean with what value it will compare at its side?

Anybody having the certificate  can simply extract tbsCertificate and recompute the hash for verification.


How to request CVE if CNA didn't provide an answer

CNAs can take more than a week to respond. Some are staffed by a small team - sometimes just one person - and if people are on holiday or off sick then there may be delays. If two weeks goes by  and you've got nothing back, that's more of a cause for concern.

If you feel like an excessive amount of time has passed you can opt to ask MITRE for a CVE directly and note in your application that the CNA did not respond. You should supply a timeline of communications to support this.


What's the difference between SSH tunneling and login into the same SSH server and executing commands?

From a security perspective (and only this is relevant here):

In both cases the connection between the local client and A is encrypted (via SSH).
In both cases the connection between A and B is not encrypted (plain telnet).
Additionally the second case opens a listener on port 9000 on localhost which allows every local user on this machine to connect to B (via the SSH tunnel to A) without further authentication at A.


Pure SAML - no, it's not possible.

This is a frequent scenario in regulated industries, e.g. user comes to work in the morning, signs on to a sensitive service, performs tasks, does not sign out at the end of the work day, then takes their device home..and they're able to access the sensitive service. It's a tougher problem to solve if the sensitive service is hosted outside of company "walls". Tougher but not impossible, the devil is in the details.

Assuming you're going with Web Browser SSO profile in SAML, your control point where you can apply your IP/hours constraint is limited to the identity provider. To be more precise, it's limited to the authentication event, i.e. when a user signs in to the identity provider. Subsequent clicks by the user that may launch or target a particular application (acting as a SAML service provider) will bypass the identity provider most of the time. The identity provider will not see the request so you have no way of applying your policy.

If you're okay with doing this at the identity provider during authentication, some SAML identity providers will allow you to implement a policy that looks at hours of operation and/or IP ranges to allow or deny authentication. Some identity providers with more sophistication will allow you to use the change of IP (and/or date/time) as triggers for requiring reauthentication...which would then deny access as the next step.

The usual solution to this problem involves multiple layers where SSO is just one brick in the proverbial wall.


Can the location of a cellphone be pin-pointed?

.. can you pin-point ...

This depends who 'you' are and how exact you need the location.
A mobile phone needs to connect to a nearby base station in order to send the message. Each base station can serve a number of users in parallel and also has a limited reach, which is even more limited in cities because of all the buildings. If you know which base station the phone is connected to you can tell the area where the phone currently is (accuracy can be 50m in cities).

The operator of the network does know which mobile phone is connected to which base station. It will also store these information for a while and will usually provide law enforcement with this information. But as a normal user you don't get access to these information.

For more information see wikipedia:mobile phone tracking.


Is it bad practice to let the user know its hashed password?

It seems needless exposure to me. Hopefully it is not merely hashed, but with a sizeable random per-user salt and a KDF with a lot of iterations. Even so, the intent of the design is to keep it protected on the server, not to send it out to clients.

If as you say, the hidden field is sent out of the server only upon proper authentication, the risk is far lesser (so a hacker wouldn't easily be able to collect hashes by attempting to reset a whole bunch of users' passwords), but it still appears needless.

The reason we are still talking about risk is that end-user systems and networks are far easier to snoop on, than consciously secured servers. So if in this case an attacker has a privileged position on a network that uses SSL stripping at its perimeter, then (s)he wouldn't need to "hack the server" - thus bypassing server-side protections.

We could argue that "the user account is going to be deleted anyway", and to some extent it would be true (lower risk). Still, a cache of used passwords (if they can be derived from the hashes) is nice to have - since password reuse is rampant.


Good question - in a browser there is certificate pinning.
After looking this up I came across the curl flag --pinnedpubkey

  Certificate pinning

  TLS certificate pinning is a way to verify that the public key used to
  sign the servers certificate has not changed. It is "pinned".

  When negotiating a TLS or SSL connection, the server sends a
  certificate indicating its identity. A public key is extracted from
  this certificate and if it does not exactly match the public key
  provided to this option, curl will abort the connection before sending
  or receiving any data.

  You tell curl a file name to read the sha256 value from, or you
  specify the base64 encoded hash directly in the command line with a
  sha256// prefix. You can specify one or more hashes like that,
  separated with semicolons (;).

  curl --pinnedpubkey "sha256//83d34tasd3rt..." https://example.com/
  This feature is not supported by all TLS backends.

Reference:
https://ec.haxx.se/usingcurl-tls.html


Can a USB device read data from the internal HD of a PC when it's turned off?

If the computer is setup to support wake-on-peripheral and boot from USB, then it is possible for a USB device to turn on the computer and boot to its own operating system which would still have access to any non-encrypted hard drives in the computer.  Wake-on-peripheral in particular, and even boot from USB tend to not be default options though and would normally still require manually turning the computer on and altering bios settings (which would also require resetting the BIOS password if one is set, though this is normally trivial.)


I need explanation on how serious these vulnerabilities are?

If I were creating this, I would avoid any type of RFI (whether it can be practically exploited or not doesn't matter). If a hole exists but there seems to be no risk, it's just asking for trouble. I would let the webmaster or whoever you think you should contact know what you found. Linking to some vulnerabilities regarding remote file inclusion will help bring your point across. This is a good resource


Is there any way to send malicious keystrokes to wireless keyboard USB dongle?

In short, yes - for some keyboards. The technique used to intercept and sniff on some (mostly older than 5 years) wireless keyboards can be pretty easily leveraged to allow an attacker to transmit back to the receiver on those keyboards.

You say you are aware of blog posts that discuss how to intercept wireless keyboard keystrokes. If you are, then you know that those methods include breaking the 'encryption' of those devices. The 'encryption' used by those keyboards is as simple as XOR'ing the data with the MAC of the keyboard. Now consider an attacker has successfully obtained the key of the encryption, from there, he/she can use the same radio transmitter they used to sniff to start transmitting, instead of just passively intercepting.

Since this is RF we're talking about, there is no state-full 'connection' between the keyboard and receiver other than the predetermined protocol. This enables the attacker (that now knows the protocol, since he/she successfully sniffed the traffic) to start transmitting to the receiver pretending to be the keyboard.

An HID attack can then take place. The attacker could do many malicious things to the victim machine. Although, if the owner is using the machine, the attack is easily thwarted, simply by injecting random keystrokes or by disconnecting the receiver, so the attacker must initiate the attack at an opportune moment.

Edit: According to daniel's comment, I have tried to make my answer clearer and more accurate.


Are there cases where malicious scripts on websites breached the sandbox of a browser so that files on the user's computer could be accessed?

To keep you up-to date, you can read about the freshly MFSA2015-78 where Firefox sandboxing mechanism is bypassed by violating the same origin policy. The problem  fixed by Mozilla Firefox on the 6th of August 2015. This vulnerability allows attackers to bypass the same-origin policy and execute malicious JS code remotely that will be interpreted in the local file context. This, in turn, allows attackers to read and write files on local machine as well as upload them to a remote server.

Attacks exploiting this vulnerability impacts Windows, Linux and OS X operating systems.

The malicious script violates Firefox sandboxing mechanism by exploiting vulnerabilities of the embedded PDF.js in Firefox.

For example, in Windows OS, the script probes important configuration files to fetch, mainly for credentials. A part of its code looks like this:

You can see the list of the files in which it is interested once your browser is compromised by it.

For Internet Explorer, you may read about CVE-2015-0016 released by the end of January 2015. The vulnerability is lead by TSWbPrxy.exe which is an ActiveX Control module. The vulnerability allows the attack to bypass Internet Explorer sandbox as it is possible to perform remote attack to gain privileges via a crafted pathname in an executable file.

For Google Chrome, you can read about the freshly CVE-2015-1252 in which the sandbox is violated since it is possible for remote attackers to bypass a sandbox protection mechanism or cause a denial of service (out-of-bounds write) via vectors that trigger a write operation with a large amount of data


That "charter" is rather down-to-earth; it does not specify that "TLS should provide confidentiality and integrity" because this is taken to be obvious; instead, the charter is a roadmap to the future TLS 1.3 and thus documents the desirable changes from TLS 1.2.

As for the mailing-list messages you are pointing to, I think you are over-interpreting them. The kind of "middleware boxes" can be, for instance, a load-balancer system that needs to inspect ClientHello messages so that it redirects session resumption attempts to the server which last handled that session. Or a RADIUS server using EAP-TLS as authentication protocol: in EAP-TLS, the EAP layer must recognize the record boundaries in order to wrap them into EAP messages. These are very legitimate, non-evil reasons for systems residing in-between the TLS client and server to inspect the packets and actually understand the unencrypted parts of the protocol.

The dialogue in the mailing-list goes mostly the following way:

We must encrypt all the things ! Our Charter demands it ! Let's change the record header format.
This will break systems which rely on the record format; this may break compatibility with middleware boxes (that I will allude to only in the vaguest terms). Is it really required ? Or is it a Gratuitous Change, that is explicitly forbidden by Our Charter ?
This is needed because content-type field in the header allows for evil traffic analysis attacks (that I won't describe because I don't actually know of such an attack). Traffic Analysis is Very Serious ! Encrypt all the things !
But Our Charter does not talk about Traffic Analysis ! And Traffic Analysis is much harder to defeat than simply encrypting the record content-type headers. Traffic Analysis is Out Of Scope !

and so on, ad nauseam. Interspersed in the exchange are actual bits of information, from which we can conclude that the WG members do not seem to have reached (yet) a consensus as to the level of backward compatibility that TLS 1.3 should have with previous protocol versions. Especially since that compatibility is defined relative to existing, deployed system that interact with the on-the-wire format in various way that are not necessarily well-documented.

However, reading these emails as if the WG was trying to promote some generalized NSA-like spying would be erroneous. This is a classic case of "committee reasoning" when the actual goals and constraints have been insufficiently specified. It can be predicted that the definition of TLS 1.3 will take some time (years) to come to fruition.


Is there any possibility that a trusted CA can perform a man in middle attack?

There are some news articles about existing backdoors on CAs for use by Security Agencies, but the trustworthiness of these news must be checked,

New NSA Leak Shows MITM Attacks Against Major Internet Services

There is no evidence that shows the trusted CAs use their certificates for MITM attacks, because sooner or later will be identified or disclosed and that company will be convicted quickly. So, it seems unlikely that a trusted CA does it.

There are several ways users can detect MITM attacks, even when the certificate seems to be signed by a trusted CA. There are, for example, Firefox plugins available from Certificate Patrol as well as Perspectives that can help users by alerting on “new” certificates that have not been seen before.

Network Forensic Analysis of SSL MITM Attacks


Which cybersecurity job is most likely to be remote

I see a few vCISO roles now and then that are virtual, they would be at the top of the career path. Further down the path you could find pen testing work that is purely virtual, as well as log analyst roles. Truly, you could make most infosec work virtual with the exception of forensics, in-person social engineering, and some incident response. I think the key will be using the right search terms, and using them correctly. Look for "virtual" as a location (to keep from returning "virtual machines" or such from polluting your results. Similarly, "remote" is only good as a location. Listings with many locations listed are more likely to be remote jobs.

PM me for a few good recruiters if you are interested in going that route.


Smart-Screen filter still complains, despite I signed the executable, why?

Applications that are signed with a standard code signing certificates need to have a positive reputation in order to pass the Smart Screen filter. Microsoft establishes the reputation of an executable based upon the number of installations world wide of the same application. Since you haven't published your application as yet (and therefore the reputation hasn't been established as yet), the Smart Screen will continue to flag the application.

There are two solutions: either wait till the application has a large user base and its reputation will be adjusted by the Smart Screen. However, the current working status might prevent users from installing and trusting the application. The second option is to sign it with an EV (Extended Validation) code signing certificate. Applications signed with an EV certificate establishes its reputation right away. To quote Microsoft:

  Programs signed by an EV code signing certificate can immediately
  establish reputation with SmartScreen reputation services even if no
  prior reputation exists for that file or publisher.

You can find further details at Microsoft SmartScreen & Extended Validation (EV) Code Signing Certificates blogpost.


Is blockchain security dependent on number of transactions in time?

Such a feat would require the attacker to find a second-order preimage (a special type of collision) in the hash function. This is generally infeasible in most cases, even with many years of computation.

If the target blockchain system were to use a hash that is broken in a way that allows second-order preimage attacks, this may allow forgery. However, most existing cases of this in standard cryptographic hash functions (e.g. SHA-1, MD5) there are specific bounds on how the collision works and little control over the data which produces a collision. As such, not only would the attacker have to find a collision, but they'd also have to find a collision that's useful.

The use of SHA256 in Bitcoin and other cryptocurrencies is interesting in this regard, as it is a Merkle-Damgård construction hash similar to MD5 and SHA-1, both of which have been proven to be broken in a number of ways. However it is important to note that the inherent weakness in Merkle-Damgård constructions (length extension) is length extension attacks, which are not useful for blockchain forgery. However, the shared construction does imply that lessons learned from breaking MD5 and SHA-1 may be transferable to SHA-256. This is largely speculation, though.


debugging why TLS fails between openssl and some SSL sites

This problem is not related to certificates in any way and cannot be fixed by a certificate.

The SSLLabs report shows that server supports only suites using ECDHE_ECDSA keyexchange, i.e. Elliptic Curve Cryptography. Upstream OpenSSL 0.9.8 did implement ECC, but disabled it by default and you had to read the source to find the magic word ECCdraft to enable it. However, RedHat and therefore CentOS removed (all) ECC from packages built before about two years ago, so that probably won't work for you. You can fairly easily see that the list of offered suites in your ClientHello (hex offset 2E to 56) does not contain any bytepairs in the range C0xx where all the ECC suites are.

In addition, as noted on the SSLLabs report, "This site works only in browsers with SNI support." and OpenSSL does not send SNI by default; you must specify the option -servername $hostname -- which does work in 0.9.8.

However, my 0.9.8zg with ECCdraft and -servername still gets alert 40. The only difference I can find between that and 1.0.0s (with -servername) which does work is that 1.0.0 sends the pointformats (0xB) and curves (0xA) extensions and 0.9.8 does not -- but according to rfc4492 they are supposed to be optional. So even if you had an un-nobbled 0.9.8 you might be out of luck.

I have never had any problem building OpenSSL itself from source on any decent Unix; it's actually one of the simplest packages to build I've experienced. However, you would also need to rebuild everything on your system you want to use the updated OpenSSL, and depending on what those things are that could be much more difficult, especially where source changes are required, as they were in some cases going from 0.9.8 to 1.0.x (and much more from 1.0.x to 1.1.0 if you wanted to move up that radically).

Depending on what you are doing, you might be able to route your traffic through an external SSL/TLS proxy, like squid+bump, that accepts the grimy faded old TLS (or even SSL) you can do, and relays your data to and from other systems using shiny glittery newfangled TLS.


TrueCrypt -vs- MacOS encrypted sparse image - equally secure? Other alternatives?

Is the Apple solution equally secure as a TrueCrypt using the same encryption?

Assuming that there is no "publicly known" security flaw within the file structure of the images created by said applications, the logical strength of said "container" would depend on the encryption algorithm utilized as well as the pass phrase implemented. Although, there are conspiracy theories surrounding TrueCrypt, they are beyond the scope of this question.

  Is there any alternative that can easily be integrated into the OS to encrypt single files instead of whole disk images?

Yes, GnuPG, as stated by "mikeazo". You could generate a key-pair and encrypt your "sensitive" data using the public-key. You could write a script which would encrypt and decrypt, etc, all required files as necessary.

On the note of encryption algorithms, Blowfish, designed by Bruce Schneier, has the following notes based on cryptanalysis work:

  There is no effective cryptanalysis on the full-round version of
  Blowfish known publicly as of 2011. A sign extension bug in one
  publication of C code has been identified. In 1996, Serge Vaudenay
  found a known-plaintext attack requiring 28r + 1 known plaintexts to
  break, where r is the number of rounds. Moreover, he also found a
  class of weak keys that can be detected and broken by the same attack
  with only 24r + 1 known plaintexts. This attack cannot be used against
  the regular Blowfish; it assumes knowledge of the key-dependent
  S-boxes. Vincent Rijmen, in his Ph.D. thesis, introduced a
  second-order differential attack that can break four rounds and no
  more. There remains no known way to break the full 16 rounds, apart
  from a brute-force search. Bruce Schneier notes that while Blowfish is
  still in use, he recommends using the more recent Twofish algorithm
  instead.

  ~ Wikipedia

GnuPG can utilize Blowfish; Blowfish has also been included in the mainline GNU/Linux kernel since version 2.5.47. A list of products utilizing the Blowfish cipher may be found here.

On a side note, the key size utilized by the encryption algorithm (chosen by you) also plays a role in the overall security of said information. Generally, the larger the key (measured in bits {b}), the more computing power required to brute-force said pass phrase.


Is is possible to get the TLS implemetation information of the remote server?

TLS libaries don't reveal exact implementation details like type or version during handshake, i.e. there is nothing like the (easy fakeable) user-agent or server header in HTTP.


Why are CPUs designed in a way so the "meltdown" exploit works?

A couple things you missed:

The kernel memory in question might already be in cache, making fetching the data just as fast as fetching the access bits.  It's a content-addressed lookup for both.  Even if not, there's the TLB.  Full three-level page table accesses are not the common case to optimize for when performance is the goal.
The privilege level itself might be changed by other half-executed instructions in the pipeline.  Until those instructions are fully retired, the privilege level itself is only a speculation.

I wonder if #2 will lead to the discovery of even more vulnerabilities...


I believe that the header results being 2MB large because of the Anti-Forensic splitter: the encrypted master key is splitted in several blocks to enhance the diffusion and make sure that it can be easily erased from the disk.
In particular erasing one single stripe makes the entire encrypted mk irrecoverable.

https://web.archive.org/web/20160517044339/http://tomb.dyne.org/Luks_on_disk_format.pdf

here's LUKS2 specification: https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf

I wonder how one can extract the encrypted master key...


I had a similar issue in the past. Security is a rapidly-changing field, and it's easy for small companies to convince themselves they don't need to worry about security breaches. (and well...if you don't stay up to date with security information, it's easy to remain ignorant!)

As an American company, HIPAA is a great source for information on security and privacy standards in the healthcare industry. You can find their actual policies on their website, but they also have summaries available for their privacy rule and their security rule. (I personally tried reading their full 50-page documents, but they're very dense. Definitely try the summaries first.) Definitely check it out, you might find some good information.

For more information on hacking, data breaches, and malware, you can check out Bruce Schneier's blog. He's been writing this blog for a really long time, and has some truly excellent posts. He also has links to other helpful sources. Here are the links for posts tagged with data breaches, malware, and health care.

While fines can be dependant on states, you can find instances of people suing healthcare corporations over data breaches. Here's an instance of the Arc of Erie County being fined $200k for a security breach. (That instance was an example of HIPAA non-compliance) You can probably find other instances of hospitals and medical companies being sued over poor security practices here if you want some more examples.

Your situation is a tough one to be in. In my experience with employer's with poor security practices, I wrote a report on the security flaws and gave it to my boss when I left the job. I'm fairly certain nothing will come of it, but at least I tried. Good luck.


Is encryption key length limitations by governments norm?

Permission limit for Encryption is 40 bit key per length in RSA algorithms

This is totally nonsensical.

First some history: There was a time when key lengths were commonly restricted, particularly but not exclusively by the US government in export control regulations. (This was because encryption was considered a "dual use technology" with both civilian and military applications, and the alleged aim was to reduce the availability of encryption outside of the US that the US could not break. An easy way to do that is to restrict the key length, and the most accessible means for a government to do so is in national and export regulations.)

This key length was, for a long time, capped at 40 bits for symmetrical ciphers. The limit was eventually raised to 56 bits and later the limit was abandoned completely.

However, RSA is not a symmetrical cipher. It is an asymmetric cipher, which means that it uses different keys for encryption and decryption. There's a lot of math behind how this works, which is not necessary to understand, but which you can read about in Wikipedia's articles on public-key cryptography and the RSA cryptosystem specifically if you are curious. Basically, you pick numbers such that given a subset of those numbers the calculations involved in encryption are easy to do, but the calculations involved in decryption are difficult; you then distribute the set of numbers that make encryption easy, but keep the set of numbers that make decryption easy a secret.

Because this requires that keys have certain mathematical properties, keys must be significantly longer to provide a comparable level of security. RSA keys need to be a few thousand bits long to provide security comparable to that of 128-bit symmetric keys, which is generally considered the smallest symmetric key size that can be considered reasonably secure today. Compare Amount of simple operations that is safely out of reach for all humanity? here on Information Security SE. For RSA, absent a more exact specification, the "key size" generally refers to the size of the public modulus, which in RSA is a multiplicative product of two prime numbers. For RSA these days, the absolute minimum is generally considered to be a 1024 bits modulus, with 2048 bits strongly preferred wherever possible.

A 40-bit RSA key would be absolutely trivial to break.

Even a 40-bit symmetric key would be very easy to break with modern consumer hardware and naiive implementations.

Just to give you an idea, I'm browsing Stack Exchange over HTTPS, and they are using a 2048-bit RSA key.

TL;DR:

I don't know about the legal situation in India, but yes, governments have historically limited civilian access to "strong" encryption. What actually is considered "strong" encryption has changed over time. However, the specific limit as you wrote it is utterly nonsensical; there is no reason to use RSA with a 40-bit modulus, because you pay all the complexity in terms of implementation but gain nothing in terms of security because the key is so short. You would be better off not using encryption at all and knowing that you aren't, than using 40-bit RSA, and it is highly unlikely that any software will even allow you to create a 40-bit RSA key.


Can an attacker with MitM privileges perform denial of service and other attacks besides interception on local LAN?

Can an attacker block traffic

Yes, an attacker can create, modify or even drop traffic.

Why can an attacker block traffic

As all the traffic flows through the attacker's machine they can drop traffic

How can I defend myself

Once you have a MITM attacker you cannot be sure that messages are not being dropped, you can try to detect this with messages that are sent to make sure the connection is live, but this only lets you detect an attack, not work around it when it is in progress.


What are the implications of using the same DH parameters in a TLS server?

There is no known bad side-effect to sharing the same DH parameters with other people / servers. This is in fact the common case in elliptic-curve DH, because generating your own curve is substantially more difficult than generating your own prime modulus for classical DH, and usual implementation of elliptic curves are tied to a specific curve or a small set of curve (because this is easier and more efficient to write that way).

There has been some theoretical concern about how an attacker might invest a lot of work into "breaking" discrete logarithm modulo a specific prime and then reusing the intermediate calculations to quickly break many DH instances which work modulo that specific prime. In that sense, reusing common DH parameters might imply an extra power of nuisance for the attacker. But this kind of cost sharing does not work for all DL-breaking algorithms, and this also assumes that the attacker could break DL modulo the prime, i.e. that the prime was too short or "special form". This would be a much more pressing reason not to use that prime: not that it is shared, but that it is weak.

Thus, using existing, shared DH parameters is not a problem as long as you can make sure that the said parameters have not been specially "cooked" to allow for a fast(er) break. This usually means that the generating algorithm has been fully specified and can be verified to have been faithfully followed (e.g. see these ones).

Using custom DH parameters should work with all clients, because there is no implementation advantage to tying an implementation to a specific modulus (contrary to elliptic curves). As long as your modulus fits in the size requirements of a specific implementation, things ought to be fine (some older implementations have trouble with sizes beyond 1024 bits; other won't like a modulus whose size is not a multiple of 32 or 64 bits).


Mechanisms to detect service abuse in the cloud

It is possible to programmatically discover known pedophile images by hashing the user's files and checking for matches.  Governments request data from Google for criminal investigations so such efforts are conducted in a legal context. Google provides details on the quantity of those requests and references to the legal aspects here.


CSRF Protection for JSON API with Cookie Auth

Yes, if you validate the Content-Type of the POST request, this can't be forged by an attacker in an XHR situation.  Additionally, since you mentioned a Chrome "plugin" (extension?) it's worth noting that Chrome extensions maintain a separate cookie bucket, so a CSRF attack would require that an attacker manages to get your extension to issue a request on their behalf, not just a CSRF attacker in the main browser session.


What are the security implications of a device like Coin?

Coin relies on the loophole that they're not a merchant or a middle-man handling payment data; they're just an electronic form of a physical wallet and the data is always with the customer (on the Coin itself). This is apparent in their FAQ:

  Q. Does Coin have a PCI PA-DSS validation?

  A. The PCI Security Standards Council PA-DSS program addresses payment
  applications used to accept and process payment for goods and
  services. A device such as a Coin is seen as similar to a payment card
  in a consumer’s wallet and the standard does not apply.

Coin loses one aspect of handling a payment card - physical identification characteristics; the name isn't physically present on the card, so is the expiration date and the customer's signature. This will be met with disagreement from merchants as this will make fraud much more difficult to detect by the human cashier employee. (Note: This is one aspect of fraud detection. I'm aware that this can be easily circumvented. The fact is, merchants still train their employees on these practices).

Clearly, this device is targeting the US market where magnetic stripe cards are still the standard.Personally, I see this device massively failing (and I certainly hope so) because most US card issuers have announced that in 2017 they will be implementing a liability shift in cases of fraudulent transactions. This means that any merchant or ATM operator that doesn't use EMV (~Chip&Pin) will be liable for this transaction. Which means EMV-compliant cards will be used more and more.

Since EMV-compliant cards can't be cloned*, this Coin device will eventually die, just like its inventors hipster style.

* Well, they can be, with the help of electron microscopes and fancy laser technology, but let's not get into details on this one.


What practical damage a compromised/malicious third-party JavaScript can cause?

Perhaps the most prolific recent attack involving compromised scripts hosted by third-party servers is Magecart, which targeted scripts for Magento.  This attack compromised thousands of sites, including British Airways and Ticketmaster, and others.  It was used to steal credit card information of hundreds of thousands of users of these sites.  See https://www.csoonline.com/article/3400381/what-is-magecart-how-this-hacker-group-steals-payment-card-data.html for more info.

The attackers launched the attack by modifying javascript scripts hosted on third-party sites (such as Github and various CDN's) that the victim sites incorporated into their own sites.

Preventing this attack is rather simple.  This is exactly the type of attack that Subresource Integrity is designed to defend against.


My guess is that your visitor is owning a Windows Phone.

A windows phone does not announce what SSID networks it is looking for, but instead, it will wait for an access-point to announce its presence before connecting to it. This can be the reason why you never saw your visitors phone - it had no need to waste power or privacy on looking for a network it knew it was not there. [Where've you been?]

The cost of this feature, is that it is not possible to connect to a hidden-network (no ssid) unless you configure it to activley send wifi probe requests. Remember, a hidden access-point does not broadcast the SSID, and the phone does not know it should connect to it.
[Non-broadcast Wireless Networks with Microsoft Windows]

Apple phones on the other hand, has solved this privacy problem by randomizing the source mac address for Probe Requests. You can no longer passively identify a iPhone by its mac address alone - but you should be able to use the list broadcasted SSID's to create an identity.
See for more details:
[iOS 8 MAC address randomization]

I suspect the motivation for Apple was different for adding this privacy feature. Being able to identify customers through wifi probes would be in competition with the iBeacon - but thats my conspiracy theory.

I am still waiting for Android to make a similar move. It should not be that easy to uniquely identify a phone, its current whereabouts and past whereabouts with consumer grade electronics. Remember Wifi Enabled Smart Bins


Analysing a MetaSploit Exploit, can't figure out why a function is not executing

You've made code changes to the Powershell mixin, but for the changes to kick in, you need to reload it. And reloading the module will not reload the mixins it depends on.

You need to:

Either restart msfconsole
Or at the beginning of your module, add this line:

load "./lib/msf/core/exploit/powershell.rb"

And then when you do either reload or rerun, the code changes from the mixin will reapply.

BTW, you are actually better off asking Metasploit questions at: https://community.rapid7.com/community/metasploit

Because there are Metasploit devs there answering questions.


There's a misconception or two in your question.

As a message (file, etc.) hash, MD5 is not insecure because of the “ability to brute force and pick up the result”. Cryptographic hashes are supposed to have three security properties:

One way: Given a hash, it is infeasible to find a message with that hash.
Integrity: given a message, it is infeasible to find another message with the same hash.
Collision resistance: it is infeasible to find two messages with the same hash.

The only property of MD5 that is now broken is the third one, collision resistance. It's possible to craft messages with the same hash. However, for a message that isn't specially crafted, it's still infeasible to find another message with the same hash. MD5 is nonetheless not recommended, partly because it's plausible that better attacks will be found soon that defeat integrity, and partly because many systems that primarily rely on integrity also rely on collision resistance against some high-level attacks.

Taking MD5 and modifying the output would not help with collision resistance in any way since a collision for MD5 would also be a collision for your modified hash. It wouldn't help with integrity either, for the same reason. So your proposal can do nothing against the known defects of MD5.

If you modify an MD5 hash, then it could become harder to find a message with the hash. But only if the transformation you do is hard to invert! For example, if you do some fixed transformation like flip a few bits, that's useless. If you encrypt the hash, that could do it — or not: it depends on the security property that you want to achieve. Remember that the one way property for MD5 is not known to be broken.

So what security property do you want to achive?

If you're using MD5 it as a password hash, then MD5 is not your only problem, or your main problem. For a password hash, brute force searches are a concern. None of the usual message hashes are suitable as password hashes, because they're fast. Password hashes must be slow, precisely to make brute force searches harder — they hit the attacker harder than the legitimate user, because the attacker must try millions of possibilities. Tweaking MD5 cannot possibly help there. If you're hashing passwords, forget about MD5, even if you found it used in one of the millions of broken PHP apps out there. To hash passwords, use PBKDF2, bcrypt or scrypt. If you're even thinking of using anything other than one of these three, read How to securely hash passwords? first — all of it.

For a password hash, the idea of adding a secret component to the hash function is called a pepper. A pepper involves a secret key and some actual cryptography — “change some characters” would be so easy to reverse that it's useless as a pepper. The normal way to include a pepper is to add it to the password and to the salt when calculating the hash. And remember that the pepper must be secret — if it's in your application source, or in the same database or the same backup disks as the password database, it's useless.


Yes, you very probably need to run some check to ensure the authenticity of the request.

Basically, what is it possible from a third party website ?

Send cross site request from html form with either GET or POST method. It is not possible to set custom headers via html forms. It is not possible to use others methods such as PUT or DELETE. See this question or the RFC.
Send cross site request with ajax for whatever method you want (if there is an Access-Control-Allow-Origin and Access-Control-Allow-Methods headers sent by your server) and set custom headers. Please note that GET and POST request are not possible with ajax without those headers while they are with html form !

The different scenarii are as follow :

You use the basic javascript XMLHttpRequest object to do GET or POST request. You are vulnerable since this is possible to do the equivalent request from a cross site using html form ! You can protect your site from csrf adding an extra header such as X-CSRF-HEADER and checking for it server side.
You use $.ajax from jQuery library for a GET or POST request. Your are vulnerable if you don't do any server side check ! jQuery automatically add an header, X-REQUESTED-WITH, while performing $.ajax request, that you can check server side.
You use another method than GET or POST, you are not vulnerable since you can't send cross site request with another method without additional autorization from your website. Still, this is really thine ice (a bug in the browser or HTTP sepcs could change) so you should also protect it against csrf.

The value of the header X-XSRF-TOKEN in your example is at the time I write useless. The most important thing is the presence of the header itself because you can only add a cutstom header with ajax which itself isn't cross site natively possible. Howewer, note that this may change in the future depending of how HTTP specs evolute so that I would advice to check the token value.


Is it possible to implement a secure game without having a reliable arbiter?

If everyone has a complete copy of the game state at time T, and the permitted moves can be deduced strictly from knowing the game state, then it's possible to identify cheating without an arbitrator, though telling who is cheating requires that the majority of players are honest.

Everyone starts the game with a complete copy of the game state (implicit in this being a perfect information game), and making a move involves broadcasting it to all the other players.

Claiming person P1 cheated isn't simply a matter of telling the other players that they cheated.  Instead, a claim of cheating would be for player P2 to tell all the other players "Given game state S, player P1 told me they made move M, which is against the rules".  Everyone can verify this by comparing S against their idea of what the game state should be, comparing M against the move they received from P1, and checking to see that M is against the rules.

At this point, the main issue is distinguishing cheating by P1 from lying by P2.

You can eliminate tampering with moves by having every move cryptographically signed by the player who makes it: if P2's claimed M has a signature that doesn't check, they're lying (if P1 sent a move with a signature that didn't check, P2 would have rejected it).

There's another way of cheating, though: if P1 sends a consistent series of legal moves, but the moves sent to P2 are different from the moves sent to everyone else, it can give P2 a false idea of the game state and induce them to make a false claim of cheating.  If the majority of players are honest, this can be thwarted by having everyone compare what move they think was just made, but if the majority are collaborating with P1, they can lie to P2 about what move they just received.  In this case, I'm not aware of any way to prevent it.


Publish a PDF on a website with MD5 Hash

The best way is to provide the hash as text (hexadecimal string) over HTTPS. Otherwise you could just offer the download directly over HTTPS and avoid adding the hash. The important point here is the security provided by TLS, without it your hash will be useless security-wise.

You should use a robust hash, such as SHA-256 instead of MD5.

If you are not interested by preventing an attack but just want to ensure the integrity of the downloads, you should put the downloads over HTTPS and forget the hash. This way, everybody will benefit from it, not only the users who know about hashes, and it will be a more seamless experience.


Is it possible to encode a Flash exploit with msfencode?

It is not possible to encode the exploit as you would encode a payload. The reason is that the data that is part of an exploit is directly processed by the vulnerable application (in this case Flash). The function inside the Flash binary which process the exploit data won't decode it first. In case of payloads we can encode it because when the payload gets executed, we already have code execution privileges on the box so we can first decode the payload and then execute it.

There are a lot of ways through which you can bypass the signature based IDS rules. I am not sure if you have access to the actual signature code (most probably the regex) but if you have, you can study it and see what it is looking for. In my past experience with Cisco ASA IDS, the signatures were so dump you can practically replace ' OR '1'='1' -- with ' OR '1000'='1000' -- and it would work.


IDEA and DES cipher suites support in TLS 1.2?

Here's my interpretation:

When they write that DES and IDEA have been "removed from TLS version 1.2", they just mean literally that: They are not explained in the TLS 1.2 standard, RFC 5246. Nowhere does it say that you MUST NOT implement them.

If you were implementing TLS 1.1, you might have said, "I'm implementing TLS 1.1, specified in RFC 4346, including the IDEA cipher suite." Now you would say, "I'm implementing TLS 1.2, specified in RFC 5246, additionally incorporating the IDEA cipher suite, specified in RFC 5469."

A modern TLS implementation is derived from a dazzling array of standards, from the IETF and other standards bodies. RFC 5246 alone has dozens of references; even the "Updated by" line lists nine newer RFCs, adding a variety of cipher suites, extensions and other features, and deprecating and prohibiting others.

The official TLS Cipher Suite Registry lists all currently specified cipher suites, with links to each of their RFCs. Indeed, none of the cipher suites currently en vogue are specified directly in 5246. The list in Appendix C is brief, and largely obsolete. ECC was previously specified in RFC 4492, incorporated by reference with minor changes. AES-GCM is specified in RFC 5288. ChaCha20-Poly1305 was recently added by RFC 7905.

So, i don't think implementing IDEA is actually prohibited or undefined. It was just moved from the primary document to a separate standard to save space and discourage use. You can do it — you just probably shouldn't.

(By the way, DES is terrible and insecure. Run far, far away. IDEA is by and large decent, as ciphers go, but there are no defined TLS cipher suites that let you use it with modern key exchange or MAC algorithms, so you'd be missing out.)

On a related note, the standard for HTTP/2, RFC 7540, goes out of its way (and somewhat beyond its own scope) to make a long list of older TLS cipher suites — Appendix A — and encourage HTTP/2 implementations to prohibit them. DES and IDEA are listed. But it's not required, and this has no direct implications for general TLS implementations.


It is in fact the final derived key.
It's not particularly leaky in this context because as the caller you already have access to the raw secret (you need the password to generate the file), as well as once all is said and done you have the file itself which contains the keys in cleartext.
Of course if someone is taking the output of the tool and logging it somewhere broadly readable, well, that's certainly bad.


Android forensics on Samsung Galaxy S7 edge's Voice Recorder

If you have completed the recording and saved it then there are high chances to find it in the memory of your device using some data recovery utility/software (many available paid and free). These is also another linux distribution specifically made of Mobile forensics and pen testing named Santoku linux, You can try its data recovery and forensics tools to get back the recording. If you did not completed or saved even then you can try these tools but chances are low for recovery


How do countries block encrypted protocols like Skype?

Payload encryption means they can't know what the communication content is, but in some cases they can still know what protocol you're using (In this case Skype). This is how countries block Tor, for example.

Methods to detect the protocol being used even if it's encrypted:

IP-based: TCP is not encrypted even if the payload is encrypted (So that computers can route your packets). The country can tell where the packets are going, and block them depending on their destination IP Address.

Port based: Same as above, but based on the destination port. For example: XMPP uses port 5222, if I block all packets connecting to port 5222, I block out XMPP even if it's encrypted (Unless users and servers use non-default ports)

Handshake based: Many (maybe all) encrypted protocols start the connection unencrypted, and then the two sides "shake hands", the handshake envolves sharing the cryptographic data needed in order to begin using encryption, so it isn't encrypted. Packet inspection can work here. For example, the first few packets of the https handhsake are unique, not encrypted and can be indetified.

VPNS are effective against all 3 methods mentioned above because they route everything through an already encrypted connection. TCP is wrapped by the VPN protocol and sent through the VPN Protocol. This means your country cannot see the destination IP, the port, or the handshake because it's all wrapped in an encrypted TCP connection originating from your machine and ending at the VPN server. However, your country might be blocking the VPN protocol in the first place. (Unlikely)


What things should I check for when giving a client control of the filename parameter to C's open() function?

This is a deceptively simple question as it boils down to how can paths be be abused. I for one don't claim to know how many ways they can be abused because there are many. Some of them are platform specific and there was no platform mentioned. You aren't doing any matching of paths for access control, passing off control to different handlers based on the path contents or decoding percent encoding so it's a bit simpler.

The main issue I see with your code is the incomplete check for a absolute path. The desire appears to be that only files in the current directory will be returned and hence the stripping off of a leading slash. This is incomplete though as starting the path with more then one slash will allow an attacker to request files outside of the current directory (eg: //etc/passwd). You can fix this by either stripping any number of leading slashes or by preppending the server root path to the request path. Either would do. Both might be wise.

After the open and error checks you should us fstat to do some sanity checking that what you just opened is just a plain file and bail otherwise. Although not likely to be in the server root, you likely don't want to be reading from a device file. Also some platforms (again, not specified in the question) will happily return a stream of dirent structures with simple open of a directory giving the attacker directory listings.

You need to know the potential oddities of the platform you're on as well (your code appears to be posix but it could be a library layer like cygwin). If you're unlucky enough to be running such on windows you need to consider issues such as whether you want to allow access to alternate file streams (:stream suffix). In particular you would need to make sure you're not allowing the attacker to access dos devices names (https://en.wikipedia.org/wiki/Device_file#DOS).

One last pedantic tidbit. strtok is not thread safe. You don't specify in the question if this was a multi-threaded server or not. If so you have a race condition. Even if it's not multi-threaded I'd change your code to use strtok_r. I once saw a apache mod written for 1.3 which did preforked workers ported to 2.x which usually does threads that used strtok. It was perfectly fine solution for 1.3 but the porters didn't notice the issue when they ported it.


Reason 1 One kind of attack a mutually authenticated SSL connection would protect against is credential stealing XSS.

Typical SSL encrypted connections only authenticate the server. To authenticate the client, the user enters her username/password. Typically then, the user's session id is used to maintain that authenticated connection with the server.

An XSS attack could steal that session id and send it to the attacker. The attacker then uses that session id to gain access to the user's account without needing a password.

MA-SSL would protect against this as the client is authenticated (probably with a client certificate) and no session id is required.

Reason 2 Another reason for MA-SSL is that with the traditional deployment of SSL (server auth by cert, client auth by password), if a server can trick the client into believing the authenticity of the server (e.g., misspelling the domain by a single character and registering a valid certificate), when the client is authenticated, the server now has the ability to impersonate the client. MA protocols based on certificates are much easier to design in such a way that the server cannot impersonate the client after a successful authentication of the client.

NOTE: The use of MITM in the quote you posted seems wrong.