Is there any bias in this random selection from a dictionary? I am generating passwords by selecting random words from a dictionary and counting entropy=words_in_passphrase*log(dictionary_size)/log(2). This algorithm assumes words will be selected from the dictionary with uniform distribution.

I think the design principle is sound but I'm not sure about the implementation. I'm reading from /dev/urandom enough bytes to express an index into the @words dictionary, and converting those bytes into an integer somewhat awkwardly.

The code appears to work correctly, but are there any caveats to Perl or /dev/urandom which will skew the results? Full source.

my $entropy_per_word = log (@words) / log (2);

my $pw = "";
my $pw_entropy = 0;

# maybe /dev/random ?
open my $random_source, '<', "/dev/urandom" or die "Could not open /dev/urandom";

binmode $random_source or die $!;

my $random_buffer = "";

my $random_bytes = ceil ($entropy_per_word / 8);

die "Tried to read no random bytes." if ($random_bytes < 1);

while ($pw_entropy < $entropy)
{
    die "Could not read random bytes"
    if ($random_bytes !=
        read ($random_source, $random_buffer, $random_bytes));

    my @bytes = unpack 'C ' x $random_bytes, $random_buffer;

    my $n = 0;

    foreach (@bytes)
    {
        $n *= 256;
        $n += $_ * 1;
    }

    next if ($n >= @words); # don't use %, it will bias the randomness

    $pw .= ' ' if ("" ne $pw);

    foreach (split //, $words[$n])
    {
        # sprinkle some capitalization for good measure
        $_ = uc if (rand > 0.8);

        $pw .= $_;
    }

    $pw_entropy += $entropy_per_word;
}

You are right to use /dev/urandom. Don't use /dev/random: it is not better than /dev/urandom, and in some ways it is worse. This page is a nice summary on that subject.

Your entropy calculation is correct. Entropy is a measure of what the password generation process could produce, not of what it has produced; hence, if you have n words in your list and pick each word randomly and uniformly, then you get exactly log n bits of entropy per word (base-2 logarithm here). The entropy is not reduced if you happen to pick several times the same word. More detailed explanations are available in this answer.

Your looping test:

next if ($n >= @words); # don't use %, it will bias the randomness

is correct. You avoided the bias induced by the modulo operation. However, there is a slight inefficiency here, in that you generate and integral number of bytes. For instance, if your list contains, say, 1000 words, then you will produce sequences of two bytes, hence a number in the 0..65535 range. You will have to loop on average 65.536 times before hitting a number in the 0..999 range. Depending on your context, this may or may not matter; modern computers are very fast, and if the password generation is human driven (you produce a single password for a human user who is waiting for it) then the computer has a lot of computing power to spare, and the dozens/hundreds of loops won't even be noticeable.

If you want to be more efficient, there are mainly two improvements that can be made:

Truncate the byte sequence to the minimal length in bits. For instance, if you have a 1000-word list, the minimal bit length is 10 (because 210 = 1024). This would entail masking out (i.e. clearing) the top 6 bits of the 16-bit random integer. In that specific case, this would mean that looping would happen only in 2.4% of cases, i.e. quite rarely. On a more general basis, truncation to the correct bit length ensures that the average number of loop instances will be no more than 2.
Use a combination of exclusion (when the number is too high) and modulo reduction. With a 1000-word list, this would mean generating a number in the 0..64999 range, and then reducing modulo 1000: the next clause would be triggered only when the 16-bit integer falls in the 65000..65535 range (i.e. not often at all), and the modulo would not induce a bias because 65000 is a multiple of 1000. You might want to take inspiration from the documentation for Java's java.util.Random.nextInt(int bound) method (the documentation includes a code excerpt which is enlightening; this is Java, but the concept applies to other languages as well).

I would advise against the random capitalisations: they don't directly hurt security, but they consume human memory resources for a comparatively mediocre entropy gain. That is, if by not using that capitalisation, you make enough room in your brain to remember a couple of extra words, then that's probably a better bargain. Furthermore, having an all-lowercase password makes for smoother password entry, especially on smartphones.


How can I scan open ports through Windows Firewall? I use Kali Linux and VMWare for testing some penetration techniques.
The problem is that when I scan ports with Nmap to my Windows IP "all ports are filtered". I know that the firewall is blocking the Nmap test.
My question is: how can I scan open ports with Nmap even it there is a firewall?

A port scanner, like nmap, connects to a port and analyzes the traffic being returned. A firewall's most basic function is to block access to a port. This means that there is no way to scan a port that is being blocked by a firewall. With some exceptions...

Some firewalls will allow traffic to a port unless it determines that the traffic is malicious (like a port scanner) and then it blocks the port. Sometimes reducing the speed of the scan can help, sometimes scanning the most probable ports first (80, 443) can work in case the firewall is designed to block IPs that scan blocked ports. Some firewalls can inspect the packet characteristics in order to determine that the packet came from a port scanner (each one has a fingerprint). So, in order to bypass these types of protections, you would need to play with the scanner settings, try different scanners, connect to expected ports with a valid client (browser to port 80), or build your own tool. But in all(?) cases, if the firewall is configured to block traffic to a port, then you cannot communicate with the port.

That said, Windows Firewall does not have any of the above protections. It blocks traffic to ports.


Is it possible to sign a certificate such that the issuer is different than in the CA's certificate? Lets say I have a self-signed root certificate called root-ca.pem created by openssl. It allows me to sign certificates. Is it possible sign new.csr certificate with root-ca.pem such that the issuer from signed new.csr would be different from the issuer who signed root-ca.pem?

It would be possible to do this, but the simple question is: why?

Let us assume that when signing the TBS Certificate you change the issuer DName to something else. If the specified signer of the certificate is different from the real signer then the process of validating the certificate path would fail.

Check out RFC 5280 Section 6 to view the certificate path validation algorithm. One of the key checks is that the subject of certificate x is the issuer of certificate x+1, which in your question is not the case. Thus, the produced certificate would always fail certificate validation.

In all commercial situations you would not be able to do this, because the issuer part of the certificate is not included in the certificate request (check out the PKCS#10 format) and is set by the CA just prior to the actual signing of the certificate.

But if you were doing the actual programming of the certificate signing (using, say, bouncycastle APIs in Java or C#), then you could change the issuer name. However, in doing so your certificate would fail validation by all systems other than a custom validation system that you would have to build yourself.


ASN.1: ENUMERATED vs INTEGER From the X.509 specs:

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

...and...

Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

Why isn't Version an ENUMERATED type?  And similarly, why isn't CRLReason an INTEGER?

ENUMERATED and INTEGER serve different purposes.  ENUMERATED is for creating a list of named items while INTEGER is for carrying numbers.  The fact that the type notation seems somewhat similar does not make them identical.  For ENUMERATED, the only values permitted are those named in the list.  For INTEGER, the named list is just a set of useful labels for specific numbers, and does not limit what values are permitted for the INTEGER type.

I can only assume that CRLReason was made ENUMERATED because there is a closed set of values while Version was made an INTEGER to leave the number of future versions open ended.

Feel free to try some of these specifications at http://asn1-playground.oss.com, which is an online ASN.1 compiler and encoder/decoder that supports not only BER and DER, but also PER, XER and CER.  You will be able to see that differences between ENUMERATED and INTEGER seem more significant for other encoding rules (such as PER and XER) than they seem for BER and DER.


I clicked a Grabify link. Is my phone hacked now? Someone sent me a grabify link on discord. Now they told me they know my IP address, the device's name that I am using, my location and IP address. I am wondering how much else do they know? Should I be worried? What should I do now?

TL;DR: Don't worry, your phone is not hacked.

Essentially they send you a tracking link and they know from which IP address this linked was accessed. They then can match this IP address to your ISP, and might infer a more or less precise location depending on how your ISP assigns IP addresses. This is the kind of information which are visible by any website your visit, i.e. these are not actually secret private information. While the attacker could for example try to DDoS you it is likely more to just scare you in this case. Don't be scared.

You can try yourself what the "attacker" and also any website you visit can see. Just create your own link at grabify, visit it and check the result.

I've tried myself and for example the location is way off  (another town) and the claimed device name is actually only its IP address again. Not actually impressive and nothing to worry about. Depending on the capabilities of your device this might also include the battery level etc. Again, these information are not really secret but might be used to scare you since you don't expect the "attacker" to know this and wonder what else they know. Best check yourself.


Most Secure Way to Install Python on Windows 10 What is the most secure way to install Python 3.X on Windows 10? I have Windows 10 version 1809, and there are so many ways to install Python on Windows, such as the regular way (CPython), IronPython, WinPython, Miniconda or Anaconda, etc (for example, see here). Is there a way to install Python that reduces security vulnerabilities such as a virtualized or "sandboxed" installation of Python on Windows, or is this not needed?

In general, for most users, there's no need to install Python "virtualized" or "sandboxed." A malicious program would have the same "permission" level (run all the same user level OS assembly instructions) with or without Python installed. Python would only be a vehicle for execution.

Before installing any program, it's always good to verify the integrity of the application either through a posted hash, or ensuring that the code-signing certificate is valid and from the correct publisher (especially when downloading from non-official websites). This would mean a high confidence the application wasn't modified before it got to your computer. For trusted programs like Python, this is much more important than sandboxing.

If you wanted to take this up a notch, you could always install Python on a virtual machine and do all your work on the virtual machine. This would virtually eliminate the possibility of adverse effects on your main machine (though, certain vulnerabilities like spectre and meltdown could still theoretically affect your main machine from your VM).


Device visibility on a network At my college dorm's Wi-Fi network, one device can play to any other network-connected, YouTube-enabled device on that network. Apple devices can also AirPlay to the one Apple TV connected here.

How would the IT Staff here make the visibility from one device to another zero? In other words, how would a member of IT make it so some device can't tell the TV is there and start randomly playing videos to it?

The reason other devices can see each other on the campus network is because all the clients are on the same "subnet" or area of the network, in which case there is no filtering.

NetBIOS, Bonjour and other discovery services use the "broadcast" ip of the network to advertise the machine's presence.   So, let's say the campus network internal range is 10.0.0.0-10.0.255.255.  They would send packets to 10.0.255.255, to advertise the presence of the device to the rest of the network.  Essentially, they keep sending a message that says "I'm Here! I'm this device!" to everyone on the LAN.

Restrictions for broadcast-based services like NetBIOS and Bonjour can be put in place at the switch level, provided layer-3 capable "managed switches" are used.   There are many ways to handle this, IT can make it so each device can only communicate with itself, or to a subset of the network (e.g. an individual VLAN).  The broadcast for the domain can also be disabled entirely, but either approach might cause issues for users trying to get things to work like chromecast etc.

Often this requires fine-tuned rules.  For example, the MAC address of the Apple TV can be set to a static IP reservation.  Then, this static IP can be allowed to receive traffic from certain other devices, but not others -- so only authorized IPs may send video traffic.  As you can see however, this is cumbersome to maintain and many network administrators just leave the network open internally.

As a side note, out of the box many WiFi access points support restriction of clients so they cannot communicate with other machines also connected to the network, only the internet.


Is VRFY command enabled on SMTP server usually considered a vulnerability? Messing around I found a critical SMTP server with VRFY command enabled.

Yes, but often as part of a combination of vulnerabilities. For example, if you find a system that has a login (FTP, telnet, or other) that needs a username and password, and there's an SMTP server on the same network or even server, then the VRFY command  (can often give clues to the usernames that might work for brute forcing the login.

Sometimes these very 'minor' vulnerabilities, often leaks of information, can be combined into something more serious.

Unless there is a very good reason to have this function on an SMTP server, it's a good idea to turn it off.

Similarly, you could consider silently dropping emails to non-existent accounts so that the email server can't be used for user enumeration (bouncing off emails looking for failed deliveries), but this is controversial because it's sometimes more important to tell legitimate users that they have made a mistake in the email address (and with silent drop they wouldn't know).

And... it suggests that the server lock-down might not be as good as it could be and might be worth looking at a little more closely!


What prevents web shop owners from misusing credit card data? I don't own a credit card but read much about fraud with stolen credit cards. Since I don't own one, I don't know how you exactly buy online using your credit card, so please correct me, if I am wrong (and I hope so).

Customer choses articles in online shop and puts them into shopping
cart.
Customer goes to the virtual check out.
Customer enters delivery address and his cc data(?) and sends them to the server of the shop owner.
Shop server sends the cc data the customer entered and his data and the amount to the cc card server and receives the money.
Customer receives bought articles.
The shop owner wasn't very honest and uses the cc data the customer entered to shop on other online shops (especially
non-trackable goods like software licenses, ...). Since the data is
the same for all shops, nobody knows which shop misused the cc data.

Why not use an one-time authentification code or token instead? For example the customer enters the cc data on the server of the cc company which sends a confirmation to the shop owner or gives a signed token (like gpg) which the user gives the shop to prove he sent the money or the shop just waits till it sees the money on its account?
Since I have basic it-security knowledge you might also add technical details.
So are my assumptions right and if so, what prevents web shop owners from misusing credit card data?

The liability for a disputed transaction falls upon the merchant for Card-Not-Present transactions.  Essentially, if you dispute a transaction, if the merchant doesn't have your signature, then if you persist they will end up footing the bill.  By the same token, when a CNP merchant double bills you, they're going to end up paying when you dispute the bill.

As @DavidFoerster points out, the processors and card companies track chargeback rates.  They eye the statistics and, when a merchants is having too many chargebacks, they get cut off.  (Usually they get booted from their processor, and go find another processor who'll charge them more for the higher risk).

The same is true with stores that re-abuse cards elsewhere.  The card brands look at fraud reports and determine that these 20 fraud report cards all had Bob's Web Shack in common as a past transaction.  They will then investigate Bob's Web Shack - both because it might be a bad shop owner, and because it might be a shop that's compromised.  And - again - if a shop is a source of problems, they'll get cut off.

That's what prevents web shop owners from abusing the cards.  They'll lose any disputes, and then they'll get dropped and be unable to process cards.


Are fingerprint scanners easy to bypass? Thinking about adding a fingerprint based authentication layer, but then I recalled the MythBusters beat fingerprint security system episode -- is this a common issue, and if not, how do you tell if a fingerprint authentication system is easy or hard to bypass?

Fingerprints can be viewed as a fuzzy source of data. Given the same finger, a reader might never read exactly the same print. That is why most readers require the user to scan a finger multiple times during the registration phase.

During the authentication phase, the system tries to determine if the scan it just acquired is "close enough" to the trained data to allow access. This leads to two problems.

Remote authentication
Keeping biometric private

Remote Authentication

Assume I keep my biometric private (we'll deal with that problem later). Can I give another party enough information to correctly authenticate me without requiring them to store enough information to impersonate me (i.e., if someone steals the database, I don't want them to be able to impersonate me)?

It turns out you can. The functions needed are called secure sketches and fuzzy extractors. A secure sketch (SS) is given some data (w) and returns string (s) in other words SS(w)=s. A secure sketch also has a recovery function (Rec). Rec takes as input w' (a noisy copy of w) and s. If w' is sufficiently close to w (where closeness is measured by some distance metric such as hamming distance), then Rec(w',s)=w. Now the server and I share a secret value (namely w) which we can each prove knowledge of to authenticate each other (mutual authentication).

The cool thing about this is that even if someone steals s, they won't be able to impersonate me. There are a few problems with this, however. What if the attacker modifies the copy of s that the server is storing. Could they do that in such a way that w is leaked? In the original work, there were no guarantees that this couldn't happen. Later research, however, removed this restriction by developing what is called a robust secure sketch, which is secure even in the presence of an active adversary (i.e., an adversarial controlled channel).

Keeping biometric private

The above ideas all assumed that w (and w') were kept private. This is probably not a good assumption as seen on MythBusters. So, researchers went back to the drawing board and said "Hey what if my fingerprint was my public key" and thus Fuzzy Identity-Based Encryption (FIBE) was born.

Closely related to this is Identity Based Encryption, where my identity (e.g., email address) is my public key. Someone uses my email address to encrypt a message. I then prove to a third party that I own the email address, whereupon I am able to retrieve the corresponding private key and decrypt the encrypted message. It is important to note that the sender only needs some public information from the third party to enable her to encrypt messages to any identity. The receiver must at some point (either before or after the encrypted message is actually sent) retrieve his private key.

FIBE builds upon this idea for fuzzy identities. You read my fingerprint (w), I use w' to get my private key and as long as w and w' are close enough, I am able to retrieve the message you send to me (I still have to contact the third party at some time though). An authentication protocol could be built on this so that I need not keep my biometric private.

The major problem with this system (and IBE in general) is the requirement of a third party and the fact that that third party can impersonate me once they have seen a copy of my biometric. The latter problem can be removed by having multiple third parties who all contribute to the process. Thus, no single one can impersonate me. But, then I have to contact multiple people in order to encrypt or decrypt messages.

Application

I'm not sure if any commercial products implement these ideas. So, I cannot speak to commercially available products, but if you are not limited to commercially available products, you could implement these systems yourself and they would probably be pretty secure.


AES encryption on embedded device: Can this be secure? I plan to create an encryption program for an embedded device with the following characteristics:

CPU is Intel 80186 compatible @ ~20 MHz
128 KB RAM, of which I have ~20 KB at my disposal for purposes of encryption
application binary size limited to 128 KB, but I'd like to keep the encryption part < 16 KB
persistent storage in Flash memory

These are the requirements:

encrypt small text files and bitmaps < 32 KB
I can always decrypt the entire file to RAM, i.e. I don't need random access
the encrypted files are not "locked in" by the hardware, i.e. they can be transferred to a PC at any time, so I want to protect against someone who steals the device and tries to decrypt the data
I am not worried about software exploits, keyloggers and so on (assume I never borrow the device to anyone and keep it under my pillow at night, and also assume the NSA doesn't break into my house to chloroform me and install a targeted exploit)

I'm far from being a crypto expert, but I spent some time reading Wikipedia on AES, block cipher modes and key derivation algorithms, and I also read "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong". All this has made me doubt whether I can succeed given to the limitations of the hardware and my superficial knowledge of the subject, but I'll try.

The following steps line out what I plan to do:

I plan to follow the basic procedure lined out in this response, that is: encryption with AES in CBC mode, key derivation with PBKDF2, random salt, random IV.
Because I'd prefer AES-256 instead of AES-128, I would use PBKDF2 with SHA-512 so I can derive a key of double length.
There is no reliable random number source on the embedded device, so my plan is to have the user generate the random key (k1) on a PC and transfer it (probably by manually typing it in). This should not be a problem because it only happens once, i.e. I use the same key (k1) to encrypt any number of files.
The play/essay "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" points out the dangers of an attacker who has control over the encryption process, i.e. who can supply arbitrary plaintext and have it encrypted, because this enables all kinds of side-channel attacks such as "error oracle". Am I right to assume this is not an issue for me because the attacker only gets to see my encrypted files?
My understanding is that I should generate a random IV and salt for every individual encryption so as to avoid identical outcome for identical plaintext. But do IV and salt have to be cryptographically strong random numbers? The best I can do would be a Mersenne Twister (or preferably something more efficient) seeded with hash(concat(time, battery voltage)); but is this neccessary at all? I store both IV and salt in plaintext anyway, so I only need to make sure they are different each time, not worry about their predictability.
I plan to use either this implementation or one of the implementations linked here, of course after verifying them with the NIST test vectors. Is there anything else I must check for when choosing an implementation?

I'd be grateful for comments telling me which parts are wrong, unsecure or should be improved. Also, if there is a trusted AES-256 implementation for Intel 80186 I'd love to know about it. And finally, if you think it is hopeless, don't hesitate to tell me.

You don't specify a use case for this, so it's difficult to understand the limitations, and if this is "secure".

You didn't mention using an HMAC, but I'm assuming you're aware of the need for one under certain applications.

You want to use AES-256 over AES-128, but don't specify why.  AES-256 requires 14 rounds, vs only 10 for AES-128, so AES-128 is considerably faster, which may be significant in the very limited environment you're dealing with (16 bit words for instance).  AES-128 is already extremely secure, and there's little if any additional security offered by a larger keyspace, especially if you're using user typed passwords which almost never have a full 128 bits of entropy.

IV doesn't need to be unpredictable (the IV must be known to any attacker anyway).  The only important thing about an IV is that it's not re-used.  Personally I'd use a random seed that's hashed every time a new file is encrypted, and the results saved back the random hash.  The next IV will always be predictable, but given enough initial entropy will never be re-used, even globally across all devices.


Could a compromised root CA impersonate any SSL certificate? My question is about MITM attacks against https and how those would appear to the end user.

Suppose a trusted root CA were compromised / coerced into producing fraudulent SSL certificates. What would such certificates be able to achieve, specifically about MITM type attacks?

For example take Facebook, if I go there I get (1) a padlock, (2) a certificate signed by DigiCert, and (3) I can check the SHA Fingerprint matches some value 81:AB:etc.

My assumption is that if DigiCert were the compromised CA, then a fake certificate matching 1, 2 & 3 could be produced, is that correct? Is there anything else in the SSL security model that would make a fake certificate distinguishable from the real SSL cert that was actually issued to Facebook? Or anything else that would allow detection of MITM type attack based on this cert?

My second assumption is that if a CA other than DigiCert were the compromised CA, then a fake certificate could be produced, but it wouldn't say "DigiCert" on it, and it wouldn't match in terms of SHA key? Is that correct, or would it be possible (purely from a technical point of view) for a root CA to create a certificate impersonating another root CA? If so, would there be any other way to detect that a connection was encrypted with this fake cert? Could another CA create a cert apparently having the same SHA key?

This question is inspired by Britain's upcoming "snoopers charter" which is slated to give the authorities many powers to spy on digital communications. The point being how useful such powers might be in the face of encryption, as there has been some talk of using "black boxes" performing deep packet inspection to collect information that providers (eg Facebook) might not choose to share with Her Majesty's Government. My guess was that such techniques are not possible (certainly not with DPI I would hope!) but the possibilities of fake certs and MITM attacks is not really clear to me. I am guessing it wouldn't be attempted if only for political reasons assuming fake certs could be detected by tech-savvy clients.

Such compromises already happened and DigiNotar is just on example. In effect the attacker could impersonate almost all certificates this way, because for most certificates it does not matter who signed it but only that it was signed by a CA trusted by the browser.

There are few exceptions which are thus safer:

Chrome and Firefox (and IE with EMET?) have the fingerprint of the public key for some very important sites hard coded  (pinned) in the browser/OS. In this case the fake certificate will be detected, as was done in the DigiNotar case.
With HPKP sites can offer their keys for pinning into the browser on first use, even if the browser was not shipped with these keys pre-pinned.
Extended Validation certificates (EV) can only be issued by selected CA, which are hard coded into the browser.

Of course one could in theory detect such wrongly issued certificates by comparing the fingerprint. There are extensions like Certificate Patrol which notify the user if the certificate of a previously visited site has been changed, but it is still up to each user to decide if the change was correct or if this would be an attack. Extensions like Perspectives try to simplify this process by comparing the certificate against the certificates seen by other users. But none of these facilities are currently shipped with the browsers.

Note that this re-creation of certificates is often done legally in SSL intercepting firewalls, which need to get access to the decrypted content in order to detect attacks. But in this case the new root CA is explicitly added to the browser as trusted. For these CA's, which are not shipped with the OS/browser, HPKP and pre-pinning are usually ignored by the browser.


What options exist for authenticated full-disk encryption? Title says it all really.

I'm toying with the idea of storing some disk images in "the cloud", but am concerned about the possibility of an attacker manipulating cipertext to do evil things once it's decrypted, and so I'd like a system that authenticates the ciphertext and assures me it has not been tampered with.

I understand that this will require a (small?) amount of local, non-cloud storage, which is a cost I'm prepared to pay.

I haven't been able to find any off-the-shelf packages that do this (or maybe I just don't know how to do it with existing tools). Can anyone point me in the right direction?

I will have call to read disks from Linux and Windows (seperately, ie, windows images and linux images).

From your example, I think the answer is pretty straightforward. I think there are several ways to do it depending on your preferred workflow but the simplest is probably...

When you update the image, take a hash of the image before uploading it. Then, when you download it, check the hash before use.

Of course, that is only reasonable if you don't update the image that often. Otherwise, you need to automate the workflow.

More specifics depend on what OS you are using the image on. The good news is that, since you have control of the hash, you probably don't need to worry too much about which hashing algorithm you use. Some have known flaws but I think that, in this case, that probably won't worry you too much.

You could go further and digitally sign the image and there are certainly tools that will do this for you. Have a look at some of the forensic disk copiers. Using such a tool will give you a very high degree of confidence that the data has not been altered.


Email used to log in but doesn't have to be unique. Issues? I've moved onto a project where they are implementing a system whereby a user's email address can be used multiple times by different people - i.e. users can sign up as many times as they want with an email address as there's no unique constraint. The theory is that they won't have actual access to the email account so it's not a problem.

I can't think of any issues with this but something about this approach doesn't feel right. The email address is not used as a unique identifier although people log in with it but what potential issues, if any, could rise with this approach?

Edit - Resetting a password doesn't send an email, their theory is that if the user has stolen the phone, they likely have access to the email address on the phone. Instead, they need to enter security questions/answer else they need to create a new account (which is why they want to allow duplicate email addresses). My worry is that this somehow creates a new attack vector for hackers but can't figure out how and I may just be wrong.

Thanks

I'm assuming that in the case of duplicate accounts, different passwords are used as the means of distinguishing between these accounts?

i.e. if there are two bob@example.coms, one with password foo and one with bar then the password will be checked to find out which account to log the user into.

Problems with this approach would be:

If one user with an email address sets their password to the same as another account with that email address, then there is no way to warn the user without revealing that the password matches another account.
Account lockout policies cannot identify the account to lockout because the password has not been entered incorrectly.
Using a secure password storage algorithm such as bcrypt becomes impossible because there is no unique index on which to find the salt in order to determine if you have a password match. Each matching account would have to be tested, leading to long delays on login as each password hash is attempted.
Any password guessing attack against a user account has multiple attempts to succeed from each request, aiding an attacker.


How to investigate my wifi router for devices which are disconnected earlier I have a D-link 600M router with a simple WPA2 password that got cracked. 60 Gb of data was downloaded (I think they downloaded torrent movies), which resulted in the renewal of my data plan. I searched for devices in the status of my WiFi router but found no results.

Is there is any way I can use forensic tools to find the devices which attached to my router? I'd like to know their MAC addresses to be able to catch the culprits.

Do WiFi routers log data about devices that are now disconnected? My router currently only shows those devices which are actively connected in the status window.

You should be able to access their MAC address in the ARP table on the modem, but this have two problems:

The MAC Address is easily spoofable, so this invalidates the the white/black list solutions.
This model of modem has no way to consult the ARP table, so no way to know.

About the logs, it depends on the model, this is product baseed, so you should check the settings if it logs anything and if it's doing it.

Maybe you can try a ping sweep on you local network while they're using it. Or also handle/modify the DHCP so you assign/manage manually IPs, but this reduce functionality by a lot and still has some workarounds.


How does replacing/overwriting data work in Bell-LaPadula? We don't have write-down in Bell-LaPadula (star property) however does this apply only to appending or does it also apply to overwriting data?

No write-down means you can't perform any action to make changes to a system below your authorization level. The purpose is to prevent higher authorized entities from intentionally or unintentionally leaving classified data in an inappropriate location. Applied properly, this should mean that appends, overwrites, new files, etc. cannot be written/created/appended/edited in any way.


Replace application's AppArmor profile without process restart I'm using AppArmor in complain mode for a process in our production environment and I see some false positive profile violations in my logs. I'd like to roll out an updated profile but I cannot restart the process.

Is there any way to replace an AppArmor profile without restarting the confined process? How to make sure that the profile has been correctly replaced?

I found a function aa_replace_current_profile() that can replace current process profile. But I don't know how to replace the process you want.


Anonymous surveys that aren't so anonymous In the past I have completed an 'anonymous' survey at work only to find that my employer was able to garner a lot of not-anonymous information from this survey.  Location, name of manager, etc.  None of this information was provided in the survey.  This leads me to believe that somehow the website has been able to identify some form of user information.

Is there a way that a webpage can read user or other system related information?  The site in question has aspx and js elements.

I cannot think of any other way they could identify the user.  The link doesn't appear unique.  Browser is IE, environment is Win7 on Citrix.

If the site is based on ASPX files, then it is more than likely that this is a ASP.NET application - most probably hosted on IIS.

IIS has a very simple checkbox to enable Windows Integrated Authentication.

IE, on Windows 7, will by default send your credentials to any web server in the local intranet. (This is not your password, don't worry, but it is Windows based authentication - either Kerberos or NTLM).

This is very straightforward to associate your Windows Domain account with your survey answers...


secure ways to prevent access to an application by more than one person at a time? If an application is licensed in such a way that is set up for one user, on one computer, how can I secure it?

Even if locking into one computer, how could you prevent the computer from being remotely accessed by others, so that only one user can use the application at a time.

I am curious if there is an security precautions that one can include to stop people from accessing an application more than once?

My ideas were

I was thinking of testing System properties for Server versions of Windows, etc, but then I realized you can remote into any computer, with a variety of programs, so that is out the window.

2.a  I was also thinking of setting a flag in my application that I could send/receive from the server, so that the application wont launch again if it's opened already by someone else due to that flag being true?

Is it a security issue if I connect to my server, with FTP, before the application even logs a user in?

2.b  Since the users login could I also set that flag once that user logs in, so that they can't log in again? (I think this should be done regardless, since a user should only log in once).

I also thought about trying to find and see if the application is already running on the machine (as a process or task i.e., what shows in "Task Manager").

I'm not sure which of these are viable solutions(Would have to research how to do some of this), so I'm curious if anyone has a better example?

Thanks for the info.

secure ways to prevent access to an application by more than one person at a time?

There are no secure way to prevent users from running more than one instance of your application on their machines if they have a copy of your application. If a user has a copy of your application, they can always find ways to subvert any checks you make.

The only secure way to limit user's access to your application is to not run your application in the user's machine. In other words, a web application.

DRM can do an OK job to prevent users from using one instance of your application at a time for licensing reason. But trying to run trusted code in untrusted machine is inherently insecure.

DRM is a losing game for developers and legitimate users alike. License infringer will always find a way around DRM and DRM often will find ways to inconvenience and alienate legitimate users, which increases support costs.

  I was thinking of testing System properties for Server versions of Windows, etc, but then I realized you can remote into any computer, with a variety of programs, so that is out the window.

An illegitimate user can always edit any files/settings/registry in their computer. There's nothing you can do to prevent this. They are the one with system administrator privilege, not your application.

  Is it a security issue if I connect to my server, with FTP, before the application even logs a user in?

Unless your application heavily rely on the network connection as part, you cannot rely on the network connection. If your legitimate user does not have internet connection at their home, your application will either have to refuse to run (inconveniencing legitimate user) while an illegitimate user can just disallow your application from accessing the internet using an application firewall.

  I also thought about trying to find and see if the application is already running on the machine (as a process or task i.e., what shows in "Task Manager").

This would not protect against running on different machines or running your application in virtual machine. On the other hand, legitimate users may need to legitimately need to run multiple copies of the application, or your application may be stuck as an unkillable zombie process in the background and legitimate user may find themselves needing to reboot their system to restart your application again.

Licensing restrictions and DRM can only keep honest people honest.

"My application truly cannot be run as a web application, because X, Y, and Z. With DRM being futile, what can a software developer do to protect their revenue?"

If you develop a great application at a reasonable price, people will want to pay for it. Put up a simple license check you can put together in a couple hours or even go DRM free, and be done with it. Accept the risk that there will be illegitimate users and use legal measures to attack major infringers (circumvention of even simple DRMs like dumb license key check is legally protected in many countries). Avoid DRMs that do weird things like implanting itself in the MBR/boot sector or trying to hide itself from System Administrator as a rootkit. They are more likely to cause legitimate users frustrations than to hinder illegitimate users.


What are my options for securely printing an OTP Scratchcard? I want to print and distribute several One Time Passwords (OTPs) that can't be easily disclosed to a 3rd party in transit. (think the physical version of a TLS session for private secrets)

To me that means I need a non-electronic list of passwords that are protected by a physical means such as a secure envelope, or silver coating.

What are my options as far as printing and distributing these OTPs to end users?

One of the first options that come to mind is to have a company like BABN/Oberthur Technolgies print this with a scratch off similar to how they print lottery tickets, however they are only interested in high volume distributions.

Based on my experience in the lottery ticket industry, there is a lot of technology that goes into the silver coating, and often there are several layers of ink and patterns laid on top of each other.  And even with this, some ink layering techniques are better than others.

What "scratch off" technology is secure enough for an OTP password?  What should I avoid?

As an alternative to the silver coating, perhaps a perforated envelope could be used.  ADP is well known for their secure printing facilities (for checks) that make it difficult to impossible to view the contents of one of their tamper evident envelopes.  Again, they aren't in the business of distributing OTP tokens to end users in small volumes.

Are there any in-house or outsourced opportunities available?
What other physical features should I look at w.r.t. a OTP password list (waterproof, etc)

Tamper-evident systems (like the scratching technology you evoke) are not exactly what you want for an OTP. What these technology offer is a way to make sure a posteriori that the information was not disclosed. If you see the card and it is still unscratched, then you know that the OTP is still "secure" and has not been used by anybody. The security benefit for an OTP situation is indirect at best: it means that the theft of an OTP will ultimately be discovered when the intended OTP user finds the card already scratched -- that is, if he finds the card. The attacker could simply purloin the card, scratch it, use the OTP, then throw the card in a river.

What you want for OTP is something which the users will find easy to keep secure (physically) until time of usage. Using credit-card sized devices is a good idea: the most secure storage system which is available to most users is their wallet. But there is not much to be gained by making them "scratchable".

For an OTP list, you want something where users can easily "tick off" uses passwords. This might be a "tear off"; after all, once used, an OTP is useless to everybody and can be disposed of without any care (except ecological). You could imagine a small stack of stick-up notes, each with its own OTP printed on it.


How to choose a linux for learning? I am beginner in Security. My first assignment is about "Linux firewall using IPTABLES" . I know about Ubuntu, backtrack and kali Linux.

How to choose a Linux distribution to learn about security?

For such a beginner and general subject (no offense! everybody has to begin somewhere!) such as iptables, any Linux distribution would be fine.

Choose one with which you feel comfortable, does not cause incompatibilities with your hardware and provide a large choice of packages so you will not be limited when having to install new software. DistroWatch is a good information source about current Linux distributions.

Afterward, depending on your studies, you may evolve toward a more specialized distribution. Some distribution provide already installed software or configuration hard to adapt on others (however the base system will still remain the same: Linux remains Linux, so the general experience and knowledge acquired on your favorite distribution will remain valid on others).

For instance:

You mention Kali Linux. This distribution provides a lot of pentesting tools pre-installed (ie. the offensive side of security). Most of these tools are also available on any other distribution though, so this should not prevent you from trying another distribution which might better match your personality and needs,
On the defensive side of security, you will see that different distribution may implement different systems (some ship with a pre-configured SELinux while some rely on AppArmor instead, some ship with a Linux kernel with grSecurity patch applied by default while some other do not, etc.). Here, the subject of your studies will lead you toward the most suited distribution (for instance I would not recommend to use an AppArmor based distribution like OpenSuse to study SELinux, CentOS or an Hardened Gentoo would be more suitable), however these are more technical and non-beginners subjects dedicated to people already fluent with Linux systems,
I should also mention distributions specialized in the forensic side of security, but most chances are that here again, most of the pre-installed tools are also available in any other Linux distribution. Moreover, a lot of these distributions are made for non-Linux people, making evidence collection more easy using semi-automated procedures, but keeping you from acquiring new Linux knowledge.

As a final word, I see a general tendency when dealing with security to always go toward Kali Linux, more for a fashion than objective reasons. Do not hesitate to try different distributions (virtual machines are great for such things!) since most provide a different feeling to the user.

Linux is meant to provide a free and open world so take advantage of this liberty to find a distribution with which you feel comfortable, most tools can be installed afterwards. The worse you could do would be to restrain yourself to a distribution making you feel uncomfortable: it would restrain your learning too.


Rationale behind hiding originating IP address in emails? Gmail has been hiding originating IP addresses for quite some time now. Hotmail and Yahoo have started doing this too.  Apart from obvious privacy implications of revealing the sender's IP address, is there another security aspect of hiding (and in many cases, hashing the originating IP address)?

Hiding the originating IP can also help protect against attackers / phishing attackers that gain knowledge of the internal network of companies by getting the ip's of employees from the 'auto' mail replies.

But I believe the main reasoning is privacy.


Why does MD5 hash starts from $1$ and SHA-512 from $6$? Isn't it weakness in itself? I have moved this question from stackoverflow to this place. I know it may be a question about 'opinion' but I am not looking for a private opinion but a source of the final decision to keep it this way.

I have been taught that nobody tries to open a door when one does not know that the door even exist. The best defense would be then to hide a door. It could be easily seen in the old war movies - nobody would keep a hideout in the light. It was always covered with something suggesting that 'there is nothing interesting there.'

I would assume that in cryptography that would work the same way.
Why would then hash generated by MD5 started from $1$, and telling what this is a hash in the first place, and then what kind of hash it is (MD5)?

Now, I see that sha512 does exactly the same thing. Isn't it a weakness by itself? Is there any particular reason why we would have it done this way?

The main question the is: Should I scramble my hash before storing it to hide this from a potential enemy? If there is no need for that then why?

To avoid answers that suggest that obscurity is not security, I would propose this picture. It is WWII. You have just received a hint that SS is coming to your house suspecting that you are hiding partisans, and this is true. They have no time to escape. You have two choices where you could hide them - in the best in the world safe, or in the hidden hole underneath the floor, hidden so well that even your parents would did not suspect that it is there. What is your proposal? Would you convince yourself that the best safe is the best choice?

If I know there is a treasure hidden on an island then I would like to know which island it is or I will not start searching.

I am still not convinced. Chris Jester-Young so far gave me something to think about when suggesting that there can be more algorithms generating the same hash from different data.

First, there's Kerckhoffs's principle which is always desirable:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

where in this case the password is the key.  So its not a goal to keep the cryptosystem secret.

Second, you are wrong about those being md5 or sha512 hashes; the values stored in your /etc/shadow are md5crypt or sha512crypt, which involves a strengthening procedure (many rounds of a md5 or sha512 hash).

Now if your four choices are MD5crypt, sha256crypt, sha512crypt, and bcrypt (the most popular choices in linux systems), here are four hashes all generated with $saltsalt$ (or equivalent) as a salt and hashing the password not my real password:

>>> import crypt
>>> crypt.crypt('not my real password','$1$saltsalt')
'$1$saltsalt$4iXfpnrgHRXkrDbPymCE4/'

>>> crypt.crypt('not my real password','$5$saltsalt')
'$5$saltsalt$E0bMpsLR71z8LIvd6p2tD4LZ984JxyD7B9lPLhq4vY7'

>>> crypt.crypt('not my real password','$6$saltsalt')
'$6$saltsalt$KnqiStSM0GULvZdkTBbiPUhoHemQ7Q06YnvuJ0PWWZbjzx3m0RCc/hCfq54Ro3fOwaJdEAliX9igT9DD2oN1u/'

>>> import bcrypt
>>> bcrypt.hashpw('not my real password', "$2a$12$saltsaltsaltsaltsalt..")
'$2a$12$saltsaltsaltsaltsalt..FW/kWpMA84AQoIE.Qg1Tk5.FKGpxBNC'

Even without the annotation, its fairly straightforward to figure out which scheme they each use (md5crypt, sha256crypt, sha512crypt, and bcrypt are 34,55,98, and 60 chars long respectively (in base64 encoding with annotation and salt).  So unless you suggest truncating the hash, or altering the hashes properties the annotation for consistency doesn't lose any security.  It also gives you a method to gracefully update user passwords.  If you decide that md5crypt is no longer secure, you can switch users' hashes to bcrypt on next login (and then after a period of time deactivate all accounts left on md5crypt).  Or if your algorithm like bcrypt (when it was $2$) needs to be updated, because of a flaw in design you can readily identify flawed schemes when the fixed scheme went to $2a$.

Even worse, you could try saying, I'm going to modify sha512 with new constants and round keys.  That would make it superhard to break -- right?  No, it just makes it super hard for you to know you didn't accidentally introduce a major vulnerability.  If they can get at your /etc/shadow, they probably can also get at the library used to log you in and with time could reverse engineer your hashing scheme and this will be MUCH MUCH simpler than breaking a strong password.

Again, the expected time to brute force a very strong passphrase stored in sha256 hash is O(2^256 ), e.g., a billion computers doing a billion sha256crypts  per nanosecond (each involving ~5000 rounds of sha256), would take 300000000000000000000000 (3 x 10^23) times the the age of the universe to break it.  And with sha512crypt, if each of the ~10^80 atoms in the observable universe each did a billion sha512crypts every nanosecond it would still take 10^38 times the age of the universe.  (This assumes you have a 256-bit and 512-bit or higher entropy passphrase).


Is it possible to use “cryptographic hash function” for “digital signature”? I understand that a cryptographic hash function is a function that generates a fixed size random string for an arbitrary input.

However, is it possible to use a cryptographic hash function for digital signature?

Is it possible to use a cryptographic hash function for digital signature?

You can't use a hash function as a signature, but you -already- use a cryptographic hash function as part of procedure for a digital signature.

Let's first, mention some common reasons for applying a digital signature to communications:

Authentication
Integrity
Non-repudiation

Why we need Integrity?

If a message is digitally signed, any change in the message after signature invalidates the signature. Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this is still considered to be computationally infeasible by most cryptographic hash functions (see collision resistance).

What are these cryptographic hash functions?

A cryptographic hash function is an algorithm that takes an arbitrary amount of data input—a credential—and produces a fixed-size output of enciphered text called a hash value, or just “hash.” That enciphered text can then be stored instead of the password itself, and later used to verify the user. source

What's the procedure to sign a message?

source


Cross-platform browser link highjacking/redirect issue in Chrome I'm having strange issues using Chrome Version 65.0.3325.181 (Official Build) on PC (Win 7) and OSX (10.11.6) on different systems.

Clicks are often being hijacked taking me to different sites (often gambling ones). Or alternatively, clicks are being filtered through redirect domains. This is happening on websites that I am logged into (some of which, worryingly, contain real-money wallets) as well as Google.

Two examples:

The most common one. I click a link. So fast that I don't even notice it, the click goes through an intermediate redirect URL. I only see this even for a fraction of a millisecond if for some reason the redirector is slow or breaks. e.g. clicking a link in google for a bike part takes me to the website but via

https://datds.net/replacement/click?place=1234&subid=abcd1234&href=http%3A%2F%2Fwww.chainreactioncycles.com%2Fbmc-sl-048-straight-edge-carbon-fork%2Frp-prod106545&replacement=5292&url=https%3A%2F%2Fwww.google.co.uk%2Fsearch%3Fhl%3Den%26ei%3DoW7WWtWpFuebgAbG4bGQDA%26q%3DBMC%2BCarbon%2Bfork%26oq%3DBMC%2BCarbon%2Bfork%26gs_l%3Dpsy-ab.3..0j0i22i30k1.7400.7933.0.8178.5.5.0.0.0.0.205.398.1j1j1.3.0....0...1.1.64.psy-ab..2.3.398...0i22i10i30k1.0.qtLNgCu6_XE

The place and subid query parameters are the same every time, I'm not sure about the rest.

There is another domain I've seen a few times which is r.srvtrck.com.

Less frequently, I'll click a link on a site or on google and be taken to a completely different site. Again, it seems to be done through a redirect domain first and often sends me to gambling sites with affiliate information included in the URL. An example with be sending me to https://mostmgb.com/?cid=85450330.

This only happens a small fraction of the time and I can't find any pattern with linked-to or linked-from sites.

I've run Malwarebytes and checked the extensions on both systems and can't track down the issue on either. HOSTS files on both systems are clean and I'm not being led through any proxies.

Well, your symptoms tell me that this should be a sort of adware program. I mean all these hijacked links and ending up on these random websites are certainly signs of an adware-like infection. It is one thing that Malwarebytes didn't find anything related to this. I wouldn't give up there. I would scan my system with Adwcleaner or any other free or trial version of reputable antimalware software you can trust. On top of all this, I would also reset my browser(s) on a just in case basis. I hope this makes sense and helps solve your issue.


Questions regarding AES 256 i have googled and searched quite alot but most things just state the same things but not answering my questions
so hopefully you guys can help me out abit

Story:
i am looking at creating an encryption software for my self and friends to encrypt messages & files with AES 256 (in java)

Questions:
Serval other softwares using AES 256 encryption support any key length such as a 10char insted of the 16. how is that possible (such as winzip's aes encryption)?
the same way the other way. how can the encryption depend on the key strength when the key has to be 16 chars
what i was thinking was if the passharse was less than 16 then fill the remaining chars with a predefined seed if the passharse was longer than 16 then use the overlapping chars as a salt.

am i missing something completely? how can the encryption strength be based on how good the passharse is when its required to be 16 chars regardless

how would i go about securely using AES256 yet still beable to encrypt other peoples files (who uses the same software)

and last question is there anyway to notice what type of encryption is used? do they have a patten that can be seen in the hex ?
would having multiple encryption types (with same passharse or predefined modification) do any good?

NSA has stated they can crack nearly anything with a farm of super computers
is a 16 char passharse really that hard to brute with a datacenter full of super computers

Serval other softwares using AES 256 encryption support any key length such as a 10char insted of the 16. how is that possible (such as winzip's aes encryption)?
the same way the other way. how can the encryption depend on the key strength when the key has to be 16 chars what i was thinking was if the passharse was less than 16 then fill the remaining chars with a predefined seed if the passharse was longer than 16 then use the overlapping chars as a salt.

They are transforming the passphrase into a key, by using the hash of the password or other key stretching mechanism.
Of course, any other software wishing to interoperate with your software shall implement it the same way. Just like your program should be using an IV or using AES in some cipher mode (EBC, CBC, CFB, CTR…).
Concretely, zip specification will combine the user-provided passphrase with two salt bytes and use 1000 rounds of HMAC-SHA1-based PBKDF2.

am i missing something completely? how can the encryption strength be based on how good the passharse is when its required to be 16 chars regardless
how would i go about securely using AES256 yet still beable to encrypt other peoples files (who uses the same software)

You have to follow the zip AES encryption specification.
Alternatively, use a library which already handles that for you, like 7-zip

and last question is there anyway to notice what type of encryption is used? do they have a patten that can be seen in the hex ? would having multiple encryption types (with same passharse or predefined modification) do any good?

zip files have a field indicating the kind of encryption used.

NSA has stated they can crack nearly anything with a farm of super computers is a 16 char passharse really that hard to brute with a datacenter full of super computers

A 16-byte key is a 128-bit key, which nowadays is considered. Note that this is quite different to a 16-character password, which would be ~70 bits.


What is a good source for hardened base configurations I attended B-Sides in Orlando FL where one of the speakers had mentioned a site which contains hardened configs for popular services such as apache and postfix. The author of these configs is anonymous and although he doesn't claim to be an expert most would agree his configs are pretty locked down. I want to say it's "clipso" something but I'm not entirely sure.

Does anyone happen to know this source, or another good source which has hardened base configurations.  I'd like to use these as a "wide-net" starting point to hardening some servers.

The first repository that comes to my mind for secure baselines is NIST.

You can review the baselines for various software and operating systems, inluding Apache here: http://web.nvd.nist.gov/view/ncp/repository


Why do OpenSSL and Python return different SSL fingerprints? I use getmail, a tool written in Python, to retrieve my mail via IMAP. Today it suddenly stopped working because it complains about an SSL fingerprint mismatch.  (I always specify the fingerprint to check in getmail's configuration file, and I get this fingerprint from the OpenSSL command-line tool.)

According to the openssl command line below, my mail server's SSL certificate fingerprint is 393c7c58738fa6643cedd9943ffb6e951b2d3b576991d9671d86921ee79bb68a:

openssl s_client -connect onza.mythic-beasts.com:443 < /dev/null 2>/dev/null \
| openssl x509 -fingerprint -sha256 -noout -in /dev/stdin \
| cut -f2 -d= | tr -d : | tr '[:upper:]' '[:lower:]'

However, according to getmail and to the following simple Python fingerprint checker (which I essentially ripped out of the getmail source code), the certificate is actually 63d1c9e28c51aebd0c26463563be30e4df6814fa5406bab1787d1b9bdd19f15e.

#!/usr/bin/env python

import imaplib
import hashlib

conn = imaplib.IMAP4_SSL('onza.mythic-beasts.com')
sslobj = conn.ssl()
peercert = sslobj.getpeercert(True)
actual_hash = hashlib.sha256(peercert).hexdigest().lower()
print(actual_hash)
conn.logout()

I'm seeing the same results on a lot of different computers running different GNU/Linux distributions and connected to different networks.

Why are openssl and Python reporting different fingerprints for the same host?  How do I know which one is correct?  Is Python or OpenSSL perhaps caching an old copy of the certificate?  If so, how do I clear the cache?

According to the openssl command line below, my mail server's SSL certificate fingerprint is 393c7c58738fa6643cedd9943ffb6e951b2d3b576991d9671d86921ee79bb68a:
openssl s_client -connect onza.mythic-beasts.com:443 < /dev/null 2>/dev/null \

You are using port 443 for checking the fingerprint. Port 443 is your web server (https) and not the mail server as you claim. The mail server is instead on port 993 (imaps). If you replace the onza.mythic-beasts.com:443  with onza.mythic-beasts.com:993 you'll get the fingerprint you've expected, i.e. 63d1c9e28c51aebd0c26463563be30e4df6814fa5406bab1787d1b9bdd19f15e.


How to steganograph ownership information into members uploaded images? Considering a social website where members upload images which at times can be very similar - is there a way that images can be 'branded' steganographically with (salted+encrypted) text that identifies the owner's username and the date they uploaded it(for example)?

The idea is not to hide or transmit secret messages but simply to attach the information to the image files in some subtle way so that if the image gets uploaded by another member at some point in the future (whether they sourced it by downloading it from another users profile or had come across it on google images for example) it could be identified as belonging to another member.

What would be a good way to go about implementing this considering it would need to be followed on every image uploaded to the server?

Identify if the image contains any steganographic text previously inserted by the website (if so, decipher it)
If the image is 'empty' then embed the required information

Steganography is about concealing information in a medium (e.g. pictures) in a way that people who look at the medium are unaware of the presence of that information.

What you want is something else called watermarking: how to embed some information which is hard to remove. A good watermark does not alter (too much) the medium in the eyes of onlookers, but resists minor modifications such as colour filters or image cropping. On the other hand, these onlookers may be totally aware of the presence of the watermark (even if they don't actually see it).

Steganography and watermarking are quite distinct things. Usually, good steganography is fragile (minor alterations will remove it) because it hides into what can pass as simple "noise"; in a sense, robust steganography can be said to be bad because robust information is information that is much more likely to show up during statistical analysis. On the other hand, watermarks MUST be robust.

In all generality, watermarking is a lot harder to do than steganography. If "attackers" (here, people that want to grab pictures and remove ownership information) are technically inclined and have access to some system that can tell them whether the mark is present in a given picture, then they will be able to reliably remove watermarks without much altering the pictures. This means that whatever mechanism you use, you will have to keep it quiet and do not let your users ever suspect that it exists. Of course, discussing it over a public Internet-based forum like this one is kinda counterproductive...

(If your users are just normal humans, not bored geeks with too much time on their hands, then simply adding the ownership information in the EXIF metadata could already be sufficient for your needs.)


Fail Decrypt Botan built TLS using Wireshark When i use Wireshark to decrypt an Openssl sample(by importing server private RSA key) https://github.com/matthewarcus/ssl-demo it works perfect.
And i want to do the same thing with Botan CLI tools(another encryption library) using  selfsigned cert and key(RSA_2048bits).
I configed server using following commands
botan tls_server selfsignedCer.cer serverPrivate.pem --port=9999

client
botan tls_client localhost --port=9999

resulting
Alert:unrecognized name
Certificate validation status: Cannot establish trust
Handshake complete ,TLS v1.2 using RSA_WITH_AES_256_CBC_SHA256
Session ID : (long hex there)

Since handshake completed, I go look into wireshark, but there is no 'SSL decrypted data' section as showed below(so it means wireshark cant decrypt that):

Below is my success sample using  Openssl sample , I can see the 'decrypted SSL data' section

Is wireshark only able to decrypt TLS implemented by openssl?(but I think the implementation has no effect on TLS)
Or I did something wrong?
Oringinal capture file and key provided below.
https://drive.google.com/open?id=0B4wOLdBNMGUUQng1ak1qVFdkX0U
the first 30s are the one with botan, then i stop the communication and start another openssl sample on around 40s, all using the same key

The first connection in your capture, frames 1-28, presumably botan, uses the Encrypt-then-MAC extension of RFC 7366; that is, the client offers/requests it and the server agrees. Based on looking at the SSL debug log Wireshark apparently does not implement this, at least through 2.0 (I'm not on 2.2 yet), since it apparently tries to decrypt the whole message including the MAC and then unpad which is completely wrong for EtM. It definitely does not decode the extension in the Hello messages (leaving it as "Unknown 22"), which I would expect if the related functionality were implemented.

The second connection, frames 29-48, is apparently OpenSSL, which does not implement EtM and therefore does not offer it in ClientHello; your (botan) server is apparently happy to negotiate a session without it, albeit using an AEAD ciphersuite (TLS_RSA_WITH_AES_256_GCM_SHA384 0x9C) which solves the weakness EtM was intended to address.

Intriguingly your botan client also offers the ticket extension RFC 5077, but the server didn't actually send a ticket for that handshake, while it did do so for the same offer from OpenSSL. I don't see any obvious reason for the difference -- which to be clear is permitted at the server's choice.

PS: you might see if you can get your client to prefer, or even require, AEAD ciphersuites, instead of offering only AES(256)CBC as it did in this capture. If the handshake selects an AEAD suite then EtM has no effect on the encryption so Wireshark should handle it.


Advantages of one time pad I always hear that one time pad'ing something is so great because you won't know if you've successfully decrypted the data. I understand the idea that you can XOR any bits just the same as any other bits and you won't inherently be "alerted" to the fact that you used the right bits, but is this not true of any other encryption algorithms/concepts?

For instance, if you try to brute force data that was symmetrically encrypted in SSL/TLS (which is NOT a one time pad), I imagine you won't know if your brute force attack actually found relevant results unless you check those results against something you were looking for (metadata, valid PDF, valid Word, etc.)

So, if what I said is true, then what is the advantage of a one time pad? Is it simply the length of the key used (the fact it has to be as long as the data)?

A one time pad offers information theoretic security. This essentially means that the one time pad cannot be broken even if the adversary has unlimited computing power. This is because XOR-ing any data against a truly random key will guarantee that the output be random as well because you are simply flipping bits.


What does scorecardsresearch.com/beacon.js - added by Disqus.com - do? I recently added Disqus to my site. Looking at the "scripts" tab on Firebug, I noticed a script called, http://scorecardresearch.com/beacon.js (here is a prettified version - the script is not accessible directly through the url provided).

What does beacon.js do? What does this report mean?

As far as I understand beacon.js along with cookies does a bunch of tracking of visitors, but I am unclear as to details and implications.

Here is the only hard coded JS on the pages that show the beacon.js script

<script type="text/javascript">
    /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
    var disqus_shortname = 'netlumination'; // required: replace example with your forum shortname

    /* * * DON'T EDIT BELOW THIS LINE * * */ (function () {
        var dsq = document.createElement('script');
        dsq.type = 'text/javascript';
        dsq.async = true;
        dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
    })();
</script>

The above ends up modifying the html on my page to include a script link to "scorecardresearch.com/beaons.js"

This is the get request to scorecardresearch.com when I am completely logged out in Chrome incongnito mode:

http://b.scorecardresearch.com/b2?c1=7&c2=10137436&c3=1&ns__t=1356321346996&ns_c=UTF-8&c8=Disqus%20Comments&c7=http%3A%2F%2Fdisqus.com%2Fembed%2Fcomments%2F%3Ff%3Dnetlumination%26t_u%3Dhttp%253A%252F%252Fnetlumination.com%252Fdo-not-stop-not-thinking-negatively%252F%26t_t%3DDo%2520not%2520stop%2520not%2520thinking%2520negatively%26s_o%3Dpopular%231&c9=http%3A%2F%2Fnetlumination.com%2Fdo-not-stop-not-thinking-negatively%2F

And here is Disqus' embed script, which adds in scorecardresearch.com and google-analytics too:

http://mediacdn.disqus.com/1356132141/build/next/embed.js

Prettifed version of embed.js

My questions:

Am I essentially giving scorecardresearch.com access to my users and user's cookies for my domain, since the script tag is on my page?
What does this mean? I assume they have the same power to parse my user traffic as, say Google Analytics.
Could they use the Disqus cookies stored on my site to log in to a user's Disqus account or access Disqus on another domain somehow?
What practical implication does that xss report have?
What are the disadvantages of allowing third party cookies on your site?

Am I essentially giving scorecardresearch.com access to my users and user's cookies for my domain, since the script tag is on my page?

Yes. Any script included in your page either directly or indirectly (via disqus) has full access to interfere with the user's experience for everything on the hostname it is included on.

Stealing client-side (non-httponly) cookies is only one potential attack - if they wanted to, they could include a JavaScript keylogger to intercept all keypresses on your site, steal passwords, make the user automatically delete their account, and so on.

You will have to decide how much you trust Disqus and their partners, and gauge how sensitive the material on your site is, to come to a conclusion on whether this level of access is an acceptable bargain for the benefit of having a chat system for free. I'm a paranoid sort who can remember back to the days when TMRG (scorecardresearch) had their MarketScore spyware silent-installed in software bundles, so I'm not keen, personally.

If you're worried about this but still want to keep the chat feature, a potential workaround might be to include the chat in an iframe served from another domain that doesn't get scripting access into your main site domain.

  As far as I understand beacon.js along with cookies does a bunch of tracking of visitors

Yep.

  What does this report mean?

It's an automated vulnerability scan of the beacon service; it hasn't been processed manually to rate how much of a problem the detected issues actually are.

From the issues listed here we have the ability to inject unescaped HTML content into files from scorecardresearch.com. That would normally be an XSS vulnerability, albeit mitigated by the files that are being injected into being JavaScript files. So you could inject into scorecardresearch.com if you could make some visit that address using a browser that can be fooled into thinking the file is HTML by the presence of content like <html>. This is 'MIME-sniffing' and it's typically more of a problem for older browsers.

In any case, this probably doesn't affect you. You are including the script from scorecardressearch into your site's security context, not using scorecardresearch's potentially-compromised own context. Including a file as a <script> doesn't give MIME-sniffing any chance to misinterpret the string literal content as HTML, and there's no evidence of any holes in the script that would allow content to break out of the Javascript string literal (unescaped quote mark).


Is digital certificate with 'issued to' field as *.example.com valid? Came across a Digital Certificate which has issued to field *.example.com

Is this a valid certificate?

A certificate issued to *.example.com is a so-called "Wildcard Certificate". It is valid for all subdomains of example.com like www.example.com, mail.example.com, forum.example.com etc..

It would not be valid for the main domain (just example.com) or on any nested subdomains like login.forum.example.com. However, additional domains can be added to a certificate using the "SubjectAltName" field of the certificate. These alternative domain names do not even have to be under the same domain hierarchy.


Would this work to protect a cookie with an OAuth token? I'm currently trying to set up an OAuth 2.0 authentication scheme to protect some stateless REST webservices. These services deal with sensitive information, and the OAuth support is a requirement.

The issue is that the client application is 100% on the client side (Angular/Javascript), and there are no user sessions at all, so I'm struggling with how to deal with a token on the client-side without exposing it to attackers.

The plan is to do something like:

use user/password grant to get a token from the IdentityServer (client application is ours, and no client_secret is left laying around)
store the token in a cookie
when making a request, take the token from the cookie and use it to sign the request
when the token expires, use the refresh_token to get a new one

To send the request, I figured I can either:

Send the HttpOnly cookie as authentication, instead of signing the token
Use Angular’s XSRF-TOKEN cookie, which means the cookie should
only be accessible to Javascript running in our domain (though I
believe this leaves still leaves it open to XSS attacks?)

The cookies will be all set to secure, and send over HTTPS. However, this still seems insecure, since the token is still stored as plaintext.
The refresh_token will also be in the cookie. (I’ve considered local storage as well, but unless I missed something, it did not seem any safer...)

Is there a safer way to store an oauth token on the client-side?

Or is this acceptable security? What am I missing here?

Reference:

Angular XSRF protection:
https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection

You are not worrying about the right things

Protecting information located on the client?

You don't need to do anything once the information has reached your client (ex.: your browser) in order to protect it. You could store the access token in a cookie, in a hidden field on your webpage, in html5 local cache or plainly visible directly in the middle of the page and it doesn't change anything (except shoulder surfing...).

Worrying about the access token once it's on the client is like opening notepad to write your email password and then worry that an attacker might be able to steal that information from a remote location. It doesn't happen. Unless your computer is already compromised but at this point you have already lost.

Where it makes sense to worry?

Usually, your information is vulnerable when it is in transit. In the case of OAuth2 (implicit flow), the access token will be in transit at two places :

from the authorization server to your browser
from your browser to the resource server

Protecting the information while it is in transit is as easy as using TLS everywhere. Which you should already be doing since you are using OAuth2 and it's required by the protocol.

Now the real problem

The way you intend to use OAuth2 is most likely not the way that you should be using it.

To understand why you will probably misuse OAuth2, you have to know about the flows. OAuth2 define 4 authorization flow

Authorization Code (only good one but... keep reading)
Implicit (false sense of security)
Resource Owner Password Credentials (horrible idea)
Client Credentials (not applicable to your case)

Since you using a javascript client, the only flow that works for you is the implicit flow and now starts the issues.

Implicit flow problems

There are many but let's just talk about the most critical one. Access token are not bound to a specific client! From the specification section 10.16 :

  For public clients using implicit flows, this specification does not
  provide any method for the client to determine what client an access
  token was issued to.

This open the doors for attacker to impersonate you, the resource owner, and then gain access to the resource server. Let's keep reading section 10.16 :

  A resource owner may willingly delegate access to a resource by
  granting an access token to an attacker's malicious client. This may
  be due to phishing or some other pretext. An attacker may also steal
  a token via some other mechanism.  An attacker may then attempt to
  impersonate the resource owner by providing the access token to a
  legitimate public client.

  In the implicit flow (response_type=token), the attacker can easily
  switch the token in the response from the authorization server,
  replacing the real access token with the one previously issued to the
  attacker.

  Servers communicating with native applications that rely on being
  passed an access token in the back channel to identify the user of the
  client may be similarly compromised by an attacker creating a
  compromised application that can inject arbitrary stolen access
  tokens.

  Any public client that makes the assumption that only the resource
  owner can present it with a valid access token for the resource is
  vulnerable to this type of attack.

That first attack is actually not even an attack but rather just a "flaw" in the implicit flow...

The next attack

Now starts the big troubles. You seem to be trying to use OAuth2 implicit flow as a form of delegated end-user authentication which it is not meant to provide. Back to the specification section 10.16

  Authenticating resource owners to clients is out of scope for this
  specification.  Any specification that uses the authorization process
  as a form of delegated end-user authentication to the client (e.g.,
  third-party sign-in service) MUST NOT use the implicit flow without
  additional security mechanisms that would enable the client to
  determine if the access token was issued for its use (e.g.,
  audience-restricting the access token).

At this point it's mostly game over for you.

How to mount that attack?

It's pretty simple. Let's say your REST service required an access token from facebook. All an attacker need to do is to host a service, for example stackoverflow, and require an access token from facebook. When you give the facebook access token to stackoverflow, stackoverflow (our attacker) can now impersonate you with your REST service.

All that because access tokens are not bound to a specific client.

A solution

Don't use the implicit flow and instead use the authorization code flow. Which means that your 100% client side app will need to no longer be a 100% client side app.

Why are you not using the server that is serving the angularjs client to your user to handle the OAuth2 flow?

Reference : http://tools.ietf.org/html/rfc6749


Freshness for SGX enclaves Future Intel processors will support SGX (Software Guard Extensions), which allows running security-critical software on your processor in a way that is isolated from all the other code.  The hardware provides secure isolation, so other code can't tamper with the security-critical code running in the SGX enclave.  Even the OS kernel is not trusted and can't tamper with the code in the SGX enclave.  The enclave itself is stateless, but there's a way it can save data on external storage securely: the hardware supports sealed storage, where data is encrypted and MAC'ed before being written to disk.

Are there any guarantees for freshness of sealed data?  In other words, I'm worried about a rollback attack, where a malicious OS tries to roll the state of the enclave back to some earlier point in time: e.g., checkpoint the saved state, run the enclave for a while, then possibly restore back to the checkpoint.  Can SGX code defend against such rollback attacks?  If so, how?

No, not directly.

As you've observed, SGX ensures the freshness and integrity of transient state in memory, but doesn't provide any mechanism (like a monotonic counter) for ensuring freshness of persistent state. So if you just want to rely on SGX on the local CPU, you can't protect against state rollback attacks. The general solution to this problem is communication with another trusted party which can provide you the basic mechanism to ensure freshness. That could be a trusted machine/service on the other side of a network, or it might be some other trusted hardware like a TPM. In either case, because you'll be communicating over an untrusted channel, you need to secure it (i.e., crypto). If your workload is update-heavy, you'll also run into the messy tradeoff between holding up writes while you wait for communication with the trusted party vs. allowing some window for rollback attacks.


Can Javascript overwrite a HTTPOnly cookie? Can Javascript overwrite or delete a HTTPOnly cookie?

In more detail: Suppose the user's browser has a cookie for example.com with the HTTPOnly flag set, say session=552..e0.  Suppose the user visits a page on example.com.  Can Javascript running on that page overwrite the cookie with a new cookie that does not have the HTTPOnly cookie flag set?  Will that effectively delete the existing HTTPOnly cookie?  Can I count on browsers to prevent this?

Research I've done: The Google Browser Security Handbook says:

  no specific thought was given to preventing JavaScript from overwriting httponly cookies

but I know that those pages are quite old right now, and that quote is not entirely explicit about what is possible.  A table on the same page says that on MSIE, Firefox 3, Opera, and Chrome, Javascript cannot overwrite HTTPOnly cookies, but Safari and Android browsers can -- but again, that's a very old resource.  Mozilla's documentation is not clear on this point.

While you might not be able to rewrite the cookie you might be able to shadow it. The specific behavior depends on the browser though. With Firefox I can set a site-global HttpOnly cookie with path=/ and a JavaScript cookie with a different path. If I visit this path then I get both cookies:

# In server response
Set-Cookie: Foo=http; HttpOnly; Path=/

# In document script
document.cookie = "Foo=js; path=/f;"

# Request when visiting path /f
Cookie: Foo=js; Foo=http;

In Chrome though it shows in the request only a single cookie, the one with the HttpOnly flag. It has the other cookie stored locally though and can access it with JavaScript.

For more on this see also Cookies Lack Integrity: Real-World Implications from Usenix 2015. The findings there might be no longer fully true though since the browsers might have changed their behavior in the meantime.


Does escaping/cutting of  prevents you from XSS I have an input, which displays a value (Firstname) in a box on the page.
On the server side, the input is escaped by following rule (vb.net):

Public Function UnescapeString(strValue As String) As String
    If (String.IsNullOrEmpty(strValue)) Then Return strValue
    strValue = Replace$(strValue, """", "")
    strValue = Replace$(strValue, "'", "")
    strValue = Replace$(strValue, "<", "")
    strValue = Replace$(strValue, ">", "")
    Return strValue
End Function

The output isn't validated at all.

I can't believe escaping input from <> could be this safe as it feels for me!?

Are there tricks to inject code or is the most major thing to prevent XSS here, to cut out or escape <> signs?

Question 2:
I am planning a rewrite of this method like this:

   strValue = Replace$(strValue, """", "&quot;")
   strValue = Replace$(strValue, "<", "&lt;")
   strValue = Replace$(strValue, ">", "&gt;")
   strValue = Replace$(strValue, "&", "&amp;")
   strValue = Replace$(strValue, "'", "&#x27;")
   strValue = Replace$(strValue, "/", "&#x2F;")
   strValue = System.Web.HttpUtility.HtmlEncode(strValue) <- or only this

I'm planning not to cut out, but escape values properly, like in the example above.  Or I just use .NET's HtmlEncode (last line), which even encodes special characters like German umlauts, as well as dangerous signs like <>"'/.

The problem is you can use other encoding like base64 which may get processed by you browser to create a successful XSS, use HttpContext.Current.Server.HtmlEncode() instead.

Example:

$ echo '<script>' | base64
PHNjcmlwdD4K
$echo PHNjcmlwdD4K | base64 -D
<script>

Javascript example:

 var decodedData=window.atob('PGlmcmFtZSBzcmM9L3hzcy9iYXNlLmh0bWwgd2lkdGg9MTAwJSBoZWlnaHQ9MTAwJT48L2lmcmFtZT4K');
     document.write(decodedData);

Iframe example:

src=data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4K

Additional point, you may not be maintaining this code for the life of the code, a new exploit could possibly get around your filter, hopefully the maintainers of .NET would issue an update that addresses that and is applied by sys admins.


Detecting(and locating) rogue DHCP server on a local area network How would we detect and locate a rogue DHCP server on our local area network?

You can use an nmap script for locating a server that will send DHCPOFFER (so long as it's in your broadcast domain):

nmap --script broadcast-dhcp-discover

This will give DNS domain name, your IP, who offered it, lease info..all of the fun stuff.

You can also include a list of hosts that have anything to do with port 67:

nmap --script broadcast-dhcp-discover -p67 [your network CIDR]


Is a CSRF required if no direct state change operations are performed? I'm currently developing a webservice that sits in between other webservices. In the process of securing this webservice I've gotten a bit stuck on whether or not we neeed to require a CSRF token on its endpoints. This webservice does not directly interact with any database or persistent information so we are not performing any state changes. However, it does send a request to another webservice that does make changes to a database. This other webservice that makes changes is already protected by a CSRF requirement and my webservice just forwards cookie/header information.

In this situation does my webservice need CSRF protection, or is it unnecessary?

CSRF for Proxies
It sounds like your service is acting more or less as a proxy for other services.  Looking at things from that perspective I would say that the preference is to not perform CSRF protection (which is a stronger statement than suggesting that CSRF protection may not be necessary).
The reason is that if you are not doing anything yourself but transparently forwarding requests for someone else, then attempting to provide a security measure where none is expected/required will cause headaches for the person you are providing this proxy service for.  In other words, you've increased cost/usability without necessarily increasing security, which is a bad trade off.
In short, unilaterally dropping in security checks everywhere isn't often a good idea.  Unless you know for sure which requests require a CSRF check and which requests don't, you're probably better off letting the user's who operate the actual endpoints decide for themselves if CSRF is required.  Of course if you know for sure when CSRF should or should not be required, then it may not hurt to put it in as an additional safeguard, just in case someone on the other end forgets it.
Presuming you opt to skip out on CSRF protection on your end, it may be worth noting this fact in documentation somewhere. After all, it may not occur to the people using the service that they can and should implement the usual security measures when needed by their own system.


How to trust root CA When I download a browser such as Mozilla, it comes bundled with several root Certificates.

How do I trust that these certificates are legitimate? How do I know that my download does not contain some fake root certs?

I know that the software itself will go through an integrity check during the download (which rules out any tampering), however the integrity check itself relies on my existing browser trusting the browser which is being used to download Mozilla over HTTPS. Basically the Mozilla download itself relies on some other root certificate required somewhere during the download process. It seems to be a recursive problem.

So my question is how do I trust the root certificate built into my browser?

Firstly, you are right, it is a recursive problem.  SSL is sort of a house of cards because you always have to trust something, including the folks that are telling you who to trust.  A number of experts have predicted the collapse of SSL:

Security Collapse in the HTTPS Market

SSL/TLS encryption and the vacant lot scam: Too big to fail

How is SSL hopelessly broken? Let us count the ways

SSL and the future of authenticity

That being said, it is all we have for now, so panicking won't help.

If you're concerned that the program that you just downloaded also installed some malicious root certificates, there are scanners available to check them, such as this one and this one (Note: I can't recommend any of these because I haven't tried them, so do your research).

Or, if you wish to scan them manually, a pretty good list
is maintained by Microsoft's Trusted Root Certificates Program.


Why is a .jar signature still valid if a file has been added to the jar? I was reading the man page for the jarsigner tool that ships with the JDK. This line surprised me:

  A verification is still considered successful if none of the files that were in the JAR file when the signature was generated have been changed since then, which is the case if the hashes in the non-header sections of the .SF file equal the hashes of  the corresponding sections in the manifest file.

This doesn't make sense to me. Couldn't an attacker hide malicious code in an already-signed jar file?

Update: Here is an example of this scenario. It looks like jarsigner will flag the jar as containing extra files, but still considers it verified.

=> jar -cf twelfthnight.jar TwelfthNight.html
=> keytool -genkey -alias signFiles -keystore examplestore
=> jarsigner -keystore examplestore twelfthnight.jar signFiles
Enter Passphrase for keystore:
jar signed.

Warning:
The signer certificate will expire within six months.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

=> jarsigner -verify twelfthnight.jar
jar verified.

Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

=> jar uf twelfthnight.jar Hamlet.html

=> jarsigner -verify twelfthnight.jar
jar verified.

Warning:
This jar contains unsigned entries which have not been integrity-checked.
This jar contains entries whose certificate chain is not validated.
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-10-16) or after any future revocation date.

Re-run with the -verbose and -certs options for more details.

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

  Errors and Warnings

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

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

  ...

  Severe Warnings

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

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

  ...

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

  ...

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


Retrieving passcodes through forensic discovery If you encrypt a device using a passcode, the data stored on the device cannot be retrieved using forensic discovery.

What about the passcode itself? Is that encrypted too?

Can forensic analysts simply retrieve the passcode in authentic form and use it to decrypt the rest of the device?

The specifics of the device are very important here.  Generally speaking, however, (when talking about devices that implement reasonably secure encryption mechanisms) when you encrypt a device with a password, that password is not in fact stored anywhere. The standard process is that when the password, when entered, is run through a key derivation function in order to deterministically create key-encryption-key, which is then used to decrypt the the data-encryption-key, which was randomly generated by the device, and what is actually used to encrypt and decrypt the data on the device.  Without the key-encryption-key, you can't decrypt the data-encryption-key, and can't recover the data.