When hashing passwords, is it ok to use the hashed password as the salt? I don't like this idea. But I can not come up with a technical argument against it. Can somebody explain it to me? The basic idea is:

$passwd = 'foo';
$salt = hash($passwd);
$finalHash = hash($passwd . $salt);

The $finalHash is what would be stored in the database. I do understand that two users with the same password "foo" would have identical hashes. But that is only one weakness of this plan. And such collisions, while dangerous, are not the primary reason we use salts with hashes. But so far this the only technical objection I have come up with to argue against this.

My understanding is that salts should be random and should be unique for each use of the hash. And this scheme appears to violate both requirements. But I can't figure out how an attacker could benefit from this seemingly flawed use of salted hashing.

To answer this, one has to understand why salts are needed in the first place. This is explained pretty well in How to securely hash passwords?; here's an excerpt from the accepted answer:

Salts: among the advantages of the attacker over the defender, is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation is precomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.

The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash function. Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).

So the problem of your salt is that it doesn't interfere with parallelizing breaking the hashes, which is the very purpose of salting. I strongly recommend you to read the original answer, it has further advice on salting.


How to recover a lost zip file password (Extract Zip Spec '2.0') I want to recover my backup file, but I can't find the password. The password contains 12-20 characters (As!@$123)

user@PC:/media/user/MyData$ zipdetails -v backup2.zip

0000000 0000004 50 4B 03 04 LOCAL HEADER #1       04034B50
0000004 0000001 14          Extract Zip Spec      14 '2.0'
0000005 0000001 03          Extract OS            03 'Unix'
0000006 0000002 00 00       General Purpose Flag  0000
0000008 0000002 00 00       Compression Method    0000 'Stored'
000000A 0000004 44 81 99 48 Last Mod Time         48998144 'Mon Apr 25 16:10:08 2016'
000000E 0000004 00 00 00 00 CRC                   00000000
0000012 0000004 00 00 00 00 Compressed Length     00000000
0000016 0000004 00 00 00 00 Uncompressed Length   00000000
000001A 0000002 06 00       Filename Length       0006
000001C 0000002 0B 00       Extra Length          000B
000001E 0000006 6F 74 68 65 Filename              'other/'
                72 2F
0000024 0000002 00 00       Extra ID #0001        0000 ''
0000026 0000002 00 00         Length              0000
0000028 0000000               Extra Payload
0000028 0000002 00 00       Extra ID #0002        0000 ''
000002A 0000002 00 00         Length              0000
000002C 0000000               Extra Payload

Unexpecded END at offset 0000002C, value 50000000
Done

Elcomsoft is now working, I need to bruteforce the zip password but only under Linux.

If the Symbols As!@$123 are the parts you password was orignally made of I'd recommend creating a customzied bruteforce using these Symbols in order to get the password.

For this you could use John The Ripper or Rarcrack.

Otherwise; as KanekiDev said: good luck brute-forcing the 12-20 long password.


Does aircrack-ng use GPU/CUDA capabilities? As stated, does aircrack-ng when brute forcing a WPA2 handshake capture use GPU/CUDA resources such as a program like Hashcat does?

As stated by @RoyceWilliams, it does not seem to use CUDA. For this purpose, you might want to look at Pyrit, since it leverages CPUs and GPUs on the cracking process.

NB: I wanted to leave this as a comment but I still don't have enough reputation.


Tracking down the source of email attacks For the past week our company's IDS has been blocking 100-200 meeting invite emails per day from a specific client that are loaded with buffer overflows targeted at Exchange 2003. The payloads are harmless to us, but the flood of logs is annoying to say the least. I have been in contact with the IT manager at the client company and have been assured there's no record of these emails originating from their mail server, yet the attacks are only picking up speed and coming from more addresses on their domain every day. It looks pretty clear to us that there's an infection spreading through their domain, but they maintain that their system is clean. We're reasonably certain it's not coming from any of our machines because the emails are getting blocked before they even enter our network. If the attacks truly are not originating from them, how can we track down their source? Or what kinds of evidence can we gather to prove it really is from the client?

The email headers should suffice (see "email header ip address for an example of how to read them."). Perhaps post them here as well.

I want to emphasize that while only the most recent header line is absolutely reliable, header information is really the only information about email origin that you can obtain.

You could email a copy of the headers to the "sender", and they should then have enough information to confirm or deny - but it is up to them to have the desire, expertise and diligence to do something about it. As the old saying goes, "You can lead a horse to water, but you can't make him participate in synchronized swimming."

If you suspect the headers are not reliable, then the only recourse is to slowly work backwards through each intermediate MTA, each time confirming that the header line matches their logs. This would allow you to prove who the sending MTA was with absolute certainty, but:

It's a HUGE amount of work. Several hours at least.
You'd have to be quick, as many large mail systems can't store log data for long due to the volume of storage required
You'd have to be lucky, and hope that every intermediate MTA co-operates with you

Even if you succeed, the sender can still choose to ignore you (it's their mail server after all), in which case your only remaining recourse is to report the spam to blacklist providers.


What encryption did Encrochat use, and how was it broken? On 2nd July, the UK's national news outlets broke the story of an "unprecedented" 4-year-long, Europe-wide investigation that, in the UK, resulted in the arrest of 746 criminals, including many high-profile "kingpins" of the criminal underworld as well as corrupt police officers. According to The Mirror:

NCA Director of Investigations Nikki Holland, said: “This is the broadest and deepest ever UK operation into serious organised crime. Together we’ve protected the public by arresting middle-tier
criminals and the kingpins, the so-called iconic untouchables who have
evaded law enforcement for years, and now we have the evidence to
prosecute them.”

If these phones were employing a form of encryption, then it stands to reason that the French police and the UK's National Crime Agency must have been able to break it in some way. Is there any further information on what encryption EncroChat phones were using, and how exactly it was broken?

As the linked article states, is appears the server farm was compromised rather than encryption being broken:

They eventually discovered that EncroChat was operating from servers
based in France and were eventually able "to put a technical device in
place" which allowed them to access the encrypted messages sent over
the company's network.
Although it isn't clear what this device was, it suggests the
investigators were able to deploy some form of technical implant on
the network rather than break the encryption protecting the messages
in transit.

Smart money says that the chat was not end-to-end encrypted, and that the police implant tapped into servers where the data was unencrypted, or perhaps even found unencrypted server-to-server backend traffic on the wire.


Why are IMSI and IMEI still used? While I understand their function, both IMSI and IMEI makes tracking and surveillance possible by virtue of being persistent idenfitiers for SIM and handset, respectively.
Why aren't these replaced with a more secure scheme, maybe something along the lines of randomizing publicly visible device identifier every now and then (sort of like Bluetooth/WiFi MAC randomization) and sending some session-details (instead of a person/SIM-identifier) over an encrypted connection?
Is it mostly (only?) backward compatibility?

The purpose of MAC address randomization in Wi-Fi and Bluetooth is so that probe devices cannot consistently identify user devices in their immediate vicinity. These devices do not wish to actively communicate with the devices they probe, but only to record their presence and correlate with previous sightings.
However, once a device wishes to register with a network and communicate over any higher-layer protocol (such as IP), it must present a consistent MAC address to the network so it can be associated with the higher-layer address it is assigned. Some MAC address randomization implementations revert to the hardware-encoded MAC address for this purpose, while others record a consistent MAC address per network (SSID) so that only one network knows the real MAC address the device has synthesized for its use. Regardless, a non-randomized MAC address is required for the device to participate in higher-layer communication.
With mobile telephony devices, the only way for the device to receive calls or data once it comes into range of a cell tower is to register with that cell tower, so the routing infrastructure knows where it is and can refer to the device by any higher-layer address such as a phone number or IP address. Thus it is pointless to try to randomize the IMEI or IMSI, because as with MAC addresses a consistent identifier is required to register.
The only solution to not being tracked is not to use mobile telephony; it is inherent in the provision of the service that the location of the device be known (to within a cell tower's range) at all times. About the best you can do is to separate your billing information from the phone itself by tactics such as burner phones prepaid in cash. Governments are clamping down on the ability to do this.


Is there a tool in Kali Linux that get Wi-Fi passwords only by capturing the traffic? Tools in Kali Linux generally crack Wi-Fi password by injecting packets. Is there a tool that can crack or get the password only by capturing the traffic?

I would say that most of the wifi cracking tools can do their job with or without injection, depending on the commands and parameters you provide.

For example if you are cracking WPA/WPA2, you can "crack" it without injection by waiting for a client to authenticate and by capturing the 4-way handshake, which you then brute force. In that case, you are not using packet injection.

But if you don't want to wait for a client to authenticate, you could deauthenticate one that is already on the network and force it to reauthenticate, but in order to do this, the tool you are using must use packet injection.

The same counts for WEP. If there is enough traffic on the network, you can just wait and collect network traffic. When you collect enough traffic, it will be used by the cracking algorithm to get the password. In that case you do not need injection. But if there is not much traffic, you can speed up the process by injecting some bogus packets into the network.


ECC Brainpool Standard Curves and Curve Generation with Bouncy Castle which seed to use? I want to implement a ECC Key Agreement with a Brainpool curve brainpoolP512r1 or brainpoolP512t1.

I'm not clear about whichseed value to use (and how).
In this document http://www.ecc-brainpool.org/download/Domain-parameters.pdf are two seed values are mentioned.

And RFC http://www.ietf.org/rfc/rfc5639.txt

5.1 Generation of prime numbers

  6636920D871574E69A458FEA3F4933D7E0D95748 for ECC 512

5.2 Generation of pseudo-random curves

  02AC60ACC93ED874422A52ECB238FEEE5AB6AD for ECC 512

So which seed should I use in the ECDomainParameters constructor?
Is the seed value for the twisted curve the same? I find only seed values for brainpoolP512r1 and not for brainpoolP512t1
Is the implementation rigth?

    // ECC 512 = AES 256 = RSA 15360
    var ecP = TeleTrusTNamedCurves.GetByName("brainpoolp512t1");

    // because ecP.GetSeed() is null !?
    // see spec "ECC Brainpool Standard Curves and Curve Generation" site 7

    // 5.1 Generation of prime numbers
    var seed_p_512PrimeNumbers = StringToByteArray("6636920D871574E69A458FEA3F4933D7E0D95748");
    // 5.2 Generation of pseudo-random curves
    var seed_p_512PseudoRandomCurves = StringToByteArray("02AC60ACC93ED874422A52ECB238FEEE5AB6AD");

    var ecSpec = new ECDomainParameters(ecP.Curve, ecP.G, ecP.N, ecP.H, seed_p_512PseudoRandomCurves);

    // Alice

    var enc = new UTF8Encoding();
    var secretPlain = "This is a secret.";
    var secretPlainBytes = enc.GetBytes(secretPlain);

    IAsymmetricCipherKeyPairGenerator aliceGenerator = GeneratorUtilities.GetKeyPairGenerator("ECDH");
    aliceGenerator.Init(new ECKeyGenerationParameters(ecSpec, new SecureRandom()));
    AsymmetricCipherKeyPair aliceKeyPair = aliceGenerator.GenerateKeyPair();
    IBasicAgreement aliceBasicAgreement = AgreementUtilities.GetBasicAgreement("ECDH");
    aliceBasicAgreement.Init(aliceKeyPair.Private);

    // Bob

    IAsymmetricCipherKeyPairGenerator bobGenerator = GeneratorUtilities.GetKeyPairGenerator("ECDH");
    bobGenerator.Init(new ECKeyGenerationParameters(ecSpec, new SecureRandom()));
    AsymmetricCipherKeyPair bobKeyPair = bobGenerator.GenerateKeyPair();
    IBasicAgreement bobBasicAgreement = AgreementUtilities.GetBasicAgreement("ECDH");
    bobBasicAgreement.Init(bobKeyPair.Private);

    // generate shared key

    var k1 = bobBasicAgreement.CalculateAgreement(aliceKeyPair.Public).ToByteArray();
    var k2 = aliceBasicAgreement.CalculateAgreement(bobKeyPair.Public).ToByteArray();

    for (int i = 0; i < k1.Length; i++)
    {
        if (k1[i] != k2[i])
        {
            throw new Exception("Secrets are not equal.");
        }
    }

Thanks a lot!

Daniel

You don't have to specify a seed at all.

An elliptic curve is specified by a handful of parameters:

the definition of the field you are playing on (here, the field consists in the integers modulo a given prime p);
the curve equation, here Y2 = X3 + aX + b for two constants a and b;
a conventional generator G, which is a curve point (i.e. a pair of coordinates (X,Y) which matches the curve equation);
the order n of the generator, and its cofactor h.

The order n is the smallest non-zero integer such that nG = 0; h is such that the total number of points in the curve is equal to nh. Normally, we choose the curve such that n is prime and h = 1, i.e. the generator generates the whole curve, and with a prime order suitable for Diffie-Hellman or DSA.

The seed is not needed at all to compute things with the curve. The seed was used to generate the curve itself. It is about "nothing-up-my-sleeve numbers". It is mathematically possible (or at least it may be) to generate special parameters with a hidden structure (p, a and b in the notations above) such that the curve looks good, but is in fact weak against cryptanalysis. Normal, honest curve generation looks like this: we generate completely random p, a and b, and then check the requirements in section 2 of RFC 5639; if they are not all met, try again. Special-form parameters which induce weaknesses are extremely rare, so random generation is fine.

To demonstrate that this normal process was followed, and, therefore, that the curve parameters were not crafted to be especially weak, it is customary to fully specify the PRNG used to produce all the random values, complete with its starting seed(s). Thus, third parties (e.g., you) can rerun the PRNG and the curve generation process, and see that they obtain, indeed, the same curve parameters. For the Brainpool curves, this PRNG is specified in appendix A. Here, they have two seeds because they first generate p, and only then a and b, as two distinct steps, each with its own seed.

However, there is no need to do it every time. When you do such a re-generation of the curve, you do it once, just to make sure that the parameters that you are found in the RFC are legit. In fact you don't need to do it yourself, you just need to convince yourself that someone, somewhere, has done it. In any case, the curve parameters that you are about to use are already in Bouncy Castle.

To just use the curve, the seed is not needed and can be set to null. There is a room in the ECDomainParameters class to specify a seed because some (but not all) standards for encoding the curve parameters have some provision to support including such a seed. However, this does not really apply to your case:

Your code will talk to your code; both parties thus already know what curve is used, and have no need to encode the curve parameters anywhere at all.
Even if you encode the parameters, you won't need to rerun the curve generation process, because each party will use its own, hardcoded, parameters, not the ones sent by the peer.
In any case, there is no standard for the parameter generation PRNG. Brainpool has its own, but there is no agreed-upon PRNG which would fit everybody (contrary to DSA parameters, where the standard itself includes it, see appendix A). Indeed, this can be seen in the fact that the Brainpool process uses two seeds, not one.

So, right now, the inclusion of the seed in encoded parameters, and in the ECDomainParameters class, is pure dead weight. Just set it to null and move on.

Not being myself a practitioner of the Bouncy Castle C# API, I cannot really comment on your use of it, but from a cursory look, things seem fine. Your secretPlainBytes variable seems spurious; I suppose it is the message which you will then encrypt with the agreed-upon key (resulting from the DH key exchange), using code which you don't show.


Identifying unique visitor using only info that can be gathered through the browser? There is a site that allows a voter to vote for their favorite nominee once a day for a certain amount of days. While entering a vote, the only info given is the ballot choice you choose and nothing else.
If you are to go back and vote again, there is a message saying "please wait until next day to vote again". However if you just simply use a different internet browser you can enter another ballot.
I'm wondering what they are using to identify the voter through the browser and if they can tell when a single voter is entering multiple votes through different browsers. Also is there an even more simple/easier way that a voter could be doing this without having to use multiple browsers?

Yes after clearing the browser data (history, site data,  cookies,  cache...etc.) it is possible to enter another vote.


Wordpress Brute Force Attacker knows real admin Username - I've noticed a brute force attempt on several different Wordpress installs that know the right admin user name for those respective sites...

It seems very strange that the hacker would be able to find the username but not the password...
Furthermore, I've checked these Wordpress builds, and I do not see where they are leaking that information anywhere - albeit that is likely the answer...

While I am not worried about the attacker getting through thanks to a whitelist I've already implemented - I am concerned that whatever vector this hacker is using could be used to obtain more sensitive information.

Thank you for any suggestions - !

I noticed this as well and wrote a blog post about it a while ago: wordpress username leak. To summarize:

The leak is probably here: example.com/author/user_nicename. This page can for example be reached via example.com/?author=1.

WordPress has three username related fields in the database: username, nickname, and user_nicename.

username is the name with which you log in, nickname is the name which should be displayed, and user_nicename is the slug version of username, which is used in the author link.

To fix this, you can set user_nicename to nickname in the database.


Segmenting Virtual Network Traffic I have a basic to moderate understanding of VLAN's and their pros and cons as they relate to network segmentation but I'm wondering where to start as one moves into virtualized environments.

From a security perspective, how does traditional VLAN segmentation stand up to products/solutions focused on virtual environments, such as VMWare's vCloud Networking and Security product? When you're working with collocated VM's what strategies/technologies do you rely on to segment VM traffic?

I know this may be overly broad, but any starting points would be extremely helpful.  For the sake a specific question though, perhaps a good way to put it would be - Do you consider virtual network security products to be at least as good as tradition VLAN's for the purpose of segmenting network traffic?

VLANS as a concept remains stable and constant with the implementation of a technology or a solution. The core concept is to define logical set of boundary between networks; a line of trust as to say. Its the implementation that varies and this is where the risk lies.

If you know about ubuntu running under a vmware platform you can define vlans using command such as vconfig. Depending upon the use; your virtual machine is dual homed have (2) NIC cards sitting in DMZ's it may need two vlans to connect to and transfer data.

Just like in physical switch ; you want to filter or define the vlan id that a trunk link can carry; e.g you don't want the ftp server vlan to carry just traffic for ftp servers not anything else.

For inter-vlan routing you need to define intelligent policy at layer 3 router to filter / drop packets based upon security requirement. For e.g non-ftp users accessing ftp farm. Incoming traffic to non-standard ftp ports be dropped as well.

No matter how much virtualized environment you may have ultimately it has to go through physical switches / routers of your organization environment. This is where true control / checks should apply.

Securing vlan is fairly common and well reversed in case of cisco academia (e.g ccna classes). You can start from here.. This link discusses attacks to vlan protocol e.g vlan hopping and what can be done to mitigate the risk.


With BREACH attack, is session-based CSRF token still secure? This is something I haven't been able wrap my head around, if BREACH allow leaking of information, do we have to mask or generate CSRF token in a time-based or per-request fashion to make it more secure?

As far as I know, session-based CSRF token can protect user from CSRF just fine. But how accurate is this in context regarding SSL? The problem here is no longer whether attacker can perform CSRF, but whether such CSRF token can be extracted from HTTPS with compression on, even be used to leak other information?

Basically I am asking if this older question now have an different answer.

If your site is vulnerable to BREACH, an attacker can guess anything in the body of the response one character at a time. The attacker does multiple requests, one per guess, and can see if he guessed correctly. For example, the attacker may try these guesses:

csrftoken=a
csrftoken=b
csrftoken=c
etc.

After a while he figures out the first character of the token, and moves on to the next character. As you can see there are hundreds of requests needed to guess the whole CSRF token.

This attack only works if the same CSRF token is returned in all requests. If the token differs between requests, the attacker can not use multiple requests to guess it. So to protect against the BREACH attack, the CSRF token should be different on each page.

However, it is not necessary to create a new token for each request. Simply obfuscating the CSRF token is sufficient. You could encrypt or even XOR the CSRF token with some salt you include in the form, as Django and Rails do. This means that the token is different on each page, but you still have to check only one value in the backend.


For servers that are not internet facing, do they need to be authenticated to each other and should their communication be over HTTPS? My gut instinct is that best practice would be to ensure that all internal servers communicate over HTTPS and that all servers are authenticated to each other.

That would indeed be dream case scenario.

However, I'm trying to consider if it is ever acceptable for an internal server to communicate, via HTTP, to another internal server without needing to authenticate to that server.

The risk is surely that someone malicious in the network could reek havoc by not only being able to read all traffic between those servers but by replacing the receiving server with one that is under their control.

Any comment on this would be greatly appreciated.

It is easy enough to encrypt traffic and setup/maintain valid internal certificates that I  the pros are well worth the effort.  Encrypt your internal traffic.


What happens if two parties have a same pair of public&private keys we know that we have to create Private key on server and generate its public key and create a certificate.
But what if we get a private key which someone already has. Isn't the security becomes weak in this case.

Simple explanation

The only way this will ever happen is if you give someone your private key. It will never happen by random chance. Never. You'd have a better chance of winning the lottery twice, getting struck by lightning and being mauled by two gorillas all in the same day. Instead of worrying about generating a private key that someone already has, you'd be better off worrying about how to protect yourself from lightning and gorillas so you can spend the money you'll win in the lottery.

So as long as you keep your private key private, you will never have to worry about this.

Scientific Reasoning

Let's say you are dealing with 1024-bit RSA for your public key system. A good key generator will choose the two 512-bit primes independently, so the probability that any two instantiations of the key generator will choose the two primes necessary for RSA is 2-512 · 2-512 = 2-1024 or about 1/10308. That number is so astronomically small that there is no way it will happen in a properly functioning system. Your odds of being struck by lightning in a given year (forget on a given day) 1/1,000,000 (1/106). Probability of getting mauled by two gorillas 2-120 (see post in Rory's comment). The lottery one is a little harder as it depends on what lottery (as the odds are different for every one), but hopefully you get the point.

Improper System

All bets are off. As pointed out in Jeff's comment, this happened in Debian's version of OpenSSL due to a simple bug which caused the random number generator to be seeded with very little randomness. The result was that people could potentially have the same private keys.

Having the same private key as someone else would allow those two people to decrypt each other's messages, etc.


Real time application of AES and DES I am writing a paper on reducing the power consumption of security protocols. I am having trouble identifying sources that describe real-time usage of DES and AES, and how often they are used.  I plan to use such sources for the 'motivation' part of my paper - explaining why power consumption is important. I know AES and DES are used for encryption widely, but I need to site it which I can't because I couldn't find any sources.

I tried to google for details but couldn't get any good results. I need sources which I can cite.

Please help if anyone knows about it or point me in a direction where I might get the result.

Thanks in advance

In computing, Real-Time means the study of systems that must operate within strict time constraints. This is a very large class of systems, and it tends to include most applications with a user interface. For instance, if you go to Youtube and view a video, then this is a real-time application: the downloading, decompression and display of the pictures must happen at a strict schedule so that the movements are smooth and kept in synch with the audio.

From your expressed concern about power consumption, I surmise that you do not really mean "real-time"; rather, you want to know about embedded systems, another very large class of systems. Power consumption is most relevant for systems that must operate over a battery, so in particular portable devices.

The list of devices that use encryption is open-ended, so you cannot gather them all. However, one can remark that any system that engages in SSL/TLS will use one of the encryption systems that are supported in that protocol; this will most of the time be AES, 3DES or RC4. Among systems that do not use one of these three algorithms, the most notable are GSM phones; older protocol versions (2G) used A5/1, a custom stream cipher; newer versions (3G/UMTS) rely on KASUMI. An important point for the discussion at hand is that while A5/1 was designed for very low power consumption and easy hardware implementation, KASUMI is much more "software-like" in design, which means that for phones that support 3G, the encryption system has become quite negligible in the overall power consumption. Indeed, any smartphone will routinely engage in Web traffic, and this includes HTTPS, hence SSL, hence AES/3DES/RC4.

In any case, power consumption depends a lot on the implementation technology, so there cannot be any absolute answer; moreover, any comparison becomes obsolete after a few years, as technology evolves.

This article describes a comparison of various "lightweight" block ciphers, focusing on energy consumption in dedicated hardware platforms (i.e. custom ASIC). This should give you pointers, and accepted terminology for further Google-based searches.


Password security in a Snapchat photo This is going to be an extremely stupid question, so forgive my ignorance.

Let's say I took a Snapchat photo of one of my passwords written in plaintext (let's ignore for a moment the security vulnerability that comes with even having a password in plaintext). I use the colored pen feature in Snapchat to "cross out" my password so it is no longer visible.

I then send this Snapchat to my friend Eve and she does two things:

Takes a screenshot of the picture I sent her
Hacks into Snapchat's database and gets the actual image file that I sent her

Is she able to "erase" the colored pen to reveal my plaintext password? If so, is she able to do with either of the bulleted pictures, or just the second one?

No, she cannot remove the colored pen if she just takes a screenshot.

How Snapchat stores photos is a question for Snapchat themselves. Although they will most likely deny that they save them (they do), it all depends if they store the photos in layers or an all together, un-editable screenshot.


What evidence is there that SpiderOak is significantly different from Lavabit? In 2013 Lavabit shut down because a US agency was demanding access to its private SSL keys and basically the deets on whatever users the US was interested in. Lavabit shut down rather than give the US that access.

Yet, this means that Lavabit had the ability to give the government access to the data it stored for its users.

In light of this, a service called SpiderOak claims to have a Zero-Knowledge encryption mechanism that means it is unable to access user data even if it wants to. While some companies say they won't access your data, SpiderOak claims that it can't.

My question essentially boils down to the truth of this claim. What evidence is there that SpiderOak, even when pressured by a random agency or otherwise compromised, actually can't divulge the data it stores?

Also, I understand that zero-knowledge is a mathematical possibility (although I don't claim to understand exactly how that works). I am more interested in how an outside user can trust the company. Who has audited it? What credibility do they have? The software appears proprietary, so how do I know they didn't make some major mistakes?

You can prove this to yourself by watching the traffic that leaves your computer to go to SpiderOak.  That data should be encrypted by a key that only you control.  Even if they made a mistake, your data is encrypted before it leaves with a widely tested algorithm.  You can verify that your data is encrypted by that algorithm.

In addition, SpiderOak hired an outside firm to audit their recent release: crypton.io
https://blog.spideroak.com/tag/audit

Finally, the EFF seems to agree with the ZeroKnowledge claim:
https://blog.spideroak.com/20131122173304-spideroak-encrypts-best-as-per-effs-crypto-survey-report

Zero Knowledge in this usage isn't really a mathematical anything.  It just means that they only store an encrypted mass of data and don't know your key.


Monitoring access logs of Web application Is there any open source framework or libraries which can provide security monitoring capabilities for Web application by analyzing Web application access logs. Basically i need to monitor and analyze Apache/IIS logs and want to compute general statistic like Request analysis, bot hits etc

Use OSSEC (http://www.ossec.net/) for log analysis & real-time alerting,
use logwatch (http://sourceforge.net/projects/logwatch/) for log analysis & report creation OR combine those two approaches: http://www.chrisbrenton.org/2010/02/combining-logwatch-and-ossec/


Is there any benefit using a two-step salted hash? Commonly when implementing authentication mechanisms that accept passwords is to add salt when hashing the password.

Reading the article here: https://engineering.gosquared.com/evolution-of-password-security (section 4)

is there any actual benefit for doing this? There's a link to an article, listing benefits for decoupling hashes from the users, making brute force attacks even harder since the hash related to the user isn't the actual password hash.

I'm interested in knowing whether this actually helps, or if it's a case of 'security by obscurity'.

note: not asking whether salt is beneficial to hashing passwords. The question is whether decoupling the salt/hash data is beneficial to security.

This does not have any serious benefits as far as I can tell.
To summarize the content you linked, the idea is that you don't have a row with the username and hashed password:
users = [
  {"username": "admin", "salt": "PyoBT3KBnn31qDP9", "password_hash": "e53992bb5f7af6f51773ad8ea3033d66"},
  {"username": "someuser", "salt": "2IY3VczmbhHyEMQJ", "password_hash": "a7d38c0493cf0ff4af602b92c4f77a81" }
]

Instead, you remove the password_hash from the users table, and store them separately in a hashes table:
hashes = [ "e53992bb5f7af6f51773ad8ea3033d66, "a7d38c0493cf0ff4af602b92c4f77a81" ]

(Note that the article from gosquared also has a second hash and second salt, but that is pointless as well---I'll get to that later.)
If you store the username and hash together, an attacker can do a guess, for example that the password is "Pizza7!", compute the hash with the salt, and check if it's correct. When separated, an attacker has to check the result against every entry in the hashes table.
If you have 100 users, an attacker has to match the result against 100 hashes. But only one in 256 hashes has a matching first byte, so most of the time that already won't match. Almost all the time, you're just checking the first 1-2 bytes of the result against the first 1-2 bytes of every user's hash (with some shuffling for cache locality, that can be said to be instant). That is why the author advises to inject bogus hashes, so the table becomes huge. Or maybe you just have a billion users, and your table is huge as well.
If you have a huge table, looping through every hash is not efficient. An attacker would take the first, say, five bytes of every hash in the table, sort it, and keep that in memory. That's five gigabytes for a billion hashes, which easily fits in the RAM of an ordinary computer. Then you apply binary search (also known as bisection search) to find a match in about O(log n) complexity. So for a billion rows, that would be something like 9 lookups.
So you bloated your database to be a billion rows, and all the attacker needs to do extra is a handful of lookups.
But the 5GB database is way too large for a GPU. You can't reduce it to, say, three bytes, because (almost) all possible three-byte values will occur, and regardless, three gigabytes still doesn't fit in these tiny cores. So you made it impossible to do the comparison part on a GPU. However, the hash iterations from something like PBKDF2 or Bcrypt can still be done on the GPU. Only the result needs to be compared against the database in the computer's main memory. Unless you use Scrypt or Argon2, the attacker loses virtually no speed at all. You might as well increase the cost parameter of Bcrypt or the iterations parameter of PBKDF2 (they do the same thing).
Why are Scrypt or Argon2 special? Because they're "memory hard": they already have a memory parameter that allows you to require it to use a lot of memory. Sound familiar? Indeed, that's pretty much the same as using a huge table, except that this prevents the attacker from using a GPU at all.
If you don't use any iterations, for example if you use sha256(password+salt), then this scheme might help you because you add lookups which are a tiny bit slower. If you do something sane (any slow hash), I don't see an advantage in doing this.

The scheme I explained above does not match the gosquared article. They used the scheme as described in the follow-up post from opine.me. There they add a second salt. If you use a secure hashing algorithm, a random salt will always result in a unique hash, so there will not be any collisions in the hashes table, so that is not why. Instead, the reason they give is this:

If an attacker is able to both steal a user’s salt value, and insert a specific hash of their choosing into the Hashes table, they can grant themselves access to a specific user’s account

So the scenario is that an attacker can add values to the hashes table, but not the users table. Let me repeat that: they are trying to block an attacker who is able to write values to one user-related table (hashes), but not to some other user-related table (users). Privilege separation strict enough to create a scenario in which an attacker can write to some tables but not to your users table is very rare to begin with, but I'm all for layered defenses. However, your account creation script will need to write to both tables. And any login checking script need to write to neither. Being able to write to one but not the other is an inconceivably unlikely scenario, there will never be a database user with such a set of permissions.
Furthermore, the author that cooked this up argues the following:

First, I didn’t do a good job in the previous post stating my design goals. scrypt already does a perfectly fine job of letting you tune the CPU and RAM cost of completing a single hash. There’s absolutely no need for any other method than scrypt if all you want to do is tune the CPU and RAM burden on your attacker. What I want to do is two-fold:

Impose additional costs (other than RAM and CPU) on an attacker
Make it easier to detect if attackers start stealing your hashes

[...]
So this approach focuses on increasing the disk storage and bandwidth requirement of copying hashes from a target site.

Even petabytes of data would not do much to the lookup speed. It would no longer fit in RAM, but on-disk lookups can use binary search just as well. You can log in fast enough, so an attacker can do the lookups fast enough as well. You are likely to reduce your security by making your hashing algorithm faster, so that your slow lookups don't make the user wait too long.
Buying loads of hard drives to achieve all this is possible (remember that you also need to make backups of all of this), and I guess if you indeed have a few dozen terabytes of password hashes, it might actually prevent an attacker from getting all of it. Anything less is not going to be useful: network speeds are fast enough, and bandwidth and storage is cheap enough. A few terabytes won't faze any attacker. There are already password dumps of 500GB floating around the internet as torrents.
So then a, say, 40TB hashes table would actually work? The author thinks that you'll detect breaches. In practice, breaches very often go undetected for months. Some companies may notice it fast, but an equal number will be compromised for multiple years before they notice. 40TB takes (40*8*1024/3600/24=) 4 days to transfer over an ordinary gigabit connection. Another issue is storing the data, which would indeed be non-trivial at that size. They would probably have to ask friends and then probably still pool some money for a few extra hard drives. Nothing insurmountable, though. And with 40TB stored on slow, spinning drives, you're almost certainly degrading the slowness of your hashes to accommodate this scheme. And even if you succeed in thwarting the attackers, and they manage to get only 1TB (that fits on any modern laptop), then they still have the hashes from 1 in 40 users, plenty to be a big deal.
It's a huge amount of bulk for a very small amount of gain, assuming you don't degrade the quality (slowness) of the hashes.


"Reverse" approach to one-time key generation Suppose we have a master key, and we want to encrypt some file(s). We then generate one-time key for that file, use it to encrypt file contents, and finally encrypt one-time key using master key (with IV, padding and so on). Fairly common scheme, isn't it?

So, we now want to generate one-time key and store it somewhere in the encrypted file. Straightforward approach is to generate one-time key and IV and use some cipher (in my case it's AES in CBC mode) to encrypt one-time key with master key. After that we store IV and encrypted one-time key in some file. This is pretty standard way too.

So in short, we go from unencrypted random value to encrypted one.

But we can also move in reverse direction. We can fill some buffer with random bytes, then pretend that this buffer is serialized one-time key, decrypt one-time key back from that buffer, and use it to encrypt our file. In that case, instead of having two separate procedures for encryption and decryption of one-time keys, we can keep only decryption procedure.

The question: is it okay to use that trick? Any caveats or pitfalls? Any additional constraints applied to RNG used?

Basically, I just want to make sure that such a simplification won't break security.

As long as your RNG is a cryptographically secure RNG (CSRNG), and your encryption scheme of the one-time key does not involve any padding, it is in fact completely equivalent to randomly sample the plaintext of the one-time key or to randomly sample the ciphertext of the one-time key.  This follows from the fact that any unpadded encryption scheme is a permutation, and therefore if the plaintext has a uniform random distribution then so must the ciphertext, and vice versa.


1024-bit DHE vs 2048-bit RSA Currently with apache/mod_ssl, if DHE is enabled then a 1024-bit ephemeral key will be used. I found the following quote in Adam Langley's blog:

  Ideally the DH group would match or exceed the RSA key size but 1024-bit DHE is arguably better than straight 2048-bit RSA so you can get away with that if you want to.

So it appears that he is advocating something like DHE-RSA-AES256-SHA with 1024-bit ephemeral DH keys over AES256-SHA with a 2048-bit RSA key. My understanding is that 1024-bit DH (ephemeral or not) is of comparable security to 1024-bit RSA. Why would he make such a recommendation? Does he value the forward secrecy offered by DHE that much?

There are two sides to the question:

Perfect Forward Secrecy: by using a "DHE" cipher suite, you actually encrypt the data with regards to a DH private key which never gets stored on any disk. For any given SSL session, the encryption may be cracked if the attacker succeeds at cryptanalysing the public key used for encryption (DH for a DHE cipher suite, RSA for a RSA cipher suite), or if the attacker steals a copy of the private key. The latter occurrence is actually much more probable in practice for a RSA-based cipher suite; and the point of PFS is to remove that threat.
RSA vs Diffie-Hellman: for the time being, the best known methods for breaking RSA and DH entail solving two hard problems, integer factorization and discrete logarithm respectively. It so happens that for both problem, the fastest known algorithm is the General Number Field Sieve (though initially a factorization algorithm, a variant of GNFS can be applied to discrete logarithm). For asymptotic complexity, RSA and DH are thus of equivalent hardness when the DH modulus has the same size as the RSA modulus.

However, in practical term, DH is a tad harder. GNFS includes several phases, the two main being the sieve and then the linear reduction. For a big modulus, the linear reduction becomes the bottleneck because of the sheer size of the matrix. For a given modulus size, you will get the same number of elements in the two matrices (the one for RSA and the one for DH), but the matrix elements are simple bits in the RSA case, vs integers modulo p in the DH case. Thus, the DH matrix is larger.

It won't make n-bit DH as "hard" as 2n-bit RSA, though. If we look at the records, we see 768-bit for RSA, 530-bit for DH; and the DH case used less raw power. Moreover, it is not completely justified to compare the hardness of 1024-bit DH with the hardness of 2048-bit RSA, since both are in the "cannot break it" zone.

A summary of all this goes thus: while 1024-bit DH is somewhat stronger (theoretically) than 1024-bit RSA, the difference is slight (say, 1024-bit DH is like 1200-bit RSA at most). But in practical terms the risk of private key theft, for a non-ephemeral key, dwarfs out any cryptanalytic risk for any RSA or DH of 1024 bits or more; in that sense, PFS is a must-have and DHE with a 1024-bit DH key is much safer than RSA-based cipher suites, regardless of the RSA key size.


TOOL-BARS: How do toolbars manage to insert new settings on to the users computer when legitimate programs can't/won't do it? I accidentally installed Ask Toolbar, and it changed my Homepage,Search engine and added some extra stuff. It did all this without alerting Google Chrome!

But when I try to install a legitimate search engine like DuckDuckGo, I have to do a lot of manual work compared to the Ask Toolbar which seems to automate installing the settings.

I was wondering why does't DuckDuckGo use the same methods as Ask?

Is it due to security issues of sorts?

When you installed Ask there was a check box which was enabled by default that gave a high level of permissions to the toolbar. So it doesn't need to ask for these permissions in future.

I have not used duckduckgo, but I assume it is a bit more polite, and asks for specific permissions.


Password protection of encryption and signature keys I would like to store encrypted backup of text files on my computer. I'm developing a python script using Pycrypto to achieve that, based on this code to use the library. (current code)

The basic idea is :

Generate new/Read existing AES + signature keys
Encrypt the data using the first key (AES 256-CBC)
Sign the encrypted data using the second key with HMAC-SHA256

The generation of bytes for the keys is simply the result of Random.get_random_bytes(KEY_SIZE + SIG_SIZE), so 64 bytes in my case.

Now, to improve the security, I would like to add a password protection to the key (if somebody find the keys file). My initial idea is to hash salt+password and XOR the result with the random bytes in the key-file.

If I use SHA256 (to be consistent), it means I output 32 bytes and should XOR twice (for each 32 bytes key) and I don't like that (not sure but sounds like a potential attack). Using a different salt for each key ?

Finally, is there a standard way to store the salt and keys ? I don't like the idea of inventing my own scheme (usually a bad idea in cryptography). Is there some good practices ?

Update: thanks to the answer of Polynomial, I got the following code :

from Crypto import Random
from Crypto.Protocol.KDF import PBKDF2

def generate_new_keys(password, enc_key_size=32, sig_key_size=32):
    rand_bytes = Random.get_random_bytes(enc_key_size + sig_key_size)
    # save the salt
    with open('keys.salt','w') as f:
        f.write(rand_bytes.encode("base64").replace("\n",""))
    # derive the two keys using PBKDF2
    enc_key = PBKDF2(password, rand_bytes[:enc_key_size], dkLen=enc_key_size)
    sig_key = PBKDF2(password, rand_bytes[enc_key_size:], dkLen=sig_key_size)
    return (ency_key, sig_key)

Don't try to come up with your own encryption scheme. The one you propose is vulnerable to a known plaintext attack, which makes key material trivial to recover if any bits of the original file are known.

For example, if I know that the first byte of plaintext is always 0x4B, and I can see that the first byte of ciphertext is 0xC7, I can compute 0x4B ^ 0xC7 and get the first byte of the key, which would be 0x8C. From there I can skip ahead 32 bytes and decrypt that byte of ciphertext, and again, and again. Using that information I might discover more information about your plaintext, and use that to decrypt more of the data.

Encrypt your key file with a block cipher (e.g. AES) using an appropriate mode of operation (e.g. CBC), with a key derived using a proper key derivation algorithm, such as PBKDF2. Using a plain hash function for key derivation is a bad idea, as it's extremely fast and allows an attacker to crack the password efficiently. If your mode of operation requires an initialization vector (IV) it should be random and unique, but is not secret information.


Does steganography ensure confidentiality? Can we say that steganography ensures confidentiality? I think it does not ensure because it is based on the security through obscurity and then it does not respect Kerckhoffs's principles, but the notion of confidentiality being highly subjective, I would appreciate any answer.

Steganography solves a different problem.  Steganography attempts to hide the existence of the data at all, not necessarily protect the confidentiality of the data once it's discovered.

Regarding Kerckhoff's principle, yes, steganography does violate Kerckhoff's principle.  Specifically, point 2:

  It should not require secrecy, and it should not be a problem if it falls into enemy hands;

Steganography does not use a key, and as such requires that the method of encoding data remain secret.


How can I check whether file modified time has been spoofed on ext4? On Debian based system (Ubuntu 14.04.3 server specifically), using ext4 filesystem.

How would I discover if files have been changed, but the modified times have been made to look like the files have not been tampered with?

I'm most interested in a way to check whether this has already happened, rather than using a tool which checks whether it happens from now on.

Host Intrusion Detection Systems (HIDS) can offer this feature : File integrity checking.

I don't try it personnaly but according to the documentation AIDE can do this.

The idea is to create hash values of the files you want to verify they don't change then compare them regularly with new calculated values.


Transmitting Encrpyted Information to SaaS using AES I am new to the whole encryption thing. I've been reading a lot about it lately but still have some questions. So I am tasked with building a sign on solution on our side that will securely transmit information from our servers to a SaaS.

This information is highly sensitive (not passwords though) and thus why we need to encrypt it. What I am trying to wrap my head around is how I go about sending information about how to decrypt this information to the SaaS. Right now I've got it setup in .net that I encrypt it using AES with a 256b bit key, 128 bit IV, using PKCS7 padding, and the CBC cipher mode. I've read conflicting information on whether or not I should change the key and IV every time or not. If I do change the Key and IV every time how do I securely tell my SaaS about that so that they can decrypt the information? Is there another better practice I should be doing to send this information to the SaaS to be decrypted?

First, I suggest you do not attempt to reinvent the wheel: from your description, you're already out of your depth here and should attempt to build your own security this way (even using known good primitives).

Basically, you have to understand first if you want to protect your data in transit or at rest (or both).

If you want to encrypt data in transit, then use TLS. You can discuss what type of certificate or authentication, ponder about what support you need but at no point should you attempt to replace it with something of your own.

If you want to encrypt data at rest, things are a bit less clear cut. The general rule, however, stay the same: pick a set of standard that fits your need (S/MIME, PGP, PKCS#12 to name a few examples) and use that. You will quickly find out that the hard part is not encryption but key management: storing your cryptographic keys securely while still allowing them to be used when needed is a real challenge in pretty much all cases.

Here are however, a couple of answers to your questions:

IVs should be re-generated for EACH message and never reused. That is a requirement for CBC to be "secure". (note that, personally, when I had to deal with CBC I would rather perpend the data with a single block of random data that I would discard it when decrypting. I found it easier to deal with than keep track of IVs).

The key, however, is secret. Depending on your exact need, it can be static (never changing during normal operation) or dynamic (could be unique to each message and derived from either a key exchange protocol or randomly generated before being encrypted with an asymmetric cypher like RSA).

Speaking of CBC, know that it is NOT considered a secure mode: it can be vulnerable to padding oracle attacks.


How is a password kept secure before hashing? I know that once a password is on a server it is hashed and salted. But when it was transferred over the internet it was stored in plain text, right? And also when it is in the memory of the server before it's been hashed.

I think the short answer is that TLS provides encryption in transit over the internet, but the password needs to exist in plaintext on both the browser and the server, and usually little is done to protect or obfuscate it there.

Your browser will establish an encrypted TLS session with the server; which means the wifi access point, your home router, routers on the internet, etc will see the password go by encrypted.
The TLS session will be decrypted at the server and it will have the plaintext password in memory. Since it needs the plaintext to do the hashing, this cannot be avoided. Best practice is to have the password in memory for as little time as possible; ie hash it, check it, and then free that memory (zeroing it out first if you're in a programming language that lets you do that); basically don't keep the password around in server memory longer than you need to.


Help to account all the points of physical access to a rack server to steal software Let's say I want to move my 1U Dell server to co-location site with a hostile company who will try to steal my code (this is almost 90% probability if I dont take steps)...

The limitation for their hostility I see (or hope) - they can't remove the box completely and tell me, "oops, it got lost in mail", they can't hire experts from too high level (like FBI or NSA), so it has to be done on the level of a savvy sysadmin reading hacking forums. Also, they would have to explain any downtime (which is easy but in conjunction with tampering evidence will be powerful deterrent).

Now..

From my understanding the best way to secure your software is to encrypt it on the disk.

Then to disable external access to boot your server for cold boot attack (I think - disconnect optical drive, USB, com port etc.)

Then I still have the following problems - opening the case and connecting to the MB or removing RAM where the decripted software was running before a cold boot attack.

Question #1 - are there other threats for the code to be stolen in the given situation?

What I am thinking is to make sure if they tamper with the case I will get hard proof which can be brought to court and I get the compensation. If the tamper evident device is convincing and reliable then they won't risk their reputation with the legal case and leave this alone.

Please tell me what you think. Is it feasible plan? Is it possible to narrow the chances of stealing to opening the box (I mean is disconnection USB etc will work?) Are there any other things I need to consider?

EDIT. I will try to compile the answers.

The main consideration - using Dell TPM. Box is Dell R210

RAM removal (cold boot attack)
Console access using unsecure account [doest it help to recover TPM keys?]
Boot from another hard disk [doest it help to recover TPM keys?]

EDIT EDIT. Guys, most of you wrongly assumed that having box on colocation means an ISP or Internet company who sells colo to the webservers, gamers etc. Nothing even close in my case. There are few guys in my area of expertise who sells colo at affordable price. (By colo I mean letting other people they know to put boxes in their racks) And we all are doing the same thing so they dont need to ask they know what I do and I know what they do. Putting unsecured box to them is like leaving open bottle of Glenfiddich 18 next to an alcoholic and walk away. Whatever the morality is they will be really really tempted to open it. I know cos I would too in their shoes. Cold boot is not so much sophisticated thing to do either. So most of your projections simply doesnt count in my case.

I am going to leave it open for couple of day is someone would like to add to the actual physical threats list.

Thank you for your patience :)

I think you're not thinking about this clearly.

If you are convinced that the hosting provider is going to try to steal your code, there's a very simple solution: don't deploy your code on a machine with that hosting provider!

If you are convinced that every hosting provider is going to try to steal your code, don't deploy it on any hosting provider: deploy it on machines on your own premises.

That said, I strongly suspect your threat analysis to be mistaken.  I find it hard to believe that there is a 90% probability that every hosting provider will steal your code, if they can get away with it.  There's just no way that is accurate.  If they were caught, the hit to their reputation would be devastating: it would put them out of business.  Reputable providers are unlikely to take that risk.  And, what's more, most hosting providers don't have an interest in your code; they are focused on their hosting service business, and probably don't care about your code.

So I suspect that you have mis-estimated the risk.  But, if you're convinced you've got the risk right, well, the solution is simple.  Just don't use a hosting provider.

You know the old joke:
Patient: Doctor, doctor, please help me.  It hurts when I slap my knee.
Doctor: Well, don't do that then!


How does the CVE-2017-7494 "SambaCry" exploit work? According to media reports, an attacker can

upload a library to a Samba share and then
open a named pipe whose name equals the local path to the uploaded library

to remotely execute the code contained in the library.

How does it work? Is this a "classic" buffer overflow? Or is Samba tricked into executing some legitimate library loading code? If yes, how? Is there something we, as developers, can learn from this? I have checked the usual online resources, but they mainly contain information on how to protect yourself if you are a Samba user.

Trying to find the answer, I have looked at the patch:

--- a/source3/rpc_server/srv_pipe.c
+++ b/source3/rpc_server/srv_pipe.c
@@ -475,6 +475,11 @@ bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
 {
    NTSTATUS status;

+   if (strchr(pipename, '/')) {
+       DEBUG(1, ("Refusing open on pipe %s\n", pipename));
+       return false;
+   }
+
    if (lp_disable_spoolss() && strequal(pipename, "spoolss")) {
        DEBUG(10, ("refusing spoolss access\n"));
        return false;
--

But, apparently, the patch just adds additional validation and does not show the "juicy part" where the malicious library is loaded.

It would be easier if you can analyse the source of the exploit. You can find it here: https://github.com/omri9741/cve-2017-7494

From what can I see it seems Samba just loads the SO and executes it without need of any buffer overflow. Have no idea why such thing is over there but it has probably something to do with RPC over 445/TCP.

Edit:

Yep. So I went bit deep to it and its really related to IPC/RPC. It seems that you was able to open any .so file under specific conditions over named pipes. Of course, only trusted modules should be allowed and not those uploaded by anybody so I think they mainly fixed from where the modules could be loaded.


Force a subordinate CA cert to be signed to include a the CRL distribution point extension? How can I attach a crlDistributionPoints parameter when signing a CSR I've generated as follows:

openssl req -new -key /root/ca/private/private.key -out /root/public.csr

I usually sign with:

openssl ca -extensions v3_ca -days 730 -out /root/ca/certs/public.cer -in /root/public.csr

When I attempt to use -extfile to assign a file I've populated with a crlDistributionPoints parameter, clearly signing fails.  According to the man page for openssl ca, this is because -extensions refers to -extfile for the configuration profile (in this case v3_ca).  Is this correct?

If so, how do I build out a config that contains crlDistributionPoints for use with ca?

I suppose I don't understand the modular design of the configs well, and am concerned that utilizing ca will not work the way I would guess if I write my own openssl.cfg?

I've reviewed the contents of /etc/pki/tls/openssl.cnf, and the following should work to produce a usable -extfile for use with the previously mentioned command (openssl ca -extensions v3_ca -extfile /root/ca/opensslx509.conf -days 730 -out /root/ca/certs/public.cer -in /root/public.csr).

echo "[ v3_ca ]" > /root/ca/opensslx509.conf
echo "subjectKeyIdentifier=hash >> /root/ca/opensslx509.conf
echo "authorityKeyIdentifier=keyid:always,issuer >> /root/ca/opensslx509.conf
echo "basicConstraints = CA:true >> /root/ca/opensslx509.conf
echo "crlDistributionPoints=URI:http://CRLSERVER/CRL.pem" >> /root/ca/opensslx509.conf

I have not tested this at this point.


Is TCP's 3-way handshake a kind of mutual authentication? Assuming no one is able to inspect or MITM in the network. Can I see it as a way to ensure the source IP in packet's header is the real source of the packet, so a kind of authentication ?

Assumptions
Your server is not on the same network as your client thus not able to create a MITM or sniff traffic.
Answers

Is TCP's 3-way handshake a kind of mutual authentication?

I'd say it is, but a relatively weak form of mutual authentication.

Can I see it as a way to ensure the source IP in packet's header is the real source of the packet, so a kind of authentication ?

In all practical cases, yes, you can rely on the source IP in the packet's header being the real source IP if the sequence number is correct and there is no MITM.  Sequence numbers can be anything from 0 to 32^2-1. It is highly unlikely that someone can guess that number faster than the real request can get the correct number.
Recommendation
It seems like you are trying to use the wrong technologies for what you would like.  While they may work, there is a reason you don't use a screwdriver as a hammer.  I'd recommend using TLS for mutual authentication with client and server certificates.


Can a "client-initiated" session cookie provide more privacy and security than existing session alternatives? There are several uses for a cookie, and I would like to offer some kind of guarantee that a cookie is being used for a specific, limited purpose and scope.  In my case, I want to prove that a cookie is only used for authentication.
Question
Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee?
Example
In the example of a session cookie, I envision that the normal session parameters would apply

The scope would be restricted to a one, or a very limited set of URLs,
Set to HTTP only

Some added security requirements would look like this:

The client generates the cookie name and contents from a cryptographically random source
The client sends this preferred cookie to the server at the same time the credentials are sent
If the cookie doesn't conflict with an existing session, the server accepts it and uses it as a bearer token for the remainder of the session

Does a similar, or better solution exist for people who are concerned about cookies, tracking, and other aspects of privacy?

I don't think this will provide any benefit. On a secure web application, the less you depend on client data, the better.

I can see some issues:

This will surely create a vulnerability named Session Fixation: an attacker can create a session, lure your client to a special page, and have the session data on his hands.
The server has no means to know if a session sess12345678 is being cloned, or the client switched IP, or if the client is using a load balancing proxy. If you lock the session to an IP, mobile clients can have trouble.
If your client application token have not sufficient entropy, it's trivial to an attacker to bruteforce lots of possible values.
Any cookie created by your application can be read by Javascript, so an XSS can send them all to an attacker.
You are increasing substantially the complexity on the server side, because you will have to validate both the cookie name and value.
Creating a cryptographic secure cookie and value on the client can be hard, and the generation can be easily spoofed or bypassed by an attacker.

I would stick to secure cookies to authenticate the users.


Has a benefit been demonstrated for credit card machines asking for ZIP code? In the U.S., many credit card machines at places like gas stations have started asking for your ZIP (postal) code to use a credit card ostensibly to help verify that you really are the cardholder, rather than the card being stolen. My question is simply: Is there any evidence that this actually leads to a significant reduction in successful credit card fraud?

It seems to me like this would not be a very useful measure for a machine that requires the card to be present anyway. I would have guessed that the most common way someone would physically end up with your credit card would be if they stole your wallet, in which case they almost certainly have at least one and likely several IDs that include your ZIP code. For example, in my wallet, at the very least, my driver's license, car insurance card, business card, and pilot certificate all have my zip code listed and it would also be trivial to figure out from my voter registration card. Thus, I'm curious if any actual security benefit has been shown for this or not.

Is there any evidence that this actually leads to a significant reduction in successful credit card fraud?

Yes there is evidence, and Yes, it absolutely has resulted in reducing many types of card fraud:

The fraud prevention feature you are referring to is called Address Verification Service (AVS).  AVS service checks that the street number and/or the zip code presented at the terminal match the data present for the card holder at the issuing bank.

In real-time, the payment processor will return an AVS Response. Based on the response, the merchant can decide to reject a non-conforming transaction.

It has been adopted by nearly every card issuer in the US.

See Merchant Guide to the Visa Address Verification Service

The possible response codes, and the configurable reject settings are shown here:

In a gas station terminal setting, the terminal might be set to reject AVS Response codes N and A, for example.


Need help to define existing web app vulnerability I found vulnerability in a web app where I could manipulate URL parameters, i.e. take host/friends.php and then change it to host/friends.php?view=username and as a result see the users friends and subscriptions. Normally this view function is not provided by the web app's interface.

Now I would like to define this vulnerability using OWASP top 10 list, but I'm not too sure whether it is definition A5 or A7 or something else?

From the information you've provided it sounds like your issue would fit in to OWASP 2013 Top 10 under "A7 - Missing Function Level Access Control" as the application should apply an access control to restrict who can see that information but appears to be failing to do so.


Whats should be TRACE response of an API (if it is not allowed on server)? I am testing a website and noticed that when I change the GET method of the API request to TRACE, it returns an error 405-Method not allowed in Burp repeater. That's fine.

The problem is, lots of other information is also coming in response like below:

HTTP/1.1 405 Method Not Allowed
Expires: 0
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: no-cache, no-store, must-revalidate
Keep-Alive: timeout=300
Keep-Alive: timeout=300
Set-Cookie: JSESSIONID=******************; path=/; secure; HttpOnly
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; mode=block
Pragma: no-cache
Pragma: no-cache
X-Frame-Options: sameorigin
X-Frame-Options: sameorigin
MS-Node-Instance: MS_node_1.8100
MS-Node-Instance: MS_node_1.8100
Content-Security-Policy: default-src 'self' 'unsafe-eval' 'unsafe-inline';font-src 'self' data:; img-src 'self' data: https: blob:; connect-src 'self' wss:;
Content-Security-Policy: default-src 'self' 'unsafe-eval' 'unsafe-inline';font-src 'self' data:; img-src 'self' data: https: blob:; connect-src 'self' wss:;
Date: Mon, *********** GMT
Allow: HEAD, POST, GET, OPTIONS, PUT
Connection: close
Content-Length: 0

Does this constitute as a vulnerability?

The information that you've listed as coming back with the 405 response code appears to be a standard set of Web server headers.

The server giving that information back isn't generally, in and of itself, a security vulnerability as this is all information that servers need to provide to clients to allow their operation.

There's a couple of odd responses in there however, which don't seem ideal and could be worth querying with the application owner

Several of the headers are repeated.  This could cause issues if changes are made to the system which generates one of those two sets of headers, as the browser (or other user agent) might get confused by differening headers
The content security policy in use isn't ideal, as it includes items like unsafe-eval and unsafe-inline which aren't great for security.


Possible way to extract sudo password from running system via the clipboard I use to copy and paste my sudo password from a KeePass file so I guess the plain text user password will be saved in RAM at some point when I use it, for example, to accept an update. Is that right?

Would it be theoretically possible for an attacker to extract this password string or a part of it by connecting the RAM to another machine (for example Cold Boot Attack)?
Could the attacker then reconnect the RAM to the first still running machine and enter the user password to unlock the screen for example?

Would it make a difference if I typed in the sudo password with my keyboard every time I need it?
I think simple keystrokes are not being saved in RAM, right?

Another option to prevent this would be a custom screenlocker password, I guess.

Yes. In fact this is a common feature of keyloggers. They will often take screen captures every X seconds, monitor the clipboard, and log key strokes. These features pretty much defeat your strategy of typing rather than copy/paste.

However you mention you're using keepass. So you may be protected. Take a look at this information from their FAQ

  Because we are heavily using the clipboard, it is useful to block all current clipboard monitors. This means that no other applications will get notified when KeePass changes the clipboard.

  For this, an invisible window is created and added to the top of the
  clipboard event handler chain. This window simply throws away all
  clipboard change messages it receives, practically blocking all other
  applications from receiving any events.

It also details another feature to defeat keyloggers:

  The Auto-Type feature of KeePass is very powerful: it sends simulated keypresses to other applications. This works with all Windows applications and for the target applications it's not possible to distinguish between real keypresses and the ones simulated by Auto-Type. This at the same time is the main disadvantage of Auto-Type, because keyloggers can eavesdrop the simulated keys. That's where Two-Channel Auto-Type Obfuscation (TCATO) comes into play.

  TCATO makes standard keyloggers useless. It uses the Windows clipboard
  to transfer parts of the auto-typed text into the target application.
  Keyloggers can see the Ctrl-V presses, but do not log the actual
  contents pasted from the clipboard.

The bottom line, as you may gather, is that as new attacks arise so do new defenses (and vice versa).


Is this file malicious and how is it being transfered via youtube? Today on my blog a spam comment appeared. I noticed a Youtube link being in the spam comment, which I found to be rather odd as no other link was distributed. I opened the link in a sandbox environment and it turned out to download a flash file of some sort, which seemed rather strange to me considering the url is a legit Youtube link as far as I can see:

The following link should be considered unsafe until otherwise proven!

m <DOT> youtube <DOT> com/e/7wQ-hZEVLeY

I tested the file using virustotal.com but not even a single anti-virus program flagged the file as being malicious.

I have a hard time believing that a spam comment was made containing only a single link, which downloads a flash file is not malicious so I am seeking assistence here to what the file actually is, if it should be considered malware and how it is possible to use Youtube to distribute this file. I am especially interested in that last question.

Okay so it turned out to be an attempt to embed the video into the comment section of the blog. The link that was in there is the flash object of the video, so it is not malicious.

Apparently there is some sort of new spamming campaign as searching for the strings used in the spam message returns more of the same, although not working quite so well as they did not include the link in their message but rather as their website, which makes their username redirect to the flash file instead of embedding it on the page itself.


Denial of Service against an asynchronous Web service Is it possible to perform a denial of service attack on an asynchronous web service?  Isn't the operating system supposed to release the thread? It shouldn't matter if someone attacking a system would be  throwing thousands/millions of requests per second at that server.

Does anyone have an opinion on this?

If, by asynchronous, you mean a web server like vertx/undertow that puts requests onto an event bus an handles them from a thread pool, then DoS should still be possible, though you may require a higher load if you do an L7 flooding attack than when DoS-ing a threaded server like Apache.

The OS is indeed not creating and blocking a single thread per request, and instead serving from a pool of event-driven workers, which means that CPU exhaustion is harder to achieve. However, at the network level, there are still a large number of open connections, and the system may still run out of file descriptors and be unable to handle new connections.

Indeed, I did some simple testing to benchmark Apache Tomcat v/s vertx and found that on identically configured AWS EC2 instances, vertx has a capacity that is four times higher than Apache, but still crashes even from a single L7 flood generator.


Does DKIM protect the whole body message? From RFC6376 #page-29, it says:

  In hash step 1, the Signer/Verifier MUST hash the message body,  canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag.

From Wikipedia DomainKeys Identified Mail, it says:

  Both header and body contribute to the signature. First, the message
  body is hashed, always from the beginning, possibly truncated at a
  given length (which may be zero)...

What's the default value of the l= tag? Does the whole message body get hashed? If not the whole body message get hashed, then may an attacker modify the unhashed part of the body message and pass DKIM check?

From Wikipedia DomainKeys Identified Mail:

  ....No data integrity is implied.

From RFC6376 #section-1.5:

  Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.

Why is it saying that DKIM doesn't ensure data integrity? Isn't "hashed content has not changed" == "data integrity"?

There is a default value of l:

From https://tools.ietf.org/html/rfc6376#section-3.5 :

  l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
        default is entire body).

Of course the default should be the entire body. Or what else is DKIM protecting? I write an email and DKIM says "OK I only protect half of your email"? And then Gmail receives the email and warns the user "Dear Bob, the first 100 bytes of this email is validated. But for the rest, I can't promise." ?

Again, if the default is not the entire body, then when a user writes an email, how would he know how many characters he should write?

And I disagree with @schroeder 's answer.

  The reason why there is a defined length is that email servers in the
  relay chain may add to the body. If the entire body was signed and an
  email server added to the body, then the signature check would fail.

If a mail relay or intermediate server change the original email content, the DKIM signature would fail and should fail. And that's why there are other mechanisms invented to get around with this, e.g. ARC (authenticated received chain).


Banking app logon - multiple fingerprints on a device vs 2 passwords known by 1 person Yesterday I logged on to my banking app via my iPhone. The normal procedure was to enter information that consisted of:

The answer to a security question. This had to be entered in full and was the same during each login.
Three characters from an additional string. The specific characters asked for were different for each login.

A message appeared which said that they were "upgrading" this to be more secure. It involved setting up a security answer (a string which was different to [1]). However, after using this it simply said that touch (fingerprint) ID could be used instead of using any of this information.

In theory this sounded ok, but it then said that it would work for anyone who had a fingerprint access for the device. The device in question is an iPhone SE. Given it's possible for multiple fingerprints to work on an iPhone I was wondering how secure this actually is?

I have a couple of thoughts on this:

If I have to enter the details as in [1] and [2] then only I know them (unless they are leaked). So in theory only one person knows these details (me).

versus:

If someone else has fingerprint access on the device I use they can enter the app without any additional details.

My thoughts were what if this was a shared device (e.g. family iPad/phone)? This is possible - and quite often the case - for example:

  Or, maybe you share an iPad with your significant other, and they want to use Touch ID too. There’s any number of valid scenarios where you’d want to use a different finger with your Touch ID sensor. Luckily, Apple anticipated this because iOS allows you to add as many fingerprints to your device as you want

(Source: https://www.howtogeek.com/205525/how-to-add-touch-id-fingerprints-to-iphone-or-ipad/)

In the previous method it relied on someone entering details only they knew, versus a method multiple people may be able to perform.

I won't name the bank in case this is some serious issue.

Please can someone provide details about whether this is genuinely a step in the right direction in terms of security and whether there are advantages/disadvantages over the previous method?

The problem with multiple fingerprints: The bank application can't store the actual fingerprint nor a mathematical representation of it (like a number or a hash). The only thing that the application receives is something like "true" or "false", meaning "true" if the Touch ID was successful and "false" if it wasn't successful. And for security reasons that is really all Apple provides when using Touch ID. An application can't ask for a specific fingerprint on the device.

The implication of this is that other persons who are authenticated with Touch ID on your iPhone could also use the bank application since the iPhone would provide a successful Touch ID authentication to the application.

So if I were you I wouldn't change to Touch ID for the bank application.


Reproduce part of a hash I know very little about hashes, but I was wondering if I know the first 20 digits of what got hashed and the first 8 digits of the hash, is there any way to figure out the entire hash?

For example:
This is what is getting hashed using SHA256:
G3f3xfxQCG4f438e18e3f7d0ff5fbb42d0e233b331829cc0e07df04255892b4c411ba78d6c98c5490bd6

I know "G3f3xfxQCG4f438e18e3"

and after it gets hashed it becomes:
ac5b8839772026fcdf1ca090afb333795f4a63d155e6224bf23b0fa2789e1204

I also know:
ac5b8839

Is there any way for me to be able to get the full hash?

is there any way for me to be able to get the full hash?

No.

You didn't name your hash function. So I'm assuming, you're talking about a regular cryptographic hash function, like SHA-256 for example. In your regular cryptographic hash you want what is called the "Avalaunch Effect". It means that if even one bit of the input is flipped, added or removed, then the hashed output is very, very different.

For completeness sake: Two other non-cryptographic hashes:

Checksums
If you don't care about attackers, then you might want do use a faster hash, that isn't a cryptographic hash. This is sometimes also called a "checksum". Like CRC-32 for example.
There the emphasis is on detecting transmission errors and not malicious manipulation.
Similarity preserving hashes
If you actually want similarities to be preserved, then the last thing you want is the Avalanche Effect. For example if you have a large collection of files and want to sort them by similarity. Or if you have a virus sample and want to know if another file is somehow virus-y in that way as well. One hash that does this and preserves similarities is "ssdeep". VirusTotal.com uses it on its results pages.


Where to store AES keys when encrypting files at rest? I've gone through the below question:

How to store an AES Key? an Initialization Vector(IV)?

And read the below articles about how to encrypt files using AES in CBC mode:

http://www.novixys.com/blog/using-aes-encryption-decryption-python-pycrypto/
https://eli.thegreenplace.net/2010/06/25/aes-encryption-of-files-in-python-with-pycrypto

But didn't get my answer. Instead of the file assume that I have text for encryption so I do as below:

from Crypto.Cipher import AES
import hashlib

password = 'A_VERY_STRONG_RANDOM_PASSWORD'
key = hashlib.sha256(password).digest()

IV = ''.join(chr(random.randint(0, 0xFF)) for i in range(16))

mode = AES.MODE_CBC
encryptor = AES.new(key, mode, IV=IV)

text = 'j' * 64 + 'i' * 128
ciphertext = encryptor.encrypt(text)

Users of the system has hundreds of files and they all need to be encrypted at rest, so I want to use AES as its encryption is fast and secure.

The first question is that do I need to generate a new password everytime I want to encrypt a file? Or should it be per user? or system wide? Which one is the best practice and more secure?

The second question is that where should I store these/this password(s)?

NOTE: I don't want to use HSM or any external hardware for this.

Let's call the system that performs the encryption E and any system that stores the encrypted files S (for storage).

Files stored on S are secure as long as the attacker doesn't have the corresponding key.

Since you don't want to use an HSM we can assume that any keys stored on E will be compromised if E is compromised. Now you have basically two options for storage: disk or memory. On disk is pretty trivial: you use OS ACL's to restrict access to the encryption key, and hope that it will be fine. For in memory you can build a system that requires you to manually supply a master secret (typing in, read a QR code via webcam, etc.) when the encryption service starts (or on key rotation, see below). This way the key can't be accessed via vulnerabilities that provide FS access only (e.g. path traversal). Note that in Python you will have a hard time erasing secrets from memory, but you can use dirty hacks like this.

(note that Virtualization Based Security can "emulate" extra HW that would have remarkable benefits but I don't think this matches your use-case)

Expecting the compromise of E, it would be a good idea to periodically rotate keys (and move old keys away from E to safe offline storage) so any incident won't affect files encrypted with previous keys. The key rotation period should depend on your needs.

Edit: In case of a decent cipher like AES encryption large number of files with the same key is not a problem, so using a single key doesn't result in weaker encryption than using multiple keys. At the end of the day it's about key management.

The use of per file or per user encrpytion also depends on the key management requirements. Per user keys can make sense if you need to decrypt files on a per-user basis. Per file passwords can limit the impact of a compromise but archiving old keys can be problematic and you should keep in mind that systems usually remain in a compromised state for extended periods of time, so this may not help much more than a sane periodic rekey process.


How To Proper Handle Passwords In C# It's a well known fact that C# string is pretty insecure, it's not pinned in RAM, the Garbage Collector can move it, copy it, leave multiple traces of it in RAM and the RAM can be swapped and be available as a file to be read, not mentioning several other known facts.

In order to mitigate this Microsoft came up with SecureString. The thing is: what is the proper way of using it?

I ask this because sooner or later you will have to extract the inner string. And yes, SecureString does allow us to write one char at a time and gives us some other minor usages while hiding it's secret, but sometimes we need the whole string at once or something like it. So far all implementations I see use a regular string at the end, with the extracted and decrypted content from the SecureString which I think (or hope) it's avoidable in some cases even though it might involve some complicated code to get around a .NET string.

In my case I use a library for password hashing called BCrypt. It uses a regular string for calculating the hashes, which I think is far from ideal. I didn't find any libraries that would accept a SecureString directly, so I don't have much of an option but use it.

Currently I run code such as this:

SecureString password; // This usually comes from a PasswordBox Property
IntPtr passwordBSTR = Marshal.SecureStringToBSTR(password);

string insecurePassword = Marshal.PtrToStringBSTR(passwordBSTR);
Marshal.ZeroFreeBSTR(passwordBSTR);
passwordBSTR = default(IntPtr);
password.Clear();

// Use the insecurePassword....usually as:
bool result = BCrypt.Net.BCrypt.Verify(insecurePassword, user.Password); // This hashes the provided password and compares it with another BCrypt hash.

insecureString = string.Empty; // hoping for the GC to act now, fingers crossed.

// use result and etc...

This way the password raw string will be copied multiple times for the BCrypt method and probably even more times inside it.

This makes some questions arise in my mind:

1 - Are BSTR strings like C strings in the sense of memory management? Are they pinned in RAM and I can manipulate them and erase them as I see fit so it will be more secure to use them in C# or interop it with a C++ code so I can eliminate a lot of my .NET string manipulations (like verifying if the password string is null or white space or has the correct length or has the desired password strength)?

2 - If question's #1 answer is "yes" then should I invest some time to pass the BSTR string to a interop C++ code to calculate it's hash and verify?

3 - Is my later code correct or am I missing something on SecureString manipulation?

Just to be clear: My main intent with this question is to evaluate if I should pass all my password handling code to C++ from my C# (probably using C++/CLI or interop) to achieve a more secure code than what C# has to offer. This scenario really concerns me for password string hashing were multiple strings will be created and copied with the user's secret information scattered all over the RAM.

As an example: I could make a method like:

public string SecureHash(SecureString password)

And this method will extract the SecureString value and pass it as a BSTR string (or other extraction option, I honestly don't know the benefits between them) to a C++ hashing method, so we can control all the places our password sits in memory.

I ask this to not have a huge work refactoring my code and in the end discover it was all for nothing because I was using SecureStrings wrongly all the time and there are already solutions for this, or a false sense of security, as it happens sometimes, since I am not aware of how BSTR strings are implemented in memory or the other SecureStrings extraction options (Unicode, ANSI and etc).

It all depends on what you want to do.

Answer to the first part of your post:

There are .net implementations of secure string in the following: WPF's System.Windows.Controls.PasswordBox control keeps the password as a SecureString internally (exposed as a copy through PasswordBox::SecurePassword) The System.Diagnostics.ProcessStartInfo::Password property is a SecureString and finally X509Certificate2 takes a SecureString for the password.

Answer to the second part of your post:

If you want to get more into the internals of hashing, BCrypt/BCryptPrimatives/PBKDF2 are generally considered FIPS 140-2 compliant (A Government Standard) specifically because they do carefully handle hashing and passwords on disk and in memory.

If you really want to go into the nitty gritty (And it seems like you do...) Go here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1892.pdf

There are plenty of details about how this works in that PDF, sorry for the link, it's just too big of a subject to cover in a single post.


Google custom Search Engine api key: is it confidential? Normally, I'd say yes, api keys should be kept secret, and Google's api console even says that.  However, I'm just making an ajax get call and all the info is in the clear on my page in order to construct that query, including my api key and cx(custom search engine id).  Presumably, someone else can use my credentials to make queries against my daily limit.

Google does let you specify a whitelist of referrers who are allowed to use your cse by domain.  Does that somewhat mitigate this issue?  If they are just using HTTP_REFERRER, can that be faked?

Any thoughts?

Google uses the API key to identify who is sending those requests.  Google will impose a quota.  As you've correctly identified, if Google receives too many requests using that API key, they'll blacklist the API key.  If that happens, your own site/app will stop working.

Therefore, there are risks to leaving the API key in the clear on your page.  These risks are somewhat modest: someone who gains the API key doesn't get root on your systems, but they might end up causing your app to stop working.

If this risk bothers you, then don't put the API key on your web page.  Instead, have the client issue an AJAX request to your server, and then have the server issue the request to Google and return the results back to the client.  This way, the Google API key is never exposed to the client.

The Referer header check prevents someone else from copying your API key and putting it in their own web page and using Javascript to query Google.  However, it does not prevent them from copying your API key and using it in requests they initiate from their own machines.  (If they use curl or some other similar library on their own machine, they can forge the Referer header and make it say whatever they want.  Therefore, the Referer check does not help prevent this scenario.  It only prevents others from embedding the API key in their web page and using it in Javascript that runs in the browser of folks who visit their web page.)


Is Docker a PCI DSS compliant form of virtualization? I'm thinking of the mass of "single function per server" virtual machines which really do nothing in terms of memory and CPU that a PCI DSS certification entails, the NTP server, central authentication, DNS, jump host, local OS package repos etc etc,

can those be summarized in a one VMWare box with a bunch of containers on? In much the analogue way a bunch of VMWare boxes can be squeezed into a single hypervisor?

I know this stuff could end up deeply "in the eye of the beholder/QSA" area, but I'm either hoping to find out that "no, because..." or "yes, I've done it" kind of answer. Also, "I don't see why not" from someone deep into docker and with PCI experience would also be nice ^_^

UPDATE 1, Docker security docs

Introduction to Container Security: Understanding the isolation properties of Docker
Docker Security

A self-answer after a convo on the #docker IRC,

PCI DSS v3.2 doesn't state anything about the kind of virtualization that is required, nothing states you should use hardware instead of OS-level virtualization (somebody correct me if I'm wrong).

However, traditional (HW) virtualization is a relatively simple piece of code ~100k LOC (allegedly) which is hardware assisted and depends heavily on the guest OS to do most of the heavy lifting.

OS-level virtualization reuses the kernel-space between virtual machines, and kernel is a much more complicated piece of code, leaving a MUCH larger attack surface - basically the same thing that makes docker super-nice to stack a bunch of VMs with limited resources in a tiny bit of memory is what makes it less useful for the PCI DSS use case - kernel reuse.

So, even though there's nothing about PCI DSS at the moment preventing you from using OS-level virtualization such as what Docker provides and it would probably pass scrutiny by most QSAs, it feels like it should be prohibited as it leaves you with a more vulnerable architecture.

Then again, many people use and successfully certify software-based HSMs to store their keys (JCEKS and whatnot) even though it feels that it should be prohibited.

I guess the answer to my question would be "yes, you could do it, it would probably pass certification, but you probably shouldn't do it".

Full convo from the #docker irc channel


Why browsers implement stricter policy for local files I have a problem viewing HTML/JS/CSS files generated on disk. Specifically, several calls in javascript are blocked by Google Chrome. I googled and found an answer here: https://stackoverflow.com/questions/21408510/chrome-cant-load-web-worker. In the end, I have to go an extra mile to install and run a websever on my machine so that I can properly view website hosted on my own filesystem.

However, I don't understand the reasoning. Why does the browser implement stricter policy for local files? Aren't files already on my disk more trustworthy than those loaded from remote sites?

Aren't files already on my disk more trustworthy than those loaded from remote sites?

No.

Expected local HTML use case for normal (ie non-developer) users is they've gone to a web page, wanted to view it offline, and used the browser's Save As functionality to make a local copy. This does not imply any level of trust between the user and the operator of the site hosting that page and should not, in general, give that operator access to read other files from the user's hard disc.

In days of old, IE used to grant greater permissions to HTML on the local filesystem. The upshot was a ton of security holes, in that any application that could be persuaded to save a file containing HTML to a predictable path could typically be exploited to execute attacker code.