What are the risks of installing a root certificate from Facebook on your phone?

Do you trust that Facebook and everyone they sell the data to will not use it for evil?

Allowing Facebook to install a root certificate on your phone makes it possible for them to intercept any and all communications, even encrypted ones. They will be able to view everything from arbitrary private conversations to banking transactions or online purchases. They will be able to record every password you use on every service if they so wish, even if the password is being sent to a secure website using HTTPS for encryption. You have no way of knowing how they will use this data or who they sell it to.

Facebook makes money not just through advertisements, but by collecting personal information and selling it to the highest bidder. This includes advertising and profiling companies as well as "foreign" governments. The information can be used to formulate the best ways to manipulate you in the future, either to buy a product or to vote in a certain way, as has been done by Cambridge Analytica.

Do you trust that the security of this app is sufficient that hackers cannot exploit it?

Even if you trust Facebook and everyone they sell to not to use this power for evil, there are countless hackers who would love to take advantage of this fact. Normally, your system only trusts root certificates that have gone through extreme scrutiny, having gone through a key ceremony for improved security:

  The actual root key-pair generation is normally conducted in a secure vault that has no communication or contact with the outside world other than a single telephone line or intercom. Once the vault is secured, all personnel present must prove their identity using at least two legally recognized forms of identification. Every person present, every transaction and every event is logged by the lawyer in a root key ceremony log book and each page is notarized by the notary. From the moment the vault door is closed until it is re-opened, everything is also video recorded. The lawyer and the organization's two signatories must sign the recording and it too is then notarized.

Web browsers will not accept root certificates from any entity which has not gone through such extensive measures to ensure the root certificate is secure, but by installing this "Facebook research VPN" and root certificate, you are completely bypassing this process. How much security do you think Facebook has actually put into guarding the root certificate that they are asking you to install?


How can I prevent myself from barcode payload attacks?

After going through the code, I'm not sure that it is supposed to exploit or attack anything. It looks like its only purpose is to encode a payload using barcodes. It would be a nice way to import code into a system using a barcode reader when all other routes may be blocked. After you locate a vulnerability in a system, you can "upload" a payload using one of the these barcodes.

As such, there is nothing to defend against. It is getting the bar code scanner to do exactly what it is supposed to do: convert a barcode into text.


Unable to "trust" self-signed certificate

The error message

  The security certificate presented by this website was issued for a different website's address

indicates that the URL that is embedded in the cert is different from the URL that you are typing into the address bar of your browser. Once you put a cert on a server, browsers will only let you access it through its full public domain name (as a defense against man-in-the-middle attacks).

Are you trying to access your server by its IP address or by a local hostname?


The idea of PFS is that not all keys are equal, when considering risks of ulterior theft. A private key stored in a file may be stolen afterwards, e.g. if the disk fails and is carelessly discarded. On the other hand, a key which resides in RAM only disappears when the machine is shut down or rebooted, and thus is unlikely to be recovered by an hostile entity. In the PFS security model, we care mostly about keys which are not generated dynamically, but stored on physical mediums for arbitrary amounts of time.

When using Diffie-Hellman, it is not the use of DH which grants PFS; what grants PFS is not storing the DH private key. DH or an elliptic-curve variant is often used in protocols which seek PFS, because PFS implies generating a new key pair on-the-fly, and generating a DH or ECDH key pair can be done very efficiently (as opposed to, say, RSA).


Where in a TLS connection can I get the signature of the content sent by the server?

In TLS, neither the client nor server signs any content. The cryptographic signatures that are used in the initial handshake are meant for authentication: the client obtains some guarantee that it talks to the right server, and (if client certificates are used) the server obtains some guarantee that it talks to the right client. However, neither of these guarantees is transferrable: though the client knows that the data it gets comes from the server, the client gets no proof that could be shown to a third party. That's authentication, not non-repudiation.

Even if the client records everything pertaining to the whole connection (all data bytes sent and received, all the negotiated cryptographic keys, and so on), this proves only one thing: that, at some unspecified point in time, the server was, indeed, a TLS server, and has been involved in at least one TLS connection. Everything else, including all the data puportedly received and sent by the server, could have been fabricated afterwards, so it cannot be a proof (in the cryptographic sense).

Thus, you haven't found a way to "get the server's signature of the content it is serving" for the reason that this signature does not exist. If you want the server to sign things, this must be arranged at the protocol level, inside the TLS tunnel: have the server duly sign the data and send the signature as part of what TLS calls "application data". Of course the server will have to be aware of the operation, and this is not part as normal TLS (HTTPS) processing.

Alternatively, have some bailiff or a similar official connect to the server, obtain the data, and sign it himself, thereby guaranteeing (in a legal way) that the server indeed serves these data content.


Is salting a hash more secure than encrypting it?

Encryption is the exact opposite of Hashing.

Encryption is reversible, by means of the key.
Hashing  is not reversible and there for only 1 way.

Now salting protects a hash from being pre-calculated and eliminates the risk  from pre-calculated rainbow tables (as long as there does not exists a rainbow table for the hash and salt combo).

Now Hashing also has a parameter of being 'costly', or in other words the act of hashing must take some time. (at least for passwords) as to eliminate leaking details about the process (e.a. time based attacks).

Encryption does not add any significant properties to the hash and it does not protect against rainbow attacks, like the salting does.

Often encryption is suggested by people that go not understand cryptographic hash functions and encryption. For 1 knowledge proofs (proving the password is correct without revealing the password) hashing is better than encryption.


Securing firewalls for XAMPP on Mac OS X

Apple have very comprehensive hardening guides for OSX, which they publish at http://www.apple.com/support/security/guides/ so you should go through that first.

XAMPP is not meant for production use, so out of the box it is deliberately very insecure. You're not meant to use it for anything serious, so they turn lots of security features off to make it easy to use. You can reverse these deliberate weaknesses by running the lampp security command.

Because it's not for production, there isn't much in the way of hardening guides for it. I see one at http://robsnotebook.com/xampp-security-hardening you could take a look at.

Otherwise you're going to have to look at hardening guides for the specific components (Apache, MySQL, etc.)


Is it possible to force a new SSL session

In SSL, the client and server may engage in an abbreviated handshake only if both client and server remember the "handshake parameters" (in particular the negotiated pre-master secret). The "session ID" is how the client and server advertise their remembrance: the client sends in its ClientHello a copy of the previous session ID, and the server sends it back to acknowledge that this session is going to be reused.

You cannot remove the session ID from the client message without breaking the subsequent cryptographic operations, because the Finished messages at the end of the handshake are computed as hash values over all previously exchanged handshake messages, which includes the ClientHello. Thus, the client and the server MUST "see" the same ClientHello. (However, see below.)

Therefore, to prevent an abbreviated handshake, you have to enforce forgetfulness. SSL servers can be configured not to remember sessions beyond some inactivity timeout; for instance, see Apache mod_ssl directives SSLSessionCache and SSLSessionCacheTimeout. Shutting down and restarting the server may also flush the cache, as long as the cache is kept in RAM (with multi-frontend servers, the cache may be shared with a common database or something similar, in which case cache purging can be more complex).

On the client side, SSL sessions are normally kept in RAM. Internet Explorer, for instance, internally consists of several process that talk to each other, and you have to kill them all to make it forget a SSL session (in practice, this happens only when you have closed all the IE windows).

Your quote, however, is weird:

  Using tools like Wireshark, it's possible to decrypt SSL traffic as the client by logging the (pre)master secret, without using a mitm attack or the server's private key.

Wireshark cannot do that. Wireshark inspects data packets in transit, and from these packets, you cannot infer the pre-master secret without having a copy of the server's private key. That's the whole point of SSL: to prevent eavesdroppers from being able to make sense of the exchanged data. To be able to break into the SSL session from a "network interceptor" point of view, you have to do a Man-in-the-Middle attack, with double impersonation; and this may happen only if you bypass the certificate security model: you have to convince the human user (SSL client) to install a fake rogue root CA key, or to "click through" the red and scary warning that the browser displays when it notices that the alleged server certificate is funky.

If you can "log the pre-master secret" then this means that you have privilege access to the RAM contents of either the client or the server; that access would not use Wireshark, but a debugger. What Wireshark offers is the possibility to use some captured pre-master secret (e.g. see this page); with this information, Wireshark will be able to decrypt the data. However, it does not (and cannot) do the capture itself: this requires direct access to the client or server RAM, or a modified client or server to leak the information. To make an analogy, you cannot do brain surgery over the phone.

If you indeed have a debugger-like access to the client (or the server), then you should be able to manipulate the client (respectively server) to make it "forget" a previous SSL session, thus forcing a new full handshake.


Is there a more precise approach to generate signatures for ClamAV, than regex signatures?

It seems that ClamAV supports both YARA  and OpenIOC. These two methods of writing signatures will let you take a much more specific look rather than just byte sequences. Check out this SANS paper for a bit of methodology.

If you want just a quick idea of what these two frameworks can hone in on check out the documentation for YARA and IOC. Both of these frameworks have a lot more documentation on how to write good signatures that will be good further reading material.


Is it possible to find out the oauth 2.0 client id and secret when an app is communicating with a web service?

If you are distributing your "secret"  to the world with your application then its not longer a secret.   It is not possible to prevent an attacker from communicating to your web service.

You can never trust the client in a client/server architecture.


What are the risks of not patching a workstation OS for Meltdown?

No, you'll have to patch sooner or later.

More seriously, for a workstation-style machine, Meltdown is mostly a concern in the case of malware or existing compromise.  (In that it will allow reading kernel memory and consequent privilege escalation.)  The media have made a lot of noise about Meltdown (somewhat rightly so: for hosting companies, virtual machine hosting, etc., it's quite a big deal) but your average user is unlikely to be affected by meltdown on their workstation.

That being said -- you're unlikely to see a 30% hit.  Most benchmarks of typical workloads show more like a few percentage.  As you point out, you'll either have to never get any more updates or eventually accept the performance hit.  (Unless OS X adds a flag like the Linux kernel has to turn KPTI off.)


What is known about the sirefef/zeroaccess malware/botnet?

See http://techchannel.att.com/play-video.cfm/2012/8/31/AT&T-ThreatTraq-SIfref-DVRbot-Internet-Weather for a video blog on this. Looking at AT&T's 'internet weather', the activity was picked up and they give an analysis of what they found.

The kindsight blog also has information at http://www.kindsight.net/en/blog/2012/06/28/malware-analysis-new-cc-protocol-for-zeroaccesssirefef

http://thehackernews.com/2012/09/9-million-pcs-infected-with-zeroaccess.html


You would normally be correct, however you cannot protect against this MITM vulnerability even if you use a secure cookie over SSL. This cookie could still be MITM'd to inject XSS.
The pen test report is correct - the fact that the XSS mechanism is a cookie gives rise to the MITM vulnerability. This is because the Same Origin Policy for cookies does not treat different protocols and ports as separate origins:

cookies have scoping mechanisms that are broader and essentially incompatible with same-origin policy rules (e.g., as noted, no ability to restrict cookies to a specific host or protocol) - sometimes undoing some content security compartmentalization mechanisms that would otherwise be possible under DOM rules.

Without the cookie functionality, the XSS vulnerability has gone and so has the MITM vulnerability. I aim to explain below by example.
Say you wrote a safe link to a cookie with the secure flag set such as
University Link

The Secure flag will prevent a MITM from reading the cookie value. However, an attacker could MITM any other HTTP connection from the victim to any other site and then insert their own resource reference to your site.
That is, say your victim visits bbc.co.uk over plain HTTP. The MITM intercepts the HTTP request to bbc.co.uk and adds a fake JavaScript resource request into the page to your site, example.com.

They would then be able to MITM this request (because it is plain HTTP) and insert a Set-Cookie header in the response. So they could set the cookie to

to overwrite your secure cookie. Because to the browser the cookie is being set from your domain, it will be readable on both HTTP and HTTPS. When the user next visits your page, this cookie will be read and then rendered to the page  as the server has no way of knowing that this cookie was set over HTTP. Even though the secure flag is set on your original cookie, this cookie can overwrite it and as the server only gets the name/value pairs and not the value of the secure flag, it has no way of knowing that this cookie has now been poisoned.
HTTP Strict Transport Security can protect against this as the plain HTTP connection will be automatically converted to HTTPS and then will be immune to MITM so long as the HSTS policy does not expire. Also your site would still be vulnerable before your user accesses your system using their browser, as HSTS will not yet be established for your domain unless you have it in the preloaded list. Additionally, some browsers such as Internet Explorer do not yet support HSTS.
So in short, it would be better to store these links or any text you would want rendered for the user server-side and simply store a secure token within the cookie that can be looked up within your database. This will prevent any XSS attacks using the cookie. Do not encrypt the cookie value, because if there are any ask the Oracle cryptographic flaws in your system this could still leave you vulnerable. A better approach would be to HMAC the HTML code in the cookie with a secret key held server-side, and then check this MAC is correct before any rendering. This will prevent any HTML code that is set outside of your application from being injected.
Also see Security of an initial redirection from http://example.com to https://example.com


How to communicate how secure your system is to your employer's clients

The answer to your question depends on a number of factors including,

"Who are your clients" - Different companies will want different levels of assurance, for example a bank sending financial data will (hopefully) want more assurance than a coffee shop sharing menus.
"What data are you processing for your clients" - Again this will affect the answer, if there are regulations in play those may lead you to have to provide specific forms of security attestation.

With that said there's a number of strategies you can use, none of them (in my opinion) perfect.

ISO27001.  This is a common one as it's internationally recognized.  As you've done it you'll likely have found that the devil is in the detail, things like the scope of which bits of your business you certify will greatly affect how easy it is to achieve.  Also note that ISO27001 is perhaps more about documenting what you do well rather than necessarily doing all the right things, and that point is quite well known, I'd say.
3rd Party Assurance.  You can get a 3rd party to do security reviews and provide summaries of these which you can give to customers.  this is commonly seen in the technical security world (e.g. Pen Test Reports) and also to an extent elsewhere (e.g. SAS-70).  How convincing these are may depend on what testing you actually have done and how savvy your customers are (i.e. can they tell the difference between a detailed test and a quick superficial test)
Let your customers audit you.  Can be appropriate (or even mandated) for large clients.  has the upside of them being able to test exactly what matters to them, and the downside of having sets of auditors trooping through regularly asking awkward questions.

Ultimately however none of these really work with non-savvy customers.  There is a massive "market for lemons" in security where consumers cannot tell the difference between two companies, generally 'cause they all claim perfect security (ever see a site say "hey security isn't that important to us, but give us your data anyway") and there is no mandated effective impartial standard.

With a savvy customer, I'd recommend asking them what's important to them about security and how they would like to see that proven.


Affordable infosec training for a small organisation

About the security awareness
Many governments publish infosec guidelines dedicated to companies.
Consider consulting:

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-50.pdf
https://www.nist.gov/topics/cybersecurity/national-cyber-security-awareness-month/resources

About the technical skill
Many security challenge websites are free and let your employees learn a lot with fun. I think it's the perfect approach for a small company as this can be managed as a game during the breaks of the day.
I know root-me.org which has dedicated categories (web server, web client, app script, ...)
Another interesting freemium resource is https://pentesterlab.com/ which has a rich catalog of free infosec courses.
A more scholar approach should be to let your employee read the CIS benchmarks guidelines for servers and programs (including mysql) : https://www.cisecurity.org/benchmark/oracle_mysql/ (free but need registration) and the OWASP ASVS framework (for general purpose Web security): https://owasp.org/www-project-application-security-verification-standard/
Finally, you could register to a free (or paid if you have the budget) bug bounty program (hackerone, yogosha, openbugbounty, ...) and learn from the vulnerabilities found by the community.


OAuth - Why exchange the authcode for a token

The "Authzcode," more commonly known as the "OAuth Authorization Code" is used in the Authorization Grant process.  This specific OAuth process is used, when an application needs to ensure that a resource owner's credentials are never shared with the client.  This specific use case can come into play when the client is running untrusted code,  such as an app that needs privileged access.  Below is a quote from RFC-6749:

  The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the  transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially  exposing it to others, including the resource owner.


What are the security implications of losing a paper calendar?

This depends a lot how valuable these information are for the finder, which also depends on who the finder is, what abilities and intentions he has, maybe what city or country you live in (amount of criminality...) etc. And it depends of course about the amount and detail of information in the calendar.

If for example you've put your vacation into the calendar and also where you live then he knows when you are not at home and might rob your home. If he knows who are your friends and maybe when you meet them (calendar) he might try social engineering attacks. If he knows what doctors you visit and how often he might make conclusions about specific illnesses. From the network of friends he might make conclusions about sexual orientation or special preferences which can be used in some countries to blackmail somebody etc.

In other words - something like Facebook could do with all the information collected about you but more physical, with more effort and probably directed against you or your friends.


Did US and UK spy agencies defeat privacy and security on the internet?

There will be a lot of speculation regarding this question. I will try to provide as much information as stated in the articles. I will also update the answer regularly with facts provided in the comments.

Relevant articles to this answer:

NSA: How to remain secure against surveilance
The US government has betrayed the internet. We need to take it back
US and UK spy agencies defeat privacy and security on the internet

First of all I would like to say:

Is this threat real?

Depending on how well we can trust the papers, it should be considered a real threat in the sense that security agencies have succesfully implemented backdoors in software or at encryption end-points. I believe this is probably true as three reputable news papers were kindly requested to not publish  the article. This means that there is a high likelihood that at least part of the story is true.

Have they really broken crypto?

As far as we can tell from the articles they mainly have three strategies:

Use supercomputers (clusters) to brute force encryption protocols. This probably means they can efficiently bruteforce encrypted files.
Implement backdoors into the software which does the encryption.
Make technology companies comply with their demands, some of which may include #2.

Option 2 and 3 suggest that they have not succeeded at real time decryption of, for instance, SSL. As Bruce Schneier stated:

  The NSA deals with any encrypted data it encounters more by subverting
  the underlying cryptography than by leveraging any secret mathematical
  breakthroughs. First, there's a lot of bad cryptography out there. If
  it finds an internet connection protected by MS-CHAP, for example,
  that's easy to break and recover the key. It exploits poorly chosen
  user passwords, using the same dictionary attacks hackers use in the
  unclassified world.

They still require people at either end node to implement a backdoor covertly or make the technology company help them in decrypting traffic passed through their systems. Chances are high they have the encryption/decryption/signing keys of some of the Certificate Authorities, which would allow them to setup proxies and perform man-in-the-middle attacks. Due to the trusted certificates (because they can sign them themselves), these attacks will not be noticed by the users they spy on.

Note that they have proposed a system to perform real time decryption but there are not indicators that they have actually succeeded in building this. All we can do, at this moment, is speculate.

There has also been one case where they, allegedly, backdoored a random generator (according to Wired) used by encryption algorithms.

Please note: Encryption standards are public which means anyone who wants to scrutinize them can look into them. The NSA has made it a lot more difficult to review them though. (Implementations are a whole other thing though.)

Note that for option 2 it seems they specifically target commercial software. If you want to be more confident you're not using compromised software, you should use open-source products and compile the binaries yourself. (Although, theoretically speaking, the compiler could also be backdoored.). The code could be peer reviewed, or you could review it yourself. (Unfortunately, the latter is often not feasible or practical.) Furthermore, this quote from Edward Snowden would also suggest that they haven't managed to crack strong crypto:

  "Encryption works. Properly implemented strong crypto systems are one
  of the few things that you can rely on," he said before warning that
  NSA can frequently find ways around it as a result of weak security on
  the computers at either end of the communication

What are the consequences?

The NSA endangers everyone on a certain system by deliberately installing backdoors. They are not just risking the privacy of those they are investigating, but everyone using the system.
Open source software is less likely to be compromised. It's clearly stated they attack commercial, closed source software. Backdoors are much more likely to be spotted, and spotted more quickly, in open source software.
Commercial software, especially those published in the U.S., are more likely to be backdoored than any other software. (This is personal speculation, but I believe that it would be harder to do in many other regions - e.g.: the E.U. - due to more stringent privacy laws and the fact that multiple governments would often need to be involved. However, this is still no guarantee.)

It also seems that they want to compromise as many internet nodes/hubs (tier 1 providers probably) as possible. This is logical because most traffic on the internet will pass by the tier 1 providers at some point.

The biggest risk is data leaking because of their negligent practices with introducing backdoors. If the NSA is really after you I doubt some crypto will help you to save your ass. They will probably just round you up at some point and make you disappear. The NSA is not generally going to come after copyright infringers or script kiddies/hackers. They're more interested in the hard-core, dedicated (cyber) terrorists. I highly doubt that, unless the have indicators that you are a terrorist, they will use their information to sue you or even pass that information to another agency.

The danger within the NSA is however when someone like Snowden, but who has bad intentions, decides to leak all your private data or use it for personal gain (or any other purpose that is not in the interest of the citizens the NSA tries to "protect"). They have very limited oversight - and much less so publicly - at the moment, which greatly serves to facilitate abuse of the system.

What can I do?

Start by reading the article NSA: How to remain secure against surveilance written by Bruce Schneier.

My personal opinion is that the NSA probably has access to tons of sensitive data and that, even when using strong crypto, they still will be able to get access to sensitive data due to backdoors they introduced in systems or because of the cooperation companies give the NSA.
There are some precautions you can take:

Use strong passwords
Use strong cryptography (websites with SSL certificates should be verified to be running a secure, strong version of TLS)
Use VPN/proxies/Tor (not located in the US or UK - maybe not even Europe - though even they can still be backdoored)

We also need to open up software and protocols, as Bruce Schneier said:

  We can make surveillance expensive again. In particular, we need open
  protocols, open implementations, open systems – these will be harder
  for the NSA to subvert.

My 2 cents

It's also an illusion to think the NSA are the only ones doing something like this. It would surprise me if the Chinese and the Russians (or any other state with a large secret police budget for that matter) didn't have similar programs. For the Chinese we already have indicators (APT-1)  that they are involved in similar practices as the NSA. Does this make it any less wrong/hypocritical of the US/UK? Probably not. As Bruce Schneier said:

  I am saddened to say it, but the US has proved to be an unethical
  steward of the internet. The UK is no better. The NSA's actions are
  legitimizing the internet abuses by China, Russia, Iran and others. We
  need to figure out new means of internet governance, ones that makes
  it harder for powerful tech countries to monitor everything. For
  example, we need to demand transparency, oversight, and accountability
  from our governments and corporations.


Mitigating XSS by ensuring no letter is after an angle bracket

This is safe under two assumptions:

Browsers actually follow the spec.
You only insert untrusted data between tags.

As for #1, I tried recent versions of IE, Chrome and Firefox and they all seem to follow it. But back in the day browsers were very forgiving creatures, so there might be old ones around who would kindly assume you mean

As always, I recommend the OWASP XSS prevention cheat sheet.

Edit: You say no letters. As per this answer you probably don't want to allow <!, </ or <? either, since they could be used to start comments and close tags. Might not lead to XSS, but could still mess up your page with unexpected consequences.


Can't figure out input format for Hashcat salts with odd characters in salt

So, I've figured this out. Hoping leaving it her helps someone as stupid as me in the future.

In hashcat, you can convert the salt string to it's binary values and present it in hexadecimal form, with the --hex-salt option.

So the input file would look like:

F2CCA232766DE6F048F758044451EA1E667FC6587C578AF472C97F3CE3B929B76A7B2842953DCF7B6C63638A58794BC3BCC4DF7CB6783A3E8D18AB2BE056F0ED:04B37BF39123AB2C49FD44F7B845E291D3E1004DB8B2E460AE6E2438FB27B70AF5E1C709

which then, correctly, comes out with the result. :joy:


Is this REST service authentication system secure?

The basic answer is: just use HTTPS, and basic authentication. This is much simpler. The overhead of HTTPS is slight:

A couple of extra roundtrips when a new connection is established. But connections are kept alive between client and server, and closed only when unused for too much time, so this should not matter much. Indeed, a pure-HTTPS solution could be faster than your HTTPS/HTTP mix because it could work over a single connection for the whole procedure.
Some network overhead, about 0.2% for bulk data (SSL record header and padding and MAC); again, this will hardly show up on measures, let alone matter.
Some CPU overhead, but much less than usually assumed. A basic CPU core can encrypt and decrypt data at more than 100 MB/s, even without using AES-NI.

If you do want to use HTTP (after an initial HTTPS phase), then you must account for confidentiality and integrity issues. Your HMAC games may help with integrity, but will prevent replay attacks only as long as the server remembers the last "token value" (or hash thereof). This is state and contradicts the point of REST.


Understanding Key Serial Numbers (KSN) in Derived Unique Key Per Transaction (DUKPT)

8/10 bytes. The standard has always had KSN 10 bytes (80 bits), but allowed smaller values padded on the left with 0xFF,
and many people did or do use 8 bytes. I'm not in a position to say there's a clear pattern either way. If any of the devices
(or systems) you expect to deal with are limited to 8 bytes, then yes use 8 bytes.
As below, it's basically arbitrary now anyway.
You're right nearly everyone seems to use xx-19-21 bits which for 8 bytes is 24-19-21 bits. Remember DUKPT was
originally designed for ATMs that cost many thousands of dollars, so 512K wasn't a troublesome limit;
now people use it for matchboxes. Technically only the counter part (xx-21) matters to the encryption
so you can shift the other boundary(ies?) if your programs, APIs, partners etc. can handle it. OTOH if you stick to convention,
which is easier, nothing says different KSIs must always map to different BDKs.
You can have [FFFF]ABAB00-mmmmm is the first 512K devices for BDK A, ABAB01-mmmmm is the second 512K, etc.,
ABAB50 is the first batch for BDK B, etc.
As long as you only need to manage tens or maybe a hundred batches (50+ million devices) this is fine. If you needed much more than 500+ million then I'd worry about it, but by then you'd have enough clout to change this.
Originally the idea was that KSI would identify the bank or subpart of a bank (ATMs, remember) and be globally unique
so any cryptogram in the clearing network would self-identify/verify who it "belongs to".
Nowadays KSI has basically become arbitrary, so yes pick what you like.
Except I suggest don't use a value that has leading zeros; too many things tend to think leading zeros on
a number-looking (even hex-looking) value are not significant and drop them.
TRSM ID (or device id): yes just use sequential numbers. But beware you often are shown
the 21-19 bits displayed in hex like -00000-ttttt and -00001-ttttt are device 0, -00002-ttttt plus are device 1, ... -FFFFE-ttttt plus are device 0x7FFFF.


SSL - Null Prefix Attacks Still Possible?

Microsoft has issued the MS09-056 update which patched this vulnerability in CryptoAPI on almost all of their operating systems, that automatically fixes it for Internet Explorer, Chrome, Safari, and any other application that relies on the CryptoAPI. Mozilla has issued an updated quickly after Marlinspike's demonstration and Opera has patched it in version 10.00


Non SSL/TLS web page form for passwords? Security concerns?

I'm not entirely clear whether you're the user or administrator, so I'll answer for both.

As an administrator: I'd consider it a big concern, primarily because of password reuse: people will use the same password for this that they use for Facebook and their bank, and then be upset when their account information is stolen. I'd suggest using a service like Let's Encrypt to get free certificates.

But as a user, it's not really a big deal: simply use a throw-away password for the site and remember that any material is sniff-able, and that you have no guarantee of confidentiality or integrity.


If you remove the boot from CD and USB from your BIOS boot order it does increase security. Anyone cant easily drive by boot your machine when you are not there and copy all your hashes and sensitive information.

If you lose your BIOS password there is usually mechanisms to reset the BIOS back to default. Usually this involves opening the machine and using a "jumper" to short circuit two pins.


Windows User Processes running as childs of explorer.exe

I've never heard that, but it makes perfect sense:  A rootkit will also run without being a child of explorer.exe, by definition.  If the Windows process control system can see it, it's not a rootkit.

I don't know how common they are now, but they were once popular infestations.


VPN is designed to protect against attackers on the path of the communication between the VPN endpoints. This means it is does not protect against attackers before or at the VPN entry or at or after the VPN exit. This means an insecure router as VPN entry seriously impacts the protection offered by the VPN - an attacker could simply attack the VPN entry and access the communication before encryption or after decryption.


Privacy implications of Intel CPU's secret 3G communication (Anti Theft 3.0)

First thing, first:  You'll want to invest in yet another Ethernet NIC adapter for your fancy Intel motherboard in which to replace your onboard Ethernet device with.

Most Ethernet NIC do not have IME.  This takes care of your biggest security fear, as long as you do not plug anything to that onboard Ethernet port.


It is a bad practice as it makes the development more confusing in order to ensure that there is no overlay between the possible GET and POST parameters which are normally processed separately.

It also makes it a tiny bit easier for a hacker to benefit from a vulnerability in your site but it doesn't create breaches on its own.

In a well organized web application, the GET parameters are used for routing (page or module selection and relevant options) while POST parameters actually represent data submitted by the user.  Following this simple guideline makes the development much more organized, so safer from errors on your end.


Implementing 'Remember Me' for a mobile application

When you are new to cryptography, don't use cryptography. Nothing personal here; that's because you cannot test for security. You cannot easily (or at all) know if some system/protocol/algorithm is secure or not. Such tests simply do not exist. This is very unlike functionality, which can be tested: it is easy enough to see if a server boots up and answers requests, but it is impossible to verify if all this happens securely. Theoretical reasons for that have deep fundamental roots like the halting problem.

The only known way to use cryptography correctly is to let it in the hands of people who have devoted their lives to the study of cryptography. If those guys cannot collectively come up with an attack on your system, despite years of silent toil and meditation, then your system is probably secure, or at least more secure than that of your competitors, which is often good enough.

A "remember me" feature is about keeping some state on the user side, so that when the user comes back to the server, the server will automatically recognise him, and won't ask for an irksome password entry. Whatever way you put it, this means that the user device (mobile phone, as I understand it) contains everything which is needed to "log on" the server without any special user interaction. In particular, if the mobile phone is stolen, then the thief can obtain the same data and then log on the server. This is unavoidable, and that's (again) fundamental: if the user needs not enter his password, then there is nothing specific about the human user, and his physical presence is not required. That's more-or-less the point of the "remember me" feature.

No amount of cryptography anywhere will change that. If the app can log on the server without user intervention, then it can.

A "remember me" feature is thus an inescapable risk which you must balance with the improved user experience (users basically prefer not entering their password over entering their password). There are some ways to make the trade-off a bit more favourable for you:

Whatever the app stores, don't make it password-dependent. Don't store user passwords or any hash computed from the user password. User passwords are sensitive data whose scope extends beyond your app; user passwords are highways into their brains. Instead, store a "session key" which was generated randomly server side. Make it 16 byte long (at least), and use on the server a cryptographically secure PRNG to produce it (e.g. /dev/urandom or a wrapper around it).
If using a random session key, then you can cancel it on the server at any time, which is a good thing compared to the user password, because you cannot make the user "forget" his password, let alone any potential attacker.
Make it time-limited; for instance, make the "remember me" feature valid for one week. This will force the user to re-enter his password regularly, but you can choose the schedule; yet again, trade-offs. With a time-limited session key, you can contain the damage from any attacker within a strictly bounded time frame.

So now your problem is "simply" a matter of:

obtaining a random session key from the server;
storing it on the user device;
sending it back to the server when needed.

In an HTTP/Web context, all of this already exists and is called HTTP cookies. Just make sure that you set the "Secure" and "HttpOnly" flag, and that you use SSL (HTTPS) (if you are not using SSL, then you already have a lot of bigger problems, so do that first). The system which is easiest to implement securely is the system which has already been implemented securely by someone else. So just use it.

Now, if your app is about logging on an uncooperative server who is totally unaware of your "remember me" feature and will not send a session key as a cookie, then you have a problem. In that rotten situation, you have to store user credentials on the client side, and that's not good. Password manager software tries to cope with such issues, but the trade-offs are not as good as previously described. Users, generally, won't like it. There will be some local encryption with a user "master password", and that's a hard problem; moreover, Javascript is not at all the right language for that (in particular because of its low performance, which contradicts slow hashing).

It is highly preferable if you do not go there.


What websites would I be allowed to DoS?

It might surprise you, but conducting an illegal activity is illegal.

To "hack" a website, you need the written authorization of the website owner and the website host (the owner of the material infrastructure).

When doing a DDoS (as mentioned in the first version of your question), you are abusing the common infrastructure known as "internet", thus you are not only harming your target, but its neighbors too. Just do not do it.

When doing a simpler DoS, you might still infringe on your contract with your internet provider. Of course, you still need the authorization from your target.

To directly address the two websites you mentioned:

The terms and conditions of hackthissite.org states "You must not use the Services in any way that causes, or may cause, damage to the Services or impairment of the availability or accessibility of the Services". So, you are expressly forbidden to DoS them.
You do not own Wix.com, event if you put your content on their website.


Have I done enough not be compromised through image uploading

// check if extension is valid

is largely pointless. You (wisely) create the filesystem name without any input from the original filename, so the extension is discarded anyway.

Filename extensions are not a globally-observed convention. Even on Windows not everyone uses the same file extension mappings. So it's not usually a good idea to rely on particular extensions.

// no need to upload images less than 50x50

You will want to check that the image dimensions are not too big. Uploading an enormous image (especially a super-compressed one) is a good way to DoS a server.

  My temporary folder has 755 permissions.

Ideally you would want to have the web server user and the file owner user in a group, so you could give it 750 permissions, allowing the web user to write files without giving the same privileges to any other users on the server.

  I changed only one thing (function save to save every file with 644 permissions)

And similarly 640 here, or more likely 660 if you want your owner user to be able to write to the web server user's files.

  The folder is used only for image uploading

Make sure you enforce that on the server level, so that if someone does manage to upload a .php or .htaccess file into that directory, it doesn't do anything. It doesn't look like this code would allow that, but there might be some other flaw somewhere that does.

In general every file/directory that is writable to the web server user needs to be made completely non-executable, either by locking down the web server to do only static file serving from there, or not serving anything from there at all.

If you are having the web server serve the picture out of the upload directory you have a range of potential cross-site-scripting problems:

IE sniffing the contents of the file to find HTML embedded in it and treating it as a web page (with scripting) - can be prevented in more up to date versions using X-Content-Type-Options header;
Java treating the file as an applet, ignoring the real type; Flash treating the file as a SWF, ignoring the real type; the Same Origin Policies of these plugins not matching JavaScript's;
Flash loadPolicyFile treating the file as a crossdomain policy file, ignoring the real type and, in older versions of Flash, malformed content.

You've greatly mitigated these XSS-content attacks by loading and re-saving the image as JPEG, which would disturb the contents of the file, so an attacker can't just include the active content as-is inside the file.

It's not totally impossible for an attacker to submit an image that they know, when PHP re-saves it, will result in chosen malicious content appearing somewhere in file. This would be pretty difficult, especially for a lossy encoder like JPEG, and I've not heard of anyone actually using that in a real attack, but it's conceivable. The JPEG format is not specifically designed to provide hard guarantees about the difficulty of crafting input to generate a chosen output (as a cryptographic hash would).

If you want to be sure there are no possible XSS upload attacks the usual solution is to serve your untrusted data files from a separate domain, so that cross-site-scripting into it doesn't get the attacker into your main site.


Properly encrypt using AES-256 in CBC mode?

First of all, the salt is not an AES parameter. You have two different primitives here:

You would have:

pbkdf(salt, password) returns aes_key
aes(iv, aes_key)

The IV size should match the block size you are using (typically 128-bit as that's the one standarised, although other block sizes are possible).

Generate a new, random, iv for each file you want to encrypt.

Every AES implementation must provide the same algorithm. The way you choose to save data on disk is what differs.

A common solution would be to simply append everything:

file_password_salt || file_iv || file_contents

However, a more future-proof solution would embed some parameter pointing to the size of the fields and the algorithm used. Or, at least, a version number (eg. v1 PBKDF1 with SHA1 and AES-128, in a few months you may want to use Argon, with Camellia…).

Then, you could decide to use a format already used by other tools, so that it is compatible with them. For example copying what OpenSSL does (see that "SALTED" string?), or making it output a zip wrapper over the aes content.


Modsecurity create config file with rules for specific URL

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

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

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


Since you only need one account to be able to access the credentials for a second legacy system, I would recommend that you use a chain.  The user password for your system should not be reversible and the encrypted credentials should not be available without the user's password.  You can store the encrypted credentials with a symmetric record key that can be protected by both the user's password for your system and, if necessary, an administrative private key to allow account recovery.  This would probably be the best you can do since it would not allow the user's legacy account to be decrypted without the user's password.

(Basically just treat the legacy credentials as secured data.  There should be no difference.)


Android API/development security pitfalls

Insufficient protection of confidentiality and integrity of data in transit. Smartphones will often be connected to untrustworthy networks (e.g. GSM or wireless networks operated by unknown parties): when transmitting data to or from a network host, assume it can be tampered with or read.


What's keeping a malicious man in the middle server from forging a valid certificate

The "signature" field in a certificate is not a signature in abstracto; it is a signature over the contents of the other fields. You cannot simply copy a signature from a certificate to another one with distinct contents; it will not match. That's the point of digital signatures.

In the case of a MitM, the attacker may put his own public key in lieu of the genuine server's public key, but the client will not be fooled because his signature verification algorithm will tell him that the signature is now invalid. If the attacker wants to succeed, then he needs to obtain a new signature by some CA that the client trusts; and these CA are trusted precisely because they do not sign fake certificates.


How much entropy is good enough for seeding a CSPRNG?

What matters is entropy.

What makes a PRNG cryptographically secure is the inability of attackers to predict the next bytes. Precisely, there are three "security levels" that define the security, in the following model:

The attacker is given s bits of consecutive output from the PRNG.
The attacker's computing abilities are limited to 2k elementary operations.
The attacker is challenged with predicting the next bit from the PRNG, and must not be able to succeed with probability greater than 0.5+2-e for some value e.

Note that predicting a bit can always be done with probability 0.5 (with a purely random guess), so what we require is that the attacker cannot do substantially better.

In all generality, we normally want the PRNG to fulfil these properties with k+e ≥ 128. The "128" is a traditional limit. Basically, the attacker will try to enumerate possible seed values, and see what matches the known output; if the attacker found the actual seed, then he can predict all subsequent output with 100% accuracy; otherwise, the attacker knows nothing and is back to luck-based guessing, i.e. probability 0.5 for each bit.

To achieve this level, the seed shall represent an entropy of at least 128 bits. In fact, stating that "seed S has entropy 128 bits" really means "attackers who try to guess S and do so by successive trials in optimal order, starting with the most probable values, will succeed after an average of 2127 trials". The term "average" is the important one here: entropy is all about probabilities and averages.

To have 128 bits of entropy, you need at least 128 bits of data, because you cannot fit n bits of entropy into less than n bits of data. However, real-life "random" data is extracted from physical measures, and is biased, so it needs more bits to be represented. For instance, you can get some randomness out of the timing of keypresses from the user: biologically speaking, the user cannot reproduce exact keypress timings down to the microsecond, so the delay between two keypresses, expressed in nanoseconds, will "contain" about 10 bits of entropy -- but a one-second delay requires 30 bits to be encoded in nanoseconds.

In general, as an application writer, you do not have to do the complex job of estimating entropy: the operating system already aggregates randomness from physical sources, and computes these estimates. When you ask the OS to give you "random bytes" (by opening /dev/urandom on Linux systems, or calling CryptGenRandom() on Windows), you already get bits that are clock-full of entropy. So ask for 128 bits (16 bytes) and you will have a fine enough seed for your PRNG.

(The "128" is traditional. Current technological limit for the richest of attackers is close to 275 operations, and unlikely to increase beyond 2100 in the next two or three decades. "128" is considered elegant by cryptographers because it is a power of 2.)

If your PRNG is really cryptographically secure, then reseeding is not needed -- a need to reseed would actually count as a break, thus contradicting with the notion of the PRNG being cryptographically secure.

Many people and standard still insist on reseeding, mostly because of an established dogma that says that you must reseed, for reasons which are never actually specified. This dogma comes from much older days, when PRNG were not cryptographically secure, and actually were not running on computers, because that was before computers were invented.

Thus, you should reseed as often as it takes to keep your auditors happy, but do not worry about the security issues of reseeding or not reseeding: you do not reseed to achieve more security, but to keep other people happy and quiet.

(If your CSPRNG is NOT cryptographically secure, reseeding is unlikely to save your skin anyway.)


HOW is the malicious URL/payload is delivered to the user on a DOM based XSS attack?

The link you mention says that DOM-XSS is the de-facto XSS. This is simply stating that in XSS you are executing scripts (e.g. JavaScript) that are injected into the DOM.

HOW the malicious URL/payload is delivered to the user?

In some cases (reflected XSS) it's phishing: "Hey check out thiswebsit.com?p=[XSS payload]" When the phished user visits the site the script executes in their browser.

In other cases (stored XSS) you may be able to store a script in say, a comment box that is displayed to every other visitor of the site: "Hey this is a great site! [XSS payload]. Now when any user visits the site and your comment is rendered the malicious script is also executed in their browser.

In both cases although you've inserted JavaScript, that payload is not actually visible as text to the end user. The script is however executed in the end user's browser. The script payload may be a simple alert box, it might be a payload that sends their session authentication cookies to a server you control (allowing you to 'login' as them), or a number of other things.

How does the attacker identify a site with a possible DOM based XSS vulnerability?

Burp was already mentioned, this is a great tool.

A very basic way to get started testing/understanding XSS is to ask yourself when viewing a page "What data do I control, and what data is displayed back to me?". If you can test these data points for script injection you are on your way to understanding XSS. Data points that commonly are vulnerable to basic XSS attacks are comments, usernames, profile details, error messages, and search parameters.


What's the difference between "Public Key Algorithm" and "Signature Algorithm" in OpenSSL output?

The Public Key Algorithm refers to the public key inside the certificate: This certificate is used together with the matching private key to prove the identity of the peer (authentication). In your case it is an ECC key (id-ecPublicKey) which means that this is an ECDSA certificate.

The Signature Algorithm refers to the signature of the certificate created by the issuer: This signature proves that the claimed issuer of the certificate is the real issuer since the signature can be verified by using the public key from the issuers certificate. By verifying the link to the issuer a verified trust chain can be built up to a locally trust certificate (i.e. local trust store, root CA). In your case sha256WithRSAEncryption is used which means that the issuer has an RSA public key inside its issuers certificate and that the hash used for signing the leaf certificate by the issuer is SHA-256.


Should I install my subordinate Certificate Authority on the domain controller? Why?

The simple answer, ignoring any operational constraints?

Situation One: If the CA's security is (1) ROUGHLY AS important for security as the domain controller (2) you have enough spare capacity and (3) you don't need to reduce security for the DC by giving anyone special access to the CA or changing firewall rules as a result, then just run it on the domain controller because:

Presumably not too many people have access to the DC and it's well secured anyway.
The CA will normally be dependent on the DCs security anyway, so if the DC gets hacked it's game-over for the CA.

Situation Two: it's LESS important than the CA.  It's for convenience somewhere, or testing and the certificates aren't critical for your security. Then run it on a separate server.  Because:

You won't undermine the security of the domain controller with the extra complexity (running extra code always increases the security risk - in the jargon "it increases the attack surface").
You can give peoples access to manage the server without having to give them rights to the domain controller.

Situation Three: It's WAY more important than the DC security. For example, you are running a commercial CA.

Use as much segregation and monitoring as possible.  Probably a separate domain entirely.
Get some security professionals in!


Did google chrome kill public key pinning?

There are two types of pinning - public key pinning (PKP) and PKP over HTTP (HPKP). PKP is alive and well; browsers can be tested with the badssl pinning test, as Benoit E notes in a comment on another answer.
HPKP was planned to be removed in Chrome 65, then in 67 and actually deprecated in v 69.
It no longer exists in Chrome 72 and shows as removed, just as you found also.
TLS 1 and 1.1 are also deprecated in v72.
Firefox has a debate about it here.
Opera version 25 to 53 support Public Key Pinning.


Not disclosing the password when tortured?

All encryption methods have a secret key that needs to be stored somewhere. The quote doesn't say that he can't "disclose the method to access it", it only says that there is no password involved. That's a much weaker statement.

This question basically comes down to whether there are encryption schemes that do not rely on a human brain for storing the secret. The answer is Yes. These two come to mind off the top of my head:

Public-key encryption: As suggested in comments, if he sent the data to a friend, encrypted with their public key and then deleted his copy, then Edward Snowden would legitimately no longer have access to the data (but the friend can give it back to him if needed).
Hardware based encryption: by this I mean any system where the encryption key is stored in hardware. An example would be a laptop with full disk encryption where the keys are stored on a smart card; unless you have the card, no amount of password-telling with decrypt the harddrive!
Low Tech It's also possible that he's using a lower-tech solution than you are imagining, for example generating a random 64 character password, writing it down on paper and giving the paper to a friend or storing it in a bank vault.

I'm not trying to imply that any of these are convenient, or even particularly good security measures, but they count as "passwordless encryption" enough to make his statement true. Or maybe he does have some magical encryption system whereby he, and only he, has access to the data regardless of how much information he gives you.

About journalists: I have helped a few journalists set up digital encryption systems, and I completely agree with that quote that technical ability and attitude towards protecting sensitive information varies wildly from journalist to journalist!


"ScriptResource.axd" vulnerability in Windows Server 2008

Sounds like that's the padding oracle attack that came out in 2010.  You should check your server for the appropriate MS patch (MS10-070).

There's more information on the attack here


Security Concerns on clientside(Javascript)

There will never be a single perfect checklist, but here's a few things worth going through:

Wikipedia doesn't do half bad on this one
More for AJAX or other rich interfaces, but worth a read depending on your architecture - OWASP
This seems worth a test drive - haven't tried it myself - Javascript sandbox

Yes, none of these is a true "checklist" - IMO what you need to look for in Javascript vulnerabilities has a lot to do with how you are using it and what the rest of your architecture looks like - so I'm not sure a checklist will really cover the real concerns.  It may be better to go through a risk analysis first, and then see how that translates into how you use the various web technologies as a collective.


What are the insecure Protocols in terms of PCI DSS

Basically any protocol that does not provide authenticity, integrity and confidentiality. In practice this means FTP should be FTPS or SFTP, telnet should be SSH, POP3 should be POP3S and IMAP should be IMAPS.

It's important to disable all the other protocols and not just provide a secure alternative. The encrypted protocol should provide strong cryptography. Any communication sending sensitive card holder data across the public network should use an encrypted channel such as SSL/TLS or for instance IPSEC.


How does BeEF work? (working understanding)

Alright, BeEF is a framework similar to Metasploit. BeEf uses a javascript, hook.js, which when executed by a browser, gives a hook to BeEF. With a hooked browser, similar to metasploit, you have an array of exploits in front of you. Some of them are viewing cookies, browser history to the more sophisticated attacks of getting a shell. I know for a fact that there is a shell exploit that uses a JBoss vulnerability.
So, how the attack works is as follows, the client visits a malicious page, which contains BeEF's hook.js script running on it, or it can be executed via a XSS attack. When this is executed, you can see that a browser is hooked to you on your BeEF control panel and thereafter, launch exploits.

More Details: The BeEF launches a BeEF instance which is a combination of the UI server(the UI which is used to launch attacks and shows the various exploits) and the communications server which coordinates and communicates with the hooked browsers. These 2 servers in collaboration makes BeEF work.

BeEF has a very clean interface, by organizing attacks based on type and also indicating if particular attack is relevant to a browser (IE, FF, Chrome etc.). So you can just point and click on the attacks to launch.

  What purpose does it have in real world? I am curious to know how it would enhance the security in an organization.

It can be used as a serious Pen Test tool. In most cases, when you demonstrate an XSS to a client (assuming you're a pen tester) it does not have that much of an impact when you show them a silly pop up. On the other hand, if you demonstrate XSS using BeEF, now that will give them a scare.

Further reading: http://code.google.com/p/beef/wiki/WindowsInstall


High concentration of UDP traffic, good or bad?

An approach to consider that would help to define if the traffic is malicious or not.

Stage 1, traffic capture.

Tool Choice:
To do anything sensible is going to require raw packet output so use your tool of choice (wireshark / tcpdump are two examples). Personally I would use tcpdump and if needed load the traffic capture in to wireshark for a nice graphical view of the world.

Config:
You will need to configure the tool to capture the entire packet - by default tcpdump only captures 68 bytes of data. I would also capture the hexadecimal output by using the -x flag. Doing so will allow me to examine the individual bits (very important when doing a deep dive on evil packets).

As you are interested in UDP traffic you can limit the packet capture to UDP only traffic. This is done by matching the value of 17 (which is for UDP) in the 9th offset of the IP header. Or you can use the tcpdump inbuilt macro that does this for you by calling the udp flag option.

Execute:
An example command line for tcpdump could be tcpdump udp -s 0 -x -w /udp_traffic

This would capture the entire IP frame with hexadecimal output for UDP traffic only and write this to a file called udp_traffic

Confirm: To confirm that this works you can then run tcpdump -r /udp_traffic
Which would give you something like:

09:06:16.982995 IP 192.168.188.128.63793 > 192.168.188.1.42313: UDP, length 0
09:06:16.986062 IP 192.168.188.128.63793 > 192.168.188.1.623: UDP, length 0
09:06:16.986274 IP 192.168.188.128.63793 > 192.168.188.1.30303: UDP, length 0

Stage 2, Analysis.

Two real options here, use an IDS/IPS solution and replay your traffic to see what alerts this raises and then chase down each alert to understand if it is a false-positive or not. This approach is more scientific and is based on known bad traffic. This would be quicker if the IDS/IPS has already been tuned for the network and the traffic matches known rules.

Or you can use a more gut-feel approach using your knowledge of the network and services that are running to review the traffic. This is more of an art than a science, but has advantages, peoples gut feel is something you cant programme a piece of code to replicate and if you know your network things will stick out.

Both approaches will result in the breakdown of traffic in to the following groups:

Type of traffic:

Breakdown by port
Breakdown by source
Breakdown by destination
Breakdown by port

This will enable you to deal with large amounts of traffic in more manageable chunks and look for patterns.

In our example from earlier -

09:06:16.982995 IP 192.168.188.128.63793 > 192.168.188.1.42313: UDP, length 0
09:06:16.986062 IP 192.168.188.128.63793 > 192.168.188.1.623: UDP, length 0
09:06:16.986274 IP 192.168.188.128.63793 > 192.168.188.1.30303: UDP, length 0

We can see that the packets are all from the 192.168.188.128 network and from port 63793 and heading to 192.168.188.1 on various ports. This is classic scanning traffic, in this case an nmap scan for udp ports.

Traffic content:

If we do find traffic that we do not like the look of, then we can take a look at the hexadecimal output to dissect the packet at a much deeper level. If we take

09:42:15.206332 IP 192.168.188.128.63793 > 192.168.188.1.52503: UDP, length 0

and look at the hex output we see:

0x0000:  4500 001c 43d7 0000 2a11 5327 c0a8 bc80
0x0010:  c0a8 bc01 f931 cd17 0008 3fc1

Points of interest would be the first offset (counting from zero), which shows 4 for IPv4. Offset nine shows 11 (remember to convert from hex to decimal) so that is protocol 17, or UDP. Then we have source address at offset 12 - c0a8 bc80 (192.168.188.128) and destination address at offset 16 -  c0a8 bc01 (192.168.188.1).

Stage 3, Identify and review odd traffic:

When you have identified any specific traffic that is of interest then it is a combination of research (google) and deep packet analysis.

To give a feel, this type of UDP packet would give me concern and warrant further investigation:

10:30:36.313999 IP 192.168.188.128.50056 > 192.168.188.1.26000: UDP, length 2201
        0x0000:  4500 05dc 7d9c 2000 4011 dda1 c0a8 bc80
        0x0010:  c0a8 bc01 c388 6590 08a1 0c07 425a 7454
        0x0020:  3349 3665 5747 6742 4642 4177 7071 4156
        0x0030:  6c5a 7271 7975 5579 5546 6375 4b76 6c4f
        0x0040:  5762 3853 4578 6757 3766 5837 744f 7572
        0x0050:  766e 746b 4339 6c74 6f6c 6156 4264 3072
        0x0060:  566c 6739 7355 4a37 3550 3848 7a70 4d6f
        0x0070:  6f4b 6e77 7762 4b47 6c6c 4f63 3846 7372
        0x0080:  7a7a 4879 7763 6330 4c77 3172 7048 5941
        0x0090:  4177 5676 727a 6f52 4b32 566c 5a6b 5242
        0x00a0:  696b 4976 3470 547a 3467 6f74 644b 376c
        0x00b0:  3468 3443 5676 4758 4535 6857 6b41 657a
        0x00c0:  4779 7731 654d 314a 5976 7265 3974 6e41
        0x00d0:  305a 4358 6f5a 517a 4344 6378 5634 476d
        0x00e0:  7147 6979 3653 6a69 4331 486b 734f 7844
        0x00f0:  4175 6467 7858 636f 5550 386c 6332 5a6c
        0x0100:  3237 3067 5552 514b 6345 4836 7073 516f
        0x0110:  7a52 6631 315a 6365 3563 4f76 4275 4c4a
        0x0120:  6f74 5032 5057 704f 6f5a 4d58 4369 7666
        0x0130:  3847 6733 5555 5036 6e7a 4c6b 3856 4573
        0x0140:  6b59 646b 6b62 6733 5036 6c4c 534c 3248
        0x0150:  4156 3037 656b 7433 3148 6578 6968 547a
        0x0160:  436f 5635 5957 7165 6d66 4565 3563 494d
        0x0170:  6570 7947 4174 5559 4c57 5a59 6d63 3671
        0x0180:  4333 4a4e 7269 4778 5968 6b6b 4155 7a39
        0x0190:  6c53 5772 5573 5644 684f 3456 3237 5267
        0x01a0:  634a 326c 4558 6e5a 6b5a 5255 486f 6436
        0x01b0:  6878 4770 5053 4178 426a 6651 6c53 4e70
        0x01c0:  5970 646b 5539 735a 3254 737a 6964 4a46
        0x01d0:  4b4c 504e 7244 7451 7a41 4945 3233 5951
        0x01e0:  586d 4866 7a54 334c 7947 4145 5041 6a65
        0x01f0:  4850 4665 3168 7446 4639 4172 4731 526e
        0x0200:  324d 5151 4641 737a 4f53 4556 7332 5a38
        0x0210:  614d 735a 3978 444b 4565 5054 7459 5663
        0x0220:  7837 3059 3666 3871 754e 3377 7252 3659
        0x0230:  344c 586c 5232 7265 5a6f 416b 785a 6961
        0x0240:  5156 3973 3267 6279 5738 6272 7663 5463
        0x0250:  6b62 4e70 5a64 4763 4772 4262 4551 5254
        0x0260:  4757 4d76 4e51 414a 3868 5063 7267 304c
        0x0270:  4b78 784c 6b49 5563 7443 5a36 526b 745a
        0x0280:  4c4e 4c68 7175 4a54 3064 626e 4562 5157
        0x0290:  3068 4730 6e47 3650 5468 3467 4e72 4a6b
        0x02a0:  5a51 5771 4a38 5747 4453 6e64 3971 4650
        0x02b0:  4263 7358 6e46 5173 3057 5a57 6f65 7168
        0x02c0:  7a67 5859 6e74 4138 7457 3672 646b 344a
        0x02d0:  5958 5363 7231 6c6c 696e 6a38 704b 6146
        0x02e0:  786d 4f5a 6c57 4d50 4232 3459 7130 6a4d
        0x02f0:  5278 7330 3352 336f 6742 5661 3245 7879
        0x0300:  4e43 444b 4d4b 424f 7441 6a37 6e51 6238
        0x0310:  4e78 5053 6f39 5a64 3632 3879 6e54 5042
        0x0320:  7736 5258 4e42 3557 704d 6b48 7974 5050
        0x0330:  4777 4e63 3269 7672 7672 4266 697a 4c67
        0x0340:  4568 554a 4636 614b 6a56 7068 4e33 4a4c
        0x0350:  5067 7254 6a67 674c 3337 6574 5934 6836
        0x0360:  394c 354e 3261 7456 7270 4f69 6531 3452
        0x0370:  7568 6835 5374 756e 5676 6f4f 767a 6d6b
        0x0380:  6679 6846 4743 3861 3543 6538 454e 4c4c
        0x0390:  4745 7630 5247 6675 5333 3070 3576 4b62
        0x03a0:  5932 3562 6a38 4752 337a 4973 5068 3867
        0x03b0:  364a 6159 3444 7149 5372 4b63 5547 6f6e
        0x03c0:  4e36 4845 6e43 6534 4b48 5568 5639 4b47
        0x03d0:  3835 5862 5a32 6962 3157 7431 4344 3442
        0x03e0:  496e 644e 445a 6851 6870 4373 6951 5776
        0x03f0:  4438 5874 6578 4c38 4d4a 694c 3368 536c
        0x0400:  664e 3369 75b7 3f07 102d 47b3 10f8 7b04
        0x0410:  a81c 4873 7672 46b0 b823 f58d 4b13 d477
        0x0420:  6692 2ae2 2c1a d598 7c22 d624 ba3f 40b2
        0x0430:  0537 08e0 0c35 900d b7bf 4f43 85e3 3afc
        0x0440:  9671 28e1 7527 a91d 4e99 9f4a 12d1 f97e
        0x0450:  18fd b13c 3d42 9b79 7e77 7b4f 89e1 7970
        0x0460:  730b f8b5 bab8 1d3f 2584 e340 bea8 03d0
        0x0470:  c0d6 9614 b067 98b7 9942 bb97 4bb4 9bbf
        0x0480:  3bd4 88f5 4e0c 7546 3d7d 7c09 e07a 69f9
        0x0490:  2c90 7149 a92f 0415 911c 7224 9f74 7827
        0x04a0:  38d5 7637 b1b2 8ceb 6693 432d 7f02 e234
        0x04b0:  b68d 48b3 791b fc7f 3c75 35b9 7141 7447
        0x04c0:  7805 7d20 eb0d 9272 4a83 e001 e10a d2fd
        0x04d0:  734f 700d 9b7c 14b5 4390 bad3 c1f9 7630
        0x04e0:  f5be bf2d 31e3 351d 81fd 7b39 fc27 7e37
        0x04f0:  80e2 2c34 b0b1 1567 7a0c 4b98 3da8 4940
        0x0500:  bb92 b33f 0425 b71c 8d97 4741 b4f8 b8b9
        0x0510:  7705 86d6 4eb6 9193 46d4 422f a93c 6696
        0x0520:  d5b2 2499 484a 9f56 5458 3633 3057 5458
        0x0530:  3633 3856 5848 3439 4848 4850 5658 3541
        0x0540:  4151 5150 5658 3559 5959 5950 3559 5959
        0x0550:  4435 4b4b 5941 5054 5458 3633 3854 4444
        0x0560:  4e56 4444 5834 5a34 4136 3338 3631 3831
        0x0570:  3649 4949 4949 4949 4949 4949 515a 5654
        0x0580:  5833 3056 5834 4150 3041 3348 4830 4130
        0x0590:  3041 4241 4142 5441 4151 3241 4232 4242
        0x05a0:  3042 4258 5038 4143 4a4a 494b 4c4a 484c
        0x05b0:  4945 5045 5045 5045 304d 594b 5546 514e
        0x05c0:  3245 344c 4b46 3250 304c 4b46 3244 4c4c
        0x05d0:  4b51 4242 344c 4b43 4251 3844

There is a lot of data being sent in this single UDP packet, to a high port and from a high source port. In fact, this is an example of a buffer overflow being completed over UDP.


Strange behavior when injection wifi packets with aireplay-ng

Edit:

First, be sure that you're close enough to the AP. This question had almost the same problem and it fixed by that.

But if it didn't work, then the problem isn't from the injection itself, but from monitor mode option!

From your question, I can see that the problem was solved by replacing

$> sudo aireplay-ng -9 mon0

with

$> sudo iwconfig wlan0 mode monitor
$> sudo ifconfig wlan0 up
$> sudo aireplay-ng -9 wlan0

In most cases, the first way causes some troubles, and some people suggest airmon-ng check kill to solve it, but it will lead to another issues.

So, the problem is within the airmon-ng package, and the solution is to set the monitor mode using a proper way.


How do you get the PE file hash of a signed file?

PKCS7 (aka CMS) most certainly does define the generic ContentInfo. See rfc2630 section 3 et succ, or rfc2315 section 7 (no anchor to link):

  ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

  ContentType ::= OBJECT IDENTIFIER

But this is deliberately so flexible as to be useless in processing the data: it can contain any type of data as long as there is an OID to identify that type of data.

You aren't clear on your source, but my first google hit for "Authenticode signature format" is download.microsoft.com/download/9/c/5/9c5b2167-8017.../Authenticode_PE.docx and that says on page 7 regarding the contentInfo of the SignedData used for Authenticode:

  • contentType must be set to SPC_INDIRECT_DATA_OBJID (1.3.6.1.4.1.311.2.1.4).
  • content must be set to an SpcIndirectDataContent structure, which is described later.

and from page 9 to 11 (which is indeed later) contains a detailed definition beginning with

SpcIndirectDataContent ::= SEQUENCE {
    data                    SpcAttributeTypeAndOptionalValue,
    messageDigest           DigestInfo
} --#public—

SpcAttributeTypeAndOptionalValue ::= SEQUENCE {
    type                    ObjectID,
    value                   [0] EXPLICIT ANY OPTIONAL
}

where the DigestInfo contains the AlgId and digest value for a canonical hash of the file computed using a process detailed starting on page 15.


About Wikipedia section about Malware for AutoHotKey

I'm pretty sure AHK is not malware!

There is no claim (by the article or elsewhere) that AutoHotKey is Malware. I'm not sure who or what makes any indication that is the case. If anyone had doubts, they could view the source code as AutoHotKey is open source.

  Do anti-malware vendors 'often' (or sometimes) add AHK's signature to
  their databases mistakenly?

Anti-virus companies rarely do anything by "mistake". A company many design their product such that the product's heuristics determines something with AutoHotKey-like content to be malicious. Another example of this can be seen with executables passed though a "PE Packer" such as UPX. Does it always mean that the executable is bad or dangerous? No, it was either just a general/broad signature or a design choice of the product's heuristic to alert the user on the discovery of such content.


You are entering the murky area of revocation. Basically, you want to have a system which "works" but with a cancel switch which says: even though everything looks legit with cryptography and everything else, don't open.

If your system is completely offline, there is no solution. A "cleaner" has the power to open all the lockers; he cannot lose this power if everything is offline because the information about the hijack of the cleaner state (theft of his keys) cannot enter a totally offline system, since it comes "from the outside". To solve your problem, you necessarily need an at least intermittent network.

The usual solution, for instance in X.509, is to have short-lived signed objects which declare that "for now, everything is fine". In your cleaner/locker analogy:

Each locker has a clock and knows the current date and time.
Every morning, the cleaner goes to the main cleaning office and shows his face and keys to an officer who verifies that the cleaner is indeed legit and allowed access; the officer then gives to the cleaner a signed "access token" which says "cleaner X is allowed access up to March 8th, 23:00 UTC".
When the cleaner wants to open a locker, he must insert his key and the access token. The locker verifies the signature from the officer, and also that the access token is not yet expired.

In X.509, the "access token" is a CRL or OCSP response. Details vary on how the objects are brought to the validator (here, the locker). In the analogy above, the "intermittent network" is the central office; this is the point where the system is transiently "online". Alternatively, signed access tokens could be distributed to lockers proactively by someone else.

A cornerstone is that validators MUST have a reliable time source, for a suitable notion of time (you don't necessarily need much in terms of precision and accuracy).


What is the output length of CBC with zero input?

Block ciphers like CBC require an input as multiple of the block size. In this case P would need to be padded to be one block long.

Another thing to notice is that the first block of P is being XORed with the IV which is also one block long - this will also ensure that you start with an input data of size which is at least one block long.

Being a block cipher your output will be the same size as input (excluding any communications for IV between sender and receiver).


Do security consultants routinely demonstrate hacking into attendees' PCs within minutes?

If a machine is not properly setup and secured (latest patches, password protected, encryption, anti-malware etc.) they can be hacked in a couple minutes.

However, if you look at realistic scenarios, hacking a machine can be time consuming even with only a couple security measurements in place. If you can port scan a machine and find vulnerabilities, you have to find out how to abuse them by finding related CVE's and exploits.

More so, hacking a machine of a student without proper agreement is illegal in almost every country. Not even taking this legal aspect into consideration, which definitely is a problem while hacking cameras of an unrelated hotel without permission, hacking into multiple and different devices usually requires different skills and tools.

So can it be done? Yes. But it is not a realistic scenario and especially the ones you mentioned don't really sound very truthful.

It is not a common security practice to hack devices from students or hotels to perform demonstrations on, however most security researches do demonstrate different attack vectors using own machines setup to successfully demonstrate their findings.


How sqlmap tests/injections are seen by the victim?

What will be seen by the defender in this situation largely depends on what logging they have in place and where the injection is located in the HTTP request.

If the injection is in a GET request (e.g. http://vulnsite/vulnpage.php?id=5 ' OR '1'='1) then this would show up in most web server logs as they usually log the full GET request.  So a defender would likely see a large number of requests to the vulnerable page with unusual data in the parameters.

If the injection is in an HTTP POST (so as the result of a form submission) then most web servers won't log that by default. The web server log would still show a large number of requests to the page in all likelihood, but the detail of exactly what was happening wouldn't be immediately apparent.  Additional logging could be deployed but (AFAIK) this isn't the default in most set-ups.

On the second part of your question.  The IP address that the connection is made from would be logged in both cases, so if this is the genuine address of the attackers system then it may be possible to trace this back to a specific location or person.  As such many attackers do not come directly from their own systems but go out via a VPN or another compromised host.  TOR would be another option but from what I've seen the performance of TOR may not meet the requirements for speedy exploitation of SQL Injection issues.


How secure is the apt-get install command against man in the middle attacks

All of packages within the Ubuntu and Debian apt repositories are signed using SecureApt.  Asymmetric cryptography is very secure and its highly unlikely that you will be compromised in this way.   3rd party repositories are hit and miss, they may or may not be singed.  If they aren't signed,  apt should throw a warning informing you that you are installing an unsigned package.  But if its from a 3rd party you could also just be installing a backdoor,  so make sure you trust that source.

On a side note,  people don't really "inject packets" to perform MITM.  They are going to use something like DNS cache poisoning or ARP table poisoning so that you download the package from an HTTP server that they control.  This isn't an injection attack.


Is the IP address of the client present in the email headers for webmail services and for desktop clients?

The Received headers in an email track every SMTP conversation an email has.
If you're using Thunderbird or another MUA (mail user agent), you're almost certainly speaking SMTP and therefore your IP address will be logged in a Received header as per RFC 5321 §3.7.2 (though a rare few outbound SMTP relays violate the spec and actually omit your IP address).
If you're using web mail, the SMTP connection is controlled by the web mail server. Many web mail servers will add the client IP either in a Received header (typically saying with HTTP) or another header such as X-Originating-IP. A number of web mail providers removed this data in the mid 2010s in anticipation of privacy laws like GDPR and the speculation that IP addresses are personally identifiable information (which is a debated topic), so this is not as available as it once was.
IIRC, Google never had client IP information in its web mail headers.
Arguably, with a responsible web mail provider using authentication for outbound mail, tracking the client IP is unnecessary since abuse reports can pin content on the sending account, which is more telling. This unfortunately limits what third party analysts can do since an attacker may be cycling through multiple accounts from multiple providers using the same pool of IPs.


Bob goes over the just checked out code and verifies that it is indeed what he wants/needs.
Then at a later date, Bob does on another secure machine (or at least, in an empty directory):
git clone https://malicious.server.com/HonestEve/project.git

or probably he uses the same url, but somehow gets connected to a malicious git server. And then proceeds with:
git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf

Then the question is, is it possible (ignoring any SHA1 collisions or weaknesses) that the resulting source tree is different from what he got the first time?

Yes it is possible. This is not safe to do.
Mallory (the owner of malicious.server.com) can create a branch, named 5b3469eccbd7849d760f63af8537940c97c1d1bf, with arbitrary changes to the code/repository.
When Bob executes git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf, git will display a warning that the ref is ambiguous but will ultimately prefer the branch over the commit. (note if this gets run in e.g. a build script, you will likely miss the warning)
I have tested this just now on git 2.25.1 (on Ubuntu 20.04).
I have also tested pushing such a branch to GitHub - but that failed. GitHub seems to have a custom check that ensures that branches/tags cannot have a 40-hex character name:
[...]
remote: error: GH002: Sorry, branch or tag names consisting of 40 hex characters are not allowed.
remote: error: Invalid branch or tag name [...]

However, this check is specific to GitHub; and even pulling from GitHub note that you now not only need to trust git but GitHub too.
The solution to this specific attack vector is to tell git that the ref you want is a commit hash:
git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf^{commit}


It is a vector of specified size. I think everything you needed is documented here.


Safest way for multiple users post to a single social networking account

In this case, I wouldn't try to roll my own solution per platform, since there are tools designed specifically to manage team access to social media accounts.  HootSuite, for instance, has a number of team management features.  All you have to do at that point is manage access to HootSuite, not Twitter and FaceBook and anywhere else you might have accounts.   For options other than HootSuite (which I don't personally use, so can't vouch for) try a search using a term like "social media marketing management tools for teams" or something similar.


Do smartphones have built-in surveillance in certain countries?

There usually is no need for a state to install phone-call-intercepting malware when all they have to do is demand access to calls from the phone carriers. And some countries prohibit encryption on mobile phone calls.

But you asked if they can. Russia allegedly did this during the 2014 Winter Olympics in Sochi, as part of their “Ring of Steel” security strategy. It was claimed that they installed malware on mobile phones in addition to monitoring all network traffic. Such efforts are difficult to prove, of course, but are certainly not unthinkable.


Hardware secure keys are not a feature of Android, they're a feature of some (but not all) devices running Android, including most if not all high- and mid-end smartphones and tablets. The way they work depends on the capabilities of the hardware.

All processors based on an ARM Cortex-A core (and some older ones), whether 32-bit or 64-bit, have a feature called TrustZone, which is a sort of highly specialized virtualization. There are just two partitions: the secure world and the normal world. The secure world has access to the normal world, the normal world doesn't have access to the secure world. TrustZone itself isn't enough to do anything useful: the memory bus has to enforce the protection, which is the case on most (but not all) system-on-chips (SoC) based on a Cortex-A.

On a suitable processor, the secure world runs a trusted execution environment (TEE) with a small operating system. On reasonably modern Android versions, the keys of the Android keymaster are stored in the TEE, Android (even fully rooted) does not have direct access to them. There are phones where the device encryption key resides inside the TEE, but this isn't always the case.

The TEE data is stored encrypted using a key that Android cannot access. This key is derived from a root key which is stored in write-once memory (this can be fuses or other one-time-programmable (OTP) memory technology). The reason Android cannot access this key is that the processor ensures that it is only accessible to the secure world.

On some SoC, the secure world directly reads the memory. On other SoC, there is a dedicated component in the SoC that has exclusive access to the root key, and all the secure world on the main processor can do is to request a key derivation based on the root key. This doesn't change much regarding the security of the system: in either case, the key that the security of the system relies on is a key that gets stored in secure world memory.

Restricting the secure world to a derived key has one advantage: the key can be changed by changing the tweak on the derivation. An attacker who partially breached the TEE and managed to read data, but not to execute arbitrary code, would have access to the key. If the bug is fixed and the new TEE version uses a different key derivation parameter, then the attacker will no longer be able to read TEE data.

Some ARMv8 processors (including all high end phones today) have instructions similar to AES-NI, but this has no impact on security (except indirectly, in making cryptography less expensive and less prone to side channel attacks). AES-NI and the ARM equivalent are just ways to compute AES faster, the keys and data are still in the same place.


Security concerns with user Python scripts

To approach this problem from a different angle, how about creating a domain specific language?

Why give the users the ability to do a plethora of things you don't want them to be able to do, and then attempt to sandbox and contain the power you're giving them? Instead, create a simple language that can only be used for plotting, and interpret it with Python.

So you could create a simple DSL called "Plot" or something. Plot would be a language that allows users to describe their plotting strategies. So your image.py file would load cat.plot, which could be supplied by you or a user.

As was mentioned in the comments, whitelisting of functionality is much better than blacklisting. Don't give the users more power than they need—better to not give the power in the first place rather than trying to contain it.


Depending on what you are looking for there is a lot of technologies covering the smart card topic. Some of them coming to my mind:

ISO 7816: cards with contact http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx
ISO 14443: contactless smart cards
http://en.wikipedia.org/wiki/ISO/IEC_14443
PKCS#15: Cryptographic Token Information Format Standard http://www.rsa.com/rsalabs/node.asp?id=2141
PKCS#11: Cryptographic Token Interface Standard
http://www.rsa.com/rsalabs/node.asp?id=2133


okay, seems one has to add the --expert flag:
$ gpg --full-generate-key --expert                                                    gpg (GnuPG) 2.2.25-unknown; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (9) secp256k1
Your selection?


Can dual-boot, encrypted Windows 7 installations be fairly well secured against each other?

It depends on your threat model. There is one problem I can see: disk encryption does not guarantee integrity. That means the other operating system installation could change the data on the first one. Now unless something went wrong, it should not be able to write arbitrary data (it does not know how to encrypt them), but it can write random data, or more dangerously roll back the data to earlier version. This could allow for example uninstalation of security updates. Then the attacker could exploit the vulnerability, that was supposed to be patched already. This could allow an attacker who was able to infect the less OS used for presentations to attack the OS connected to the corporate network. This may be solved by reinstalling the presentation OS after each update.

Another problem may be, that if the OS connected to the corporate network stores data on its local drive for example as cache for the network share, the presentation OS may see, when data changes, even if it can't see from what to what. This can't be really prevented with FDE, though it gives an attacker limited amount of information.

An option to solve some of these issues may be to use file-system encryption in addition or instead of FDE, but reverting the whole disk will still be possible.


In general: You need to trust the machine on which you are decrypting the files. This trust is usually only warranted if you have full control over this machine which also means that you can install software on it. So if you are really concerned about the contents of your files then use an offline encryption/decryption tool on a trusted machine and upload the encrypted data to Google Drive or any other cloud file sharing service.

Then how do you access encrypted data on the library computer? Well, you don't. That machine might have malware on it that sends copies of your data and/or your key to somebody who is not supposed to have them. Once this happens your entire encryption is useless.

This also explains why there are no "online solutions to encrypting Google Drive". I'm not really sure what you mean by "online" here but I am assuming you mean "transparent" i.e. the data is encrypted but you don't really have to care about how it is done and don't need to worry about installing software. Here's why this is so hard to do:

Encryption of data always requires two main ingredients:

The algorithm used to encrypt the data and
the key used to encrypt the data.

The key must never be known by an untrustworthy entity. But you need to supply the key to the algorithm and an untrustworthy algorithm might just send the key to an untrustworthy entity. So you want the algorithm to be trustworthy. This, however, means that you should not use an algorithm provided by an untrustworthy source.

Applying this to your Google Drive situation

Since you want to store data so that Google can't read it we are going to define Google as untrustworthy.

Transparent encryption without additional software on the client side would have to be done either on the Google servers or in your browser.

When it is done on the Google servers it is obvious that you need to supply Google with your encryption key so they can decrypt your data on their servers. So now they have your key which means they can decrypt which means you might as well have stored your data in plain text all along.
The other option would be decryption in your browser. This, however, would have to be implemented by Google so they can serve it to you on their page. Again, you would have to hand the key to an algorithm that is from Google and that algorithm might send the key back to Google.

A trusted third party

After all that talk about how it is impossible to do transparent Google Drive encryption here comes a way how it might be possible. However, this requires that you trust some other party to see your sensitive data.

Google Drive has an API that allows viewing and uploading of files. In theory it would be possible to build a website that accesses your Google Drive using that API and encrypts and decrypts data before it is written or read. This means that Google would never see your plain data and you would still be able to access it without installing additional software.

However, now you have a different website owner who provides the decryption algorithm and might therefore have your key. And you have also handed him your Google Drive login so now he is the one who will be able to download and decrypt everything in your Google Drive.

Addendum 2015-02-28: From having a quick look at the InstantCryptor website it seems that they have implemented exactly this scenario. From what I can tell, they provide a JavaScript-powered web-based interface to your Google Drive and Dropbox storage. This interface can encrypt and decrypt your files before saving them on your cloud storage.

The sad conclusion

If you really want to make sure that nobody sees unencrypted data, then you can't show your unencrypted data to anyone. This, however, means that you need to do the encryption on a trusted machine and that usually mandates that you install additional software. Also you can't decrypt data on untrustworthy machines such as library computers.


One simple experiment you can run is to plug your headphones into a microphone input and speak into them.

Fundamentally, both emitting sound and capturing sound is about dealing with vibrations in the air. The processes are opposite (one takes electrical signals as input, and outputs air vibrations, one takes vibrations in the air and transforms them into electrical impulses).

However, consider the following:

Both mics and speakers (or headphones) have a diaphragm, and as mentioned in the Wikipedia article:

  Microphones can be thought of as speakers in reverse

Both incorporate circuitry able to translate vibrations into electricity (or vice versa). In other words, both have an electrical signal on one side, and vibrations on the other. The difference is what is labelled as input.
If you think about the original phonographs, the same component was used to record and listen to sound.

So yes, a speaker can pick up vibrations (albeit sub-optimally), and a microphone can emit vibrations (albeit sub-optimally).

Many TV speakers are actually speaker arrays, too, so that you (sort of) have an array of tuned inputs (important because it might allow using post-processing to enhance the wanted audio).

This doesn't address the software question, but mechanically, a speaker can function as a microphone.

There is also "proof" that the functionality can be abused: badBIOS used the built-in PC speakers as a form of high-frequency modem—this despite the fact that one would expect PC speakers to be wired only for output. So yes, your comment was correct—there is a link to information security, and the functionality can be abused, notably to bridge air-gaps.

So this seems possible—how practical and how effective is another question, but there is precedence that it is usable for certain applications.

Edit: Thanks to @nulldev, "how practical" seems to have a fairly conclusive answer: per Arxiv, it is practical, and software solutions exist.