Does recompiling a binary from source code make it more secure/obscure? Using standard hardening options like PIC, Stack Protection ...
does a mere recompilation make a program more secure against attacks?
You have the source code of a program, compile it two times with the same options. One of the binaries you give your attacker. Does it help him/not help him if you give him the same binary you will use or the other binary?
Reproducible builds are obviously out of question.
Before modern hardening options were used it maybe made a difference because recompilation produced a different layout but today, when the binary is loaded into memory (all?) parts are randomized anyways.
So is there any point in recompiling programs from source considering build options are the same?

In general, modern compilers are deterministic.  That is, for most sets of options, given the same inputs, they will produce the same outputs.  That's why reproducible builds are even possible.
Moreover, this is the behavior you want: the compiler's job is to produce an executable or shared library that faithfully reproduces the source code when executed in object code.  If it produced wildly different behavior or binaries with different security behavior when presented with the same options, that would make it hard to reason about the behavior of the code or the security of it.
So no, recompiling a binary with the same compiler and options provides no measurable difference in security.  Features such as ASLR that use random addresses are handled by the dynamic linker at runtime and are therefore not baked into the binary.
Users may wish to compile source for various other reasons, though.  For example, users may want to modify the code, audit the code for vulnerabilities, verify that the binary produced matches the source code, or various other reasons.  Those are valuable and desirable reasons to compile from the source code even if the security properties of the binary don't change.


XSS - arbitrary file in background-image css property Is it possible to make an XSS attack if you can inject an arbitrary file (any extension, like: .js, .html etc...) in background-image CSS property? If yes, how to do it?

No, that's not possible.

A value to background-image will be rendered as an image. Even an SVG with embedded script code would just be displayed as an image when loaded via background-image. So XSS isn't possible here (the same way an arbitrary value to <img src="..."> can never lead to XSS).

Even if you couldn't just change a background-image value but inject new CSS, you most likely wouldn't be able to get XSS. The techniques to inject script code via CSS expression(...) or url('javascript:...') don't work in modern browsers. In other words, even embedding an entire user-controlled CSS file can lead to severe side-channel leaks but not to plain XSS.


Current State of BREACH (GZIP SSL Attack)? It has been one year since BREACH made our way into our hearts, and there does not seem to be any articles or posts or patches since then, is my Google-fu weakening?

Has BREACH been mitigated or patched in Apache/nginx?
Can we enable GZIP on SSL if we provide further protections?

BREACH is a vulnerability that is present when several conditions are met:

HTTP compression is used,
A part of the input is reflected,
A static secret is present in the HTTP body of the response,
The attacker can read the size of the encrypted response,
The attacker can forge requests to the site under attack.

Each of these conditions pose no threat in themselves, but combined they lead to a vulnerability. This is partly the reason that there is no clear-cut solution to this vulnerability: simply upgrading Apache or OpenSSL is not enough. Disabling gzip compression for everything does not make much sense. Reflecting user input is totally fine most of the time. There is not really a simple solution, but there has been made some progress in the last years to mitigate BREACH.

One of the best solutions is the same-site cookie flag. This makes cookies no longer work on cross-origin requests, which solves CSRF-attacks and thus also BREACH. Somebody is working on a specification and it is already implemented in Chrome, Firefox, and Edge on Windows 10. Chrome is even working on making all cookies SameSite by default, thus solving BREACH and all other CSRF-like attacks in Chrome.

There are also several projects that randomize the response length. Some modules put a random HTML comment in each response, which is a total hack. Padding support has been formalized in TLS 1.3, but it will take some time before that is implemented in servers.

Some frameworks have also taken steps to mitigate BREACH attacks, particularly to prevent guessing of the CSRF token. Django randomizes the CSRF token on each request, so that it can not be guessed over multiple requests. This is relatively new, released this year in Django 1.10.

There has also been some progress for attackers. This year researchers have shown that BREACH can also be converted to a timing attack (HEIST), where it is exploitable by just running Javascript in the browser. Finally, a new toolkit (Rupture) has also been developed this year to exploit compression side-channel vulnerabilities.


How to verify an OpenPGP key's ownership? I've added the public key of Diceware creator (please use it as a practical example), I've added it by downloading diceware.wordlist.asc, and I didn't have his key and couldn't immediately find it to import it to GnuPG.

So I improvised and did gpg --verify ~/Desktop/diceware.wordlist.asc.

This showed that the file was signed by key ID: AC3184A1 (short key ID, I know... But that's what gpg showed me!)

I took that and did gpg --recv AC3184A1. Which I now have.

How can I make sure this key is owned by Arnold G. Reinhold?

Sure, it shows the name in the key ID owner in gpg, and it lists the same fingerprint found here. But neither of those is a trusted way to verify. The fingerprint is on an untrusted page, and for all I know, it's been changed in transit before reaching my PC. And the name is just arbitrary data that I can replicate myself using any gpg client.

I remember once I imported a key of someone, and they told me to view the "Web of Trust" signatures. I've been trying to find that command but I just couldn't pinpoint it with certainty. I found this command, which I think it's the WOT command: gpg --list-sig AC3184A1 which if issued will produce this:

pub   1024R/AC3184A1 1995-02-23
uid                  Arnold G. Reinhold <reinhold@world.std.com>
sig          AC3184A1 1995-02-23  Arnold G. Reinhold <reinhold@world.std.com>
sig          5F63A5B9 1995-03-27  [User ID not found]
sig          0959ECA9 1995-12-02  [User ID not found]
sig          0FF98BC9 1997-04-20  [User ID not found]
sig          E3EF9085 2001-11-28  [User ID not found]
sig          AC48A400 2001-10-22  [User ID not found]
sig          066030C3 2001-11-28  [User ID not found]
sig          D782FE45 2002-03-31  [User ID not found]
sig          BBD264A6 2004-01-02  [User ID not found]
sig 1        87D1CE0F 2004-03-04  [User ID not found]

But all of those are [User ID not found].

So again, how can I make sure the key is for whom it says it's for?

PS. Please don't go into 1024bit key weaknesses. I know this.

UPDATE:

Assuming I have done everything here correctly, and that I found gpg --list-sig AC3184A1 which if issued will produce this:

pub   1024R/AC3184A1 1995-02-23
uid                  Arnold G. Reinhold <reinhold@world.std.com>
sig          AC3184A1 1995-02-23  Arnold G. Reinhold <reinhold@world.std.com>
sig          5F63A5B9 1995-03-27  [PEOPLE I TRUST@TRUSTED.ORG]
sig          0959ECA9 1995-12-02  [PEOPLE I TRUST@TRUSTED.ORG]
sig          0FF98BC9 1997-04-20  [PEOPLE I TRUST@TRUSTED.ORG]
sig          E3EF9085 2001-11-28  [PEOPLE I TRUST@TRUSTED.ORG]
sig          AC48A400 2001-10-22  [PEOPLE I TRUST@TRUSTED.ORG]
sig          066030C3 2001-11-28  [User ID not found]
sig          D782FE45 2002-03-31  [User ID not found]
sig          BBD264A6 2004-01-02  [User ID not found]
sig 1        87D1CE0F 2004-03-04  [User ID not found]

How can I make sure that [PEOPLE I TRUST@TRUSTED.ORG] aren't all also forged identities? I can now make [PEOPLE I TRUST@TRUSTED.ORG] key ID and published it, can't I?

PS: This is the Diceware list I'm using in this question

Important note before I start: in OpenPGP, there is nobody telling you whom to trust. You have to perform this verification on your own, but there are tools (like certifications in the web of trust) that help you doing so. For the same reasons, I cannot provide you with a step-by-step tutorial on verifying a given OpenPGP key, but can only give some advice on how you could possibly verify it on your own.

You have two possibilities to verify the key's ownership: directly or through the web of trust.

Directly Verifying OpenPGP Keys

This is rather obvious. Find the owner, and ask him through a trusted channel. Meeting him probably involves least hassle -- apart from fixing an appointment and travelling.

If this is too much hassle or expensive (which it probably will be), you can go for other ways of verifying the fingerprint (choose depending on your paranoidity, not all of those will be appropriate for your use case).

Verify against the web site. If it is not properly encrypted or you don't trust the certificate, consider also verifying against web caches like archive.org, which also hosts a time line of websites' changes. Consider using multiple connections, possible from different countries (ask somebody, use VPN, proxies, ...).
Verify against completely unconnected channels. For example, maybe the fingerprint was once printed somewhere in a product box, or is included in a trusted place: for example, is there a Debian package also listing the fingerprint in the documentation somewhere?
Search in closely connected news groups and mailing lists for signed posts. When there's a history of signed posts and nobody crying "hey, that's not me!", this also indicates the key might belong to whom it claims.
Generally try to find as much indications as you can find the key is the right one, especially over time. Also try to find whether there are other keys that seem to belong to the owner, but are not used widely (news group posts, mailing lists, as above).

The last points only can be an indication that everything's fine, and how much of those you accept depends on your needs.

Verifying Through the Web of Trust

An alternative is verification through the web of trust. A helpful tool for building a trust chain would be the PGP pathfinder, I linked an example with a trust path from my key to Anold Reinhold's key (which is of limited use, by the way).

For verifying throughout the web of trust, you have to build a trust path, this means there must be a way to validate each step in-between. If there is a valid key with an outgoing certification, the certified key will also be valid; also depending on the maximum path length, certification level and trust settings. I put together some more details in "What is the exact meaning of this gpg output regarding trust?".

If you cannot build a trust path, because you don't know anybody of those, you could go for trusted organizations. Either fetch all of keys that issued certifications, or query a key server which already knows all of them. Do you recognize any well-known and trusted organization? You might accept to trust their employees/members, and be able to verify their fingerprints through the organization's website. Which ones you consider well-trusted fully depends own your personal opinion. John R. Levine issued multiple certification from different keys and is rather well-known for his publications and work, thus might be a good starting point if you are able to verify his key through some of the described measures listed above.

A good way of bootstrapping those trust paths is regularly visiting key signing parties at different occasions.

Verifying Through a Certificate Authority

This is actually very close to the web of trust network and indeed uses the same tools. Certificate authorities (as also known from X.509) issue certificates based on a set of rules. If you trust the CA, you can trust all of their certifications. Examples of such CAs in the OpenPGP environment would be

CAcert (they also sign OpenPGP keys)
Heise Verlag (German site, a company running a few German computer science magazines, and also do some CA services)
PGP Global Directory (only validated mail addresses, not identities)


Ways around browser xss detection Most modern browsers will detect xss attempts (script code in the URL) and prevent execution. Are there any known standard ways around this or are xss attacks pretty much impossible now?

There are no standard ways around, but there are ways around. What exactly you have to do to get around will depend on the browser and on the version. On this link you can find some examples to get around the protection in Google Chrome:

http://blog.securitee.org/?p=37

The precondition on the examples at this blog post is that there are two GET parameters in the link which You can use for XSS. If an attacker would submit following for GET parameters a and b, Chrome will block it:

a=<script>alert(1)</script>&b=something

But if the a and b parameters are changed like this:

a=<script>void('&b=');alert(1);</script>

...Chrome will not detect the XSS. I tested it now and it works.


Discovered a security flaw in a company, what to do? While playing with a site I have discovered a huge security problem. The thing is, if I tell them about it they might question what was I doing in the first place.

I was trying to hack my friends account. I wasn't planning to do anything with it. I was just very curious and wanted to try something. I didn't think it would work because it was one of the big companies in the world. However, it did!

I know, what I did was wrong and I will never do it again but for now what should I do?

You just found the issue, you didn't take advantage of the flaw and never intended to do harm (I assume you wouldn't do any harm to your friends).

However, every company should be happy if you report the issue to them. Big companies like Twitter or Facebook even pay nice bounties for this.

You might check out HackerOne if the company you are talking about is listed. In case it is, just go ahead and submit an issue. You don't have to worry about the "I tried to hack them, they will send the police and arrest me" scenario. In case it is not listed, try to browse their web if they offer some sort of bounty program themselves. If they don't you can still submit the issue to their support, etc.


Using old router as wi-fi extender/extra security on shared network? I just moved into a building with three apartments, all of which split an internet subscription.  There is only one router, however, in one of the other apartments.  For security/privacy purposes, I'd like to set up some way to prevent my neighbors on the same network from viewing or accessing any of my online information.

I have an old router with me, which I'm hoping to use as a wireless extender.  I already know it's compatible with DD-WRT, so I'm fairly certain this will work, as long as I get the MAC address from the main router.  Unfortunately, I don't have physical access to the main router though, since it's in another unit of the building.  If I do this, will I be able to use my router to prevent traffic from potentially being viewed by other users on the same network?  And if not, what other security options would you recommend?  Would a good VPN service be more effective?

Thanks

I have this problem.

I solved it by using a WiFi media bridge to connect to the existing WiFi, connected that to a firewall, then could connect another device behind the firewall (another AP with a different password if necessary).

It protects things like my file stored on my NAS and prevents users from directly connecting to my devices.. however as the Internet activity still goes over the main WiFi link you have to assume that could be read by others.

Of course it depends what you're trying to protect and what your risks are, for me it was the data that was on my devices, not my Internet activity.


Looking for example of well-known app using unsalted hashes Does anyone know of a well-known application that still uses unsalted hashes for password storage?  I'm looking for an example for an upcoming lecture on Rainbow Tables, and I think it would add weight to the discussion if I had a real-world example that the students had perhaps heard of.

Amazingly enough, MYSQL is a great current example.  The recent hack of Oracle's mysql.com site (Irony: MySQL and Sun websites hacked using SQL injection - TNW Industry) exposed a bunch of unsalted hashes for important accounts, with high quality passwords like "qa" for three accounts (qa_r, qa_rw, and qa_adm), all of which hashed to "077f61a849269b62".  They could be easily searched for on rainbow table sites like Passwords recovery - MD5, SHA1, MySQL.

Even the "new, improved" algorithm used since MYSQL 4.1.1 is simply an unsalted double application of the now-deprecated SHA-1 algorithm.  See Simulating MySql's password() encryption using .NET or MS SQL - Stack Overflow.  In the documentation for PASSWORD() they say you should not use it in your own applications.  But the advice they give is terrible and they offer no excuse for why they don't simply migrate to a good algorithm with not only salts but also adaptive hashing like bcrypt or PBKDF2.  Note that if you don't use an adaptive technique to iterate the hash, each salted hash is very vulnerable these days to fast cheap brute force attacks that can try billions of candidate passwords a second.

Update: A jaw-dropping example of a huge unsalted database for passwords (with hints!) is Adobe's set of 130 million, stored using reversible encryption (3DES), which was exposed in October 2013.  And of course the fact that they encrypted rather than hashing is terrible also.  See How an epic blunder by Adobe could strengthen hand of password crackers | Ars Technica.  It's a database, presumably not an available application, which illustrates again why you shouldn't roll-your-own like this in the security world.

It was the subject of the XKCD comic "Encryptic": 1286: Encryptic - explain xkcd


SHA256 instead of Rfc2898DeriveBytes Is it enough to use this method with SHA256 or it is better to use Rfc2898DeriveBytes (which orginally uses SHA1)?

    public static byte[] ComputeHash(byte[] data, byte[] salt, int iterations)
    {
        if (data == null)
            throw new ArgumentNullException(nameof(data));

        if (salt == null)
            throw new ArgumentNullException(nameof(salt));

        if (iterations <= 0)
            throw new ArgumentOutOfRangeException(nameof(iterations));

        using (SHA256CryptoServiceProvider provider = new SHA256CryptoServiceProvider())
        {
            byte[] output = provider.ComputeHash(data.Concat(salt).ToArray());

            for (int iteration = 1; iteration < iterations; iteration++)
            {
                output = provider.ComputeHash(output.Concat(data).Concat(salt).ToArray());
            }
            return output;
        }
    }

Can above code be used instead of Rfc2898DeriveBytes from point of view of security? Will hashes have more or less entropy? Will it have more or less complexity (CPU/GPU/ASIC time) if I will use significantly big iterations parameter?

Use the known, trusted algorithm over one that you've made yourself.**

I can't speak for the entropy, but of course it will take more time if you have a sufficiently large number of iterations. It's just a matter of finding that number. That being said, I personally would not use your SHA256-based code.

As has been said in what is probably my favourite answer on security.SE: Complexity is bad. Homemade is bad. New is bad. From that same answer, Rfc2898DeriveBytes is PBKDF2, and PBKDF2:

Has been specified for a long time, seems unscathed for now.
Is already implemented in various framework (e.g. it is provided with .NET).
Highly configurable (although some implementations do not let you choose the hash function, e.g. the one in .NET is for SHA-1 only).
Received NIST blessings (modulo the difference between hashing and key derivation; see later on).

Why would you want to write your own - potentially buggy, potentially vulnerable, definitely unnecessary - crypto code when there is already code written for you that has been tested, attacked, and demonstrated to be good?

Further reading:

Thomas Pornin's fantastic post about password storage
A GitHub repo containing wrapper code for Rfc2898DeriveBytes
A codereview.SE post about the GitHub code


What is the danger of hosting your SSL certificate yourself? I have Active Directory Certificate Services on my server, which makes it possible for me to deliver an SSL certificate for the websites hosted on the same server.

I know that normally, I need to acquire a certificate from a known certification authority. But I have my reasons¹ for not doing it. That's not the point.

The question is, what could be (if any) the security risk of hosting the certificate yourself, instead of using the services of a known authority?

¹ The reasons being that (1) I'm a geek and it's fun to create your own certificates, that (2) I want to test Certificate Services, and that (3) I don't care about browsers complaining about the fact that they don't know about me, because I will be the only one to use HTTPS.

Using an SSL certificate for your websites primarily gets you two things:

Identity proofing that your website is who it says it is
Stream encryption of the data between the webserver and the client

By doing what you propose, which is normally called self-signing, prevents you from relying on the identity proofing. By using a known trusted CA the client can follow the signature chain from the certificate you present up to a root level trusted CA and gain some confidence that you are who you say you are. (It should be noted that this trust is really more like faith as CA compromises do occur and some CAs take proofing much more seriously than others.)

You will, however, still have the data encryption. So if you don't need the trust aspect, then you should be fine. Personally, I have several web sites and webapps at home that I use self-signed certificates for. Since I'm the only user, I can reasonably verify the certificate manually without the need for a 3rd party to tell me that the computer under my own desk is really the computer under my desk.


What is a Warrant Canary? While browsing VeraCrypt's website I found its warrant canary. I tried to understand what it is and what its purpose was by reading corresponding Wikipedia article. To be honest I find it quite confusing.

Can someone explain what a warrant canary is in a bit less complicated way than Wikipedia does?

Governments may issue secret government subpoenas to communication providers that force them to disclose private data about their users or insert backdoors into their products.  Furthermore, governments may give criminal penalties to an organization that chooses to publicly disclose if a subpoena was issued.

Some tech organizations attempt to get around this by regularly issuing "we have never been issued any such government subpoenas" while signing their messages with their private key.  This message is called a warrant canary, with an analogy to a canary in a coal mine.  (If the mine begins to fill up with poisonous gases, the small canary will feel its effects before humans and serves as a warning to everyone to get out of the coal mine).  If the government issues a subpoena to them, they promise they will stop issuing the cryptographically signed message stating "we have never been issued any secret gov't subpoenas".  While the law allows the gov't to penalize them for disclosing information about a secret subpoena, there is (currently) no law that would require them to continue issuing such warrant canaries.

Granted, it's feasible for a gov't court to secretly force an organization to give up their private keys that were used to sign their warrant canary, or require them to continue publishing their warrant canaries or suffer severe consequences; whether this happens in practice is not publicly known.  It's also possible that the people issuing the warrant canary are not trustworthy people and would voluntarily continue to issue them, even while complying with government subpoenas.

For more information check out these links from the comments:

https://www.yalelawjournal.org/forum/warrant-canaries-and-disclosure-by-design
https://law.stackexchange.com/questions/268/what-is-the-legal-status-of-warrant-canaries


Security of a website - shared hosting If I host my website in a shared hosting, then do i need to worry about how much secure other websites are which are hosted in the same server?

My website developer is saying so and he is advising me to go for dedicated server as security is a major concern.

Please advise.

It would be worthwhile to consider a single-tenancy server. By default, most providers will give you a multi-tenant server (which can be vulnerable, albeit difficult). Most multi-tenant servers are virtualized at the operating-system level, so you cannot see other user directories, as the operating system is totally independent of each tenant (e.g. you could be running WinServer 2016, another tenant could be running Debian, and another CentOS). In other circumstances (less desirable), you're all on the same operating system, just separated by a chroot (or similar). In this case, a compromised server can affect hundreds of websites.

TL;DR: It depends on your hosting plan. If you have an entire operating system to yourself, you're more secure than just sharing the same OS and being separated by software. The most secure option is to have a dedicated server.

Realize that a dedicated server will cost a significant amount more than your typical hosting. Most of the time this requirement is seen for HIPAA or SOX regulations.


WLCTL protocol detected by sniffer in an Android tablet I detected that my rooted Android tablet had a slow connection. Trying to find what is taking the bandwith, I installed a firewall (DroidWall) and I blocked all the applications thinking that one of them was doing it.

The weird thing was that my tablet still making connections to somewhere. So, I used an sniffer application (Wi.cap) to check it and yes, I found them. A few of them were ARP, ICMP and DNS connections. No problem with them. Nevertheless, I found a LOT of connections about a "WLCTL" protocol with 1 or 2KB of data. The source and the destination were MAC address. The destination is my tablet (I checked it), but I don't know what is that source that begins with "7A". Even, the source and the destination have the SAME address, except for the FIRST byte. (source begins with "7A" and destination, my tablet, begins with "78")

I tried to find more information, but I didn't find anything. I'm stuck, so this is my question:

How can I find what process/application is doing these connections?

I think that, knowing this, I can fix the problem...

WLCTL (Web Listener Control) Utility is a UNIX utility, so I would recommend getting some sort of terminal emulator app and run the command "top" or "htop" to display the running processes, once you sort through the necessary normal processes and isolate the one that is sending out these packets, you can run the command "pidof [process name] " without the brackets and apostrophes and the output should be a number which uniquely identifies the process. From here its a simple command "kill [process id number]" again without the brackets or apostrophes.


Is it illegal to publicly reveal security flaws in a service? Mainly I'm interested in UK law on this, but I welcome input from any jurisdiction.

I discovered flaws in a service that undermined the security of all its user's data. This is a service where users are billed for usage. The flaw, if exploited would allow hackers to make charges to user's accounts.

I disclosed this flaw responsibly to the site owner. The site owner thanked me but played down the seriousness of the flaw, like "oh sure, you could do that, but it's never happened before". The site owner has shown no intention of fixing this, in fact the most recent update has introduced another similar flaw.

This flaw comes ultimately from a lack of knowledge on a developer's part, I want to publish this incident on my blog with details of how to not do the same thing in order to educate others.

Could I be breaking the law by doing that?

If you wish to educate other people on how to secure their site more effectively, i can see no harm in that as long as you do not mention the vulnerable site at all or even hint at it.

A number of sites detail how to perform exploits and how to secure yourself, but they never encourage users to do anything illegal or post targets because that's what gets the police involved.

If you still want to post it on a blog, i strongly suggest you see a lawyer.


Is there greater risk to browsing websites with invalid certificates than websites with no certificate at all? The information security community is generally very adamant that users should not proceed to visit websites that have invalid SSL certificates. Web browsers have gotten less and less cooperative with users who want to ignore these warnings. However, I regularly browse websites that don't have any SSL certificate at all.

I see that an invalid certificate is some indication that there might be an active attacker, but for all you know, there could also be an active attacker targeting you when browsing cleartext http, but you would not get any warning about it.

Do I expose myself to greater risk by browsing sites with invalid certificates than sites with no certificate at all?

Yes, sites with invalid certificates do expose you to more risk than regular HTTP sites with no certificate, though only slightly more.

In terms of the security of the connection itself your intuition is correct; a site with an invalid certificate is no worse than a plain HTTP site. In fact, in the (rather uncommon) case where an attacker is capable of passively observing your connection but not of modifying it, an HTTPS site with an invalid certificate is actually just as good as one with a valid certificate. Against active man-in-the-middle attackers however, HTTPS connections using an invalid certificate aren't much better than plain HTTP.

The security of the connection itself isn't the only consideration here though. There are other important differences between visiting a plaintext HTTP site and an HTTPS site with an invalid certificate which may make the latter scenario somewhat more risky.

For one, sites which use HTTPS connections may be more likely to transfer sensitive information over that connection. Cookies marked with the "Secure" flag, for example, will not be transmitted over unencrypted HTTP connections, but will be transmitted over HTTPS connections with an invalid certificate if you bypass the security warning. This means that if you logged into a site previously when it was using a valid certificate, then came back to it later and it's using an invalid certificate, bypassing the security warning could instantly give an attacker access to your account.

Additionally, some of the more powerful features of the web are, for security reasons, only available on sites which use HTTPS. If you bypass the security warning for an HTTPS site with an invalid certificate, you could be giving an attacker access to these features.

For example an attacker might install a Service Worker for the site you're accessing, allowing them to control your future communications with that site even if you later go back to accessing the site over a secure connection with a valid certificate. Or if you previously granted that site access to the Geolocation API, an attacker would be able to use that access to monitor your GPS location. For a full list of APIs that are only accessible on HTTPS pages, see the Features restricted to secure contexts page on MDN.

Overall though, these additional risks are relatively minor compared to the risks that using an insecure connection in the first place already exposes you to. You should exercise caution when browsing plain HTTP sites, just as you would when accessing a site after bypassing a security warning, as both of those scenarios are quite risky.


Question about authentication cookies? Say, I have a website where users are required to login to access certain functionality. Once they are logged in, they are issued an authentication cookie. Some of the pages on the authenticated portion of the website use a secure connection, while others do not.

Is it possible for a man in the middle attack to steal the authentication cookie, if the user hits a page that does not use a secure connection?

Basically - should one always use a secure connection when accessing any part of a website that requires an authentication cookie?

A "man in the middle", by definition, sees all traffic between the two victims (client and server) and can alter it at will. SSL (HTTPS) defeats MitM, subject to the usual caveats (the client must not trust a rogue CA, the human user must not click through the browser warnings about an invalid server certificate). If a site is HTTPS-only, then the MitM cannot do anything. If the site is HTTP-only, then the MitM can fake and forge and alter and inspect data at will. If the site is partly HTTPS, then the attacker can play with the non-HTTPS parts.

A cookie value is a value sent by the server, stored on the client, and the client sends it back to the server whenever it talks to it. If the cookie was marked as "Secure" and "HttpOnly" then the cookie will be safe from the MitM (at least, as long as no browser vulnerability is exploited): the cookie will be sent only through HTTPS, and the browse won't make it otherwise accessible (malicious Javascript, injected on the non-HTTPS parts of the site, will not be able to read the cookie either). Of course, this also means that the server will not receive the cookie as part of non-HTTPS requests.

It is hard to make a mixed HTTP/HTTPS site which resists MitM attackers, because you then need some very clear notions of security boundaries; and the MitM is in good position to do a lot of harm through the non-HTTPS parts of the site. Though the "Secure" and "HttpOnly" flags can keep your cookie values out of reach of the attacker, Web site security is not all about cookies (coookies are a tool, not a goal). It is altogether much simpler and much more secure to "bite the bullet" and go HTTPS site-wide.


Does ciphersuite ECDH / ECDHE need hardware acceleration I have started to read more about ECDH/ECDHE and am wondering if it has the similary issues as RSA - i.e. the processing power required for the decryption of private key is more than of the public key.
If so, then are there are hardware accelerators available for these ciphers. I did not find them by a google search and so posting this here.
Thanks for any inputs

You do not "decrypt the private key", you "use the private key for decryption".

ECDH is not an asymmetric encryption algorithm but a key exchange algorithm. Key exchange algorithms are like asymmetric encryption algorithms in which you do not get to choose the message which is encrypted -- but that's just as fine when you just want to establish a shared secret value, to be used for symmetric encryption, as is the case in SSL/TLS.

In ECDH, each involved party will compute two equivalent operations, which, on elliptic curves is the multiplication of a curve point by an integer. A simple PC, using a single core, has enough computing power to do that more than ten thousand times per second with the standard P-256 curve (which is as robust as you can hope for). This hardly mandates the use of an hardware accelerator: in HTTPS, such an operation will occur only once per client, when the client opens its first connection. Each connection will be used for several HTTP request, and extra connection will use the "abbreviated handshake" which use symmetric cryptography only.

You might want to do the ECDH and similar operations in some specific hardware, not for performance, but for security: private keys are sensitive objects, they are best kept in tamper resistant devices which will protect them from theft, even against local attackers. Such devices are known as Hardware Security Modules. When a HSM is used, the private key never leaves the HSM, and the HSM does the cryptographic operation. Some HSM support elliptic curves, e.g. recent Thales' nShield HSM.


Using a Cryptovariable with an API Designed for Human-Generated Passwords I'm working with a vendor who provides an API with a user registration method clearly designed for human-generated passwords.  We're calling the API in an offline server-to-server fashion, however, and registering with the API on behalf of our user.

I'm relatively comfortable with the idea of generating our own cryptovariable, in lieu of either re-using the user's password or forcing the user to generate their own second password for the API.  Either way, due to the design of the API, we're going to be forced to store the password/cryptovariable, which will additionally be encrypted both at rest and on the wire.

The only grief I have is that the API (again, apparently designed for human-generated passwords), has some restrictions on the password format that decrease entropy when using a cryptographic random number generator to generate the 'password' (more accurately a cryptovariable).  I can do the math on them all except for one (and getting the code correct is also pretty reasonable).

The most cryptovariable-unfriendly of the 'password' rules is that there can be no repeating sequences of characters in the password.  In other words (and not accounting for the other password rules the API enforces), 'ab' and 'ba' are OK, but 'aa' and 'bb' are not.  For that specific simple case, assuming fixed-length of two and only the two symbols 'a' and 'b', I can see that restriction exactly halves the entropy, and I can also see that it's better as the length increases.  In my case I would just double the length and call it a day, except there's also a maximum password length restriction (doh!).

So enough background -- my concise question is:

What is the entropy of a randomly generated, fixed-length 48-symbol long cryptovariable consisting of 64 symbols (A-Z, a-z, 0-9, + and /), where any combinations with any repeating sequences of symbols are excluded?

As a matter of personal edification, I would also like to know not just what the answer is in this specific case, but I would also like to understand how to determine the entropy for the 'non-repeating' conditions for various lengths and symbol sets.  Seems like this might even be an exercise in a cryptography textbook, and would love a reference.

And, now that I'm ready to admit I've spent WAY more time on this already than I'd ever hoped, I'm also wondering:

Am I just being paranoid?

Specifically, since passwords that follow these rules are theoretically "secure enough" from brute force attacks that the remaining entropy is "enough", can I, in good conscience, just trust that the API is plenty "good enough", call it a day, and go have a beer?

-- Tim

p.s.  I should also note I'm open to other out-of-the-box solutions to the problem at hand as well, but have already ruled out storing the user's human-generated password locally and prompting the user interactively when we need to pass it through to the API.

Reusing the user's password would force us to store the user's actual personal password locally, rather than use the much more appropriate industry standard practice of storing a one-way hash of the password -- so we very definately don't want to do that.

Forcing user interaction to generate a second password is both a bad user experience in general, and practically guarantees a high degree of password reuse by many users, so we don't want to do that, either.  Further, and more critically, we're accessing the API mostly offline.  Despite the heartburn this particular problem is giving me, offline use is fully supported by the API per the documentation.  In any case, since we're accessing the API offline, we don't actually have an opportunity to request the user enter the password -- so we can't do that, either.

Computing entropy for a randomly chosen password can be broken down to a simple rule that can be used in virtually all cases, with some caveats.  It's the log2() of the password character set space raised to the power of the password length.  So, with a completely random password where all characters are independent, this is an easy calculation.  E.G., For a password that is 8 characters long and composed only of uppercase English letters, it is: log2(26^8) or ~37.6 bits of entropy.  Another slightly more verbose way to express this is: log2(26*26*26*26*26*26*26*26).  If we were to add a constraint to our password, perhaps it must be four uppercase characters and then two digits, a randomly generated password will have log2(26*26*26*26*10*10) bits of entropy.  (~25.4 bits)

So, in a more complex case like yours, you have to determine how many characters are available for each successive position in order to determine the password space and thus, the entropy.  The condition prohibiting repetition means that you cannot actually know before hand the entropy of a specific password, because the character set to chose from will be constrained by characters already chosen...So you can only calculate the minimum entropy should the characters randomly chosen maximally constrain the character space for later characters.  I don't actually want to work out this specific calculation but generally, to prevent any repetitive sequences, you need only limit the character space by the last character chosen (so you don't get bb) and if there are any previous incidents of the previous character, the characters that follow those incidents.  (So if to this point the password is abcdbeb, you would need to exclude b, c, and e from the character space for the next character.)  As you can see, this means that as the password grows in length, the available character space is not only going to shrink, but its size will only be known after the previously chosen characters have been examined.

So, the super simple method to determine minimum entropy with a maximum margin of error I mentioned in the comment is to simply exclude each character as it is used.  With no possibility of a character being used twice, there is no possiblity of a repeating sequence.  With a character space starting with 64 characters, and a password that is 48 characters long, this is log2(64*63*62*...*16) which is a massive ~249.7 bits of entropy.  So, since we know that given your specific constraints, the entropy of your passwords will be higher, you have a huge safely margin, and there's no realistic chance of a successful brute force attack.

As an aside, if you had no constraints, and randomly chose 48 character passwords from a set of 64 characters, you would have had 288 bits of entropy.


Security Implications of PHPCSS Files ( Dynamic CSS using PHP ) I'm working on an website where I need to allow the user to change multiple CSS values in their CMS. I need to read these values back to the browser in CSS and ran across an "easy" way to do just that - create a PHP file but send the header content type as text/css as seen below:

<?php
    header( "Content-type: text/css; charset: UTF-8" );

    $body_bgcolor = get_option( 'background_color' );
    /* ... Additional Settings ... */
?>

body    {background-color: <?php echo $body_bgcolor; ?>}

This allows me to send the above to the browser using:

<link rel="stylesheet" href="http://domain.com/globals/customizations.php" type="text/css" />

All the above works fine and there may be some performance drawbacks but I'm more concerned about any security holes this may create. When discussing this with colleagues they talked vaguely about how insecure the above method was. I've tried searching on this subject but I haven't found anything specifically discussing the security implications of doing the above.

Would applying the above be insecure in some way?

I have been doing exactly this for many years on several websites.

This is no more and no less secure than using PHP to build an HTML page.

Make sure you sanitize/validate any user-provided inputs (as you would do for handling user input on a regular web page), and there's no reason not to do what you are doing.


Detect a Virtual Machine on my Wifi? Is there a way to detect whether a machine connected to my wifi is a physical machine or a virtual machine?

Maybe you can look at their MAC address. For example, by default, VirtualBox begins theirs MAC address by 08002xxxx.

The lists of couple address MAC - constructors
https://support.microsoft.com/fr-fr/kb/461260


TrustWave PCI Compliance - OpenSSH First time 'asker' on here, but wanted to say thanks to how much I've used this site and reading answers to questions I've had!

Anyway, lately I've been having issues with a customer of ours who's server is failing the PCI Compliance scan from Trustwave. The problem in particular is with OpenSSH being vulnerable and needing to update to the latest 4.4. However according to the CVE numbers they provided, it looks like the version the server is running has been patched. I could be reading it wrong, but from what I can tell there isn't a problem.

This is what the initial report said:

Port: tcp/xxxx
OpenSSH prior to version 4.4 is affected by multiple vulnerabilities
that may allow for a remote attacker to execute arbitrary code on
the affected device.
This finding is based on version information which may not have
been updated by previously installed patches (e.g., Red Hat "back
ports"). Please submit a "Patched Service" dispute in TrustKeeper
if this vulnerability has already been patched.
CVE:
NVD:
Bugtraq:
CVSSv2:
Service:
CVE-2006-5051, CVE-2006-5052
CVE-2006-5051, CVE-2006-5052
20241, 20245
AV:N/AC:M/Au:N/C:C/I:C/A:C
ssh
Evidence:
Match: '4.3' is less than '4.4'
Remediation: This issue was fixed in OpenSSH version 4.4. Upgrade to a
recent/stable version
Patches:
http://www.openssh.com/

So we filed a dispute with the following information from our server:

[root@host ~]# rpm -q centos-release
centos-release-5-10.el5.centos

[root@host ~]# rpm -qa | grep -i ssh
openssh-4.3p2-82.el5
openssh-clients-4.3p2-82.el5
openssh-server-4.3p2-82.el5

And all they responded with was this:

We have denied this dispute based on the information provided. The
information provided does not appear to be related to the vulnerability that
this finding is regarding.

According to the CVE database links below, aren't we running a patched version of OpenSSH?

https://access.redhat.com/security/cve/CVE-2006-5051

https://access.redhat.com/security/cve/CVE-2006-5052

If not, where am I getting turned around at? Thanks for your time and any input would be greatly appreciated!

EDIT:

I ended up submitting the following, which apparently was good enough for Trustwave to believe me when I told them our releases had been backported.

# rpm -q --changelog openssh-server-4.3p2-82.el5 | grep "CVE-2007-4752"
- CVE-2007-4752 - Prevent ssh(1) from using a trusted X11 cookie if creation of an

# rpm -q --changelog openssh-server-4.3p2-82.el5 | grep "CVE-2006-5794"
- CVE-2006-5794 - properly detect failed key verify in monitor (#214642)

# rpm -q --changelog openssh-server-4.3p2-82.el5 | grep "CVE-2006-5051"
- CVE-2006-5051 - don't call cleanups from signal handler (#208459)

# rpm -q --changelog openssh-server-4.3p2-82.el5 | grep "CVE-2006-5052"
- fix an information leak in Kerberos password authentication (CVE-2006-5052)

CVE-2008-1483: This has also been patched in Red Hat/CentOS releases (https://access.redhat.com/security/cve/CVE-2008-1483). To be sure, we have disabled X11 forwarding in SSH as it shouldn't be needed anyway.

Without checking, I'm going to assume that your CentOS RPMs contain backported fixes which address the CVE's listed in their report.  (That's how RedHat does it and CentOS is RedHat in this regard).  Because of this, your packages are probably immune to issues that their banner would otherwise indicate they're vulnerable to.

What you need to provide Trustwave with is the version you're running (which you've done) but also the evidence that this version contains fixes for the CVE IDs they think you're vulnerable to.  If you go to the RedHat CVE database it will tell you which versions include the patches for a given CVE, just collect those links and submit them to Trustwave.


HMACs that have the same key and message im using HMACSHA256 to generate the hash of password and store it.
the objective here is to just authenticate users, i.e - save their hashed passwords, and validate users whenever needed using the hashed passwords

// salt is a guid we store seperately, its the id of the user
byte[] GetHash(byte[] password, byte[] salt)
{
    byte[] saltAndPassword = salt.Concat(password).ToArray();

    var hmac = HMACSHA256();
    hmac.Key = password;
    var hash = hmac.ComputeHash(saltAndPassword);
    return hash;
}

notice that the key is password, and the hash is generated on salt+password

can we have the password as the key to hash the salt+password, will that comprise security?
when using HMACSHA256, do we necessarily have to have a key management inorder to use seperate keys rather than passwords?

also, do keys have to be unique in HMACSHA256?

i know that people often suggest slow functions like - PBKDF2, Scrypt etc..

but is using HMACSHA256 safe too?
do people actually use a hmac for hashing and storing passwords?
what would be the recommended approach for hashing and storing passwords(if all you have is passwords and unique salts)?

apologies for the parade of questions :)
thank you in advance

Edit

I couldnt find a way to comment on neither the question or answer(stackexchange requires me to have a 50 rep). so im posting my comment here :

@CodesInChaos hi, thank you for your answer.

  HMAC(password, salt + password)

  This is silly but harmless. 1) It uses a variable length value as key.
  HMAC has some >weird properties when doing that. 2) Why input the
  password twice?

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting??

but from what i see from your answer, HMACSHA256 does similar thing using the key supplied?

  If you use HMAC for hashing passwords, I'd use the password as message
  and the salt as >key. This matches HKDF-Extract.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?.

I know that people often suggest slow functions like - PBKDF2, Scrypt etc..

Listen to them. Use scrypt, bcrypt or PBKDF2. These functions are designed for hashing password. See How to securely hash passwords? for details. This is the recommended approach to hashing passwords.

but is using HMACSHA256 safe too?

It's fast => brute-force is cheaper => it's weaker than a slow hash.
A fast hash is only acceptable if you know that only strong passwords (say 80+ bits of entropy) will be used. In practice this means that you don't allow user chosen passwords and generate them using a computer. At this point they're closer to keys than to typical passwords.

do keys have to be unique in HMACSHA256?

When used as a MAC, keys don't need to be unique. You're using it as a password hash, so there is no secret key. Salts should be unique to prevent multi target attacks, but occasional collisions don't hurt much.

// salt is a guid we store separately, it's the id of the user

This means that the salt will be reused when the user changes their password. Not ideal, but not a big deal either.

HMAC(password, salt + password)

This is silly but harmless. 1) It uses a variable length value as key. HMAC has some weird properties when doing that. 2) Why input the password twice?
If you use HMAC(salt, password) for hashing passwords, I'd use the password as message and the salt as key. This matches HKDF-Extract.

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

If you use the salt as key and the password as message, the key has fixed length. But since these properties don't have much practical impact, don't worry too much if it's variable length either.

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting?
but from what I see from your answer, HMACSHA256 does similar thing using the key supplied?

Since HMAC already combines key and message, you don't need to include the password in both.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?

Yes, using a public salt as key input to HMAC is fine. You need to make stronger assumptions about HMAC than "It's a PRF", but that's fine.


How can a client verify that code sent from the server has not been tampered with? While trying to understand the recent controversy involving ProtonMail, I started to wonder if its possible to verify that the opensource JavaScript being sent from the server to the client hasn't been tampered with.

If I understand correctly, you cannot use E2EE in the browser because technically if the server was compromised the server could send malicious JavaScipt to the client and respond with the client's secret encryption key/password.

If I am a developer, how could I ensure that my client is receiving the same JavaScript that is stored in my public GitHub repo? Is this even possible?

Generally speaking, I think what you are asking is impossible, or rather, it's unfeasible and probably not useful. The reason why it's unfeasible is that you would have to check that the code is the same as the official code (for example on GitHub), and you would have to do this every time you reload the page. The reason why it's probably not useful is that to be sure that a web page actually behaves correctly, you would have to audit all its code, every time. Even if the page really loaded the official code for a specific library, how do you know if the page then actually uses that code as expected? It might load the code but not execute it, or it could redefine some functions before using them, etc. And even if you audited all the code and you were sure everything is working fine, the next time you reload the page all this could have been changed.

When you download software from GitHub, you are ultimately trusting the provider of that code, that is, GitHub. When you install software from a Linux repository, you are trusting the repository servers. And when you execute software on a web page (javascript), you are basically trusting the domain owner.


What kind of TLS certificate should I use for an internal system? I have a system which is not connected to the public network. This system is used to open doors inside a building. It spans a open Wifi network where users can open a specific website and enter credentials to open the doors. A TLS certificate is used to secure the connection between the website and the browser. I have no control over endend user machines. Most probably they connect with Android devices (some also have iPhones or normal PCs). Now the old certificate expires and I'm thinking what the best future-proof solution could be:

Certificate from Startcom CA: This is the existing solution we had. However several browsers don't trust this CA anymore. So I'd expect that several users won't get easy access to the website.
Certificate from Let's Encrypt CA: This would require someone to retrieve the certificate, physically go to the hardware and change the certificate. This seems very error-prone. It quite some effort to do this and I expect that people forget this.
Certificate from CAcert CA: This could be one possible solution. Here we would have to teach users how to import the CAcert root certificate and this would work.
Buying a certificate from a CA: This is also a possible solution, but the organisation is quite small and can't effort to pay this amounts of money to get a certificate.
Making a self-signed certificate: This is also doable, but I don't know how browsers will handle those kinds of certificates in the future.

So what is your recommendation? What kind of certificate would you recommend and what is the best in terms of user experience?

Self-signed certificates should not be used directly in TLS, but there is nothing wrong in building a private CA. You just provide the root certificate to all internal clients and all will work fine exactly like it would with paid certificates. The only difference is that well known root certificates are pre-loaded in browsers whereas you will have to distribute yours.

openssl contains all what is needed for a CA, but your could try easier interfaces like xca


CIS recommendations - disabling ip forwarding I am looking through the CIS recommendations for debian 8.

In a CIS compliance test using nessus, I see that the test for disabling ip forwarding has failed. But when I look at the system, I can see that it is in fact disabled.

$ cat /proc/net/ipv4/ip_forward
0

It seems like the CIS recommendation is to explicitly disable ip forwarding. But as far as I can tell, if you do not enable ip_forwarding explicitly, it will remain disabled.

Is there a bigger reason to do what the recommendation says, other than to make sure the default parameter is set?

For reference, I added the chapter for ip_forwarding below:

7.1.1 Disable IP Forwarding (Scored)

Profile Applicability:

Level 1

Description:
The net.ipv4.ip_forward flag is used to tell the server whether it can forward packets or
not. If the server is not to be used as a router, set the flag to 0.

Rationale:
Setting the flag to 0 ensures that a server with multiple interfaces (for example, a hard
proxy), will never be able to forward packets, and therefore, never serve as a router.

Audit:

Perform the following to determine if net.ipv4.ip_forward is enabled on the system.

  # /sbin/sysctl net.ipv4.ip_forward

  net.ipv4.ip_forward = 0

Remediation:

Set the net.ipv4.ip_forward parameter to 0 in /etc/sysctl.conf:

net.ipv4.ip_forward=0

Modify active kernel parameters to match:

  # /sbin/sysctl -w net.ipv4.ip_forward=0

  # /sbin/sysctl -w net.ipv4.route.flush=1

Is there a bigger reason to do what the recommendation says, other
  than to make sure the default parameter is set?

Similar to configuring firewall ACLs, the best practice is to explicitly configure the settings you want and not rely on the default (which may be different from device to device. For example, ACLs should end in deny all and log.

There are many reasons for being explicit in your configurations:

Not all systems have the same default value
Setting the desired value explicitly aids in accountability
Audit Requirements


Can I get malware from a .rar file without opening it in Android? I was on a group with almost 200k people on it in Telegram. One of these members (probably new, his account is now deleted) sent me (and to other people too) a file named "Customer deposit H.rar", I proceeded immediately to delete it and analyze my Android 9.0 phone with Kasperky Free.
What are the possibilities that I'm infected if I didn't open the file (I didn't analyze the file, I'm assuming this has malware on it)?
In other words, and as the title says, can I get malware from a .rar file without opening it in Android?
I found another question about this but always refers to Windows.

Unless there's a vulnerability in File Explorer's archive manager, it's harmless. Even if a malware compromises File Explorer, it cannot break out of app-sandbox without another vulnerability. Simply uninstalling the app removes the malware.
To compromise system, an embedded malware needs chain of critical vulnerabilities and even then there's no assurity that the exploit will run because SELinux blocks process execution that violates SELinux policy. You can verify that your system hasn't been tampered with by simply rebooting your device. Tampered image bricks the device on boot because of Android Verified Boot.


Hashing passwords before inserting into database For the last 2 weeks I have been reading many blogs about website security and hashing passwords.

Many sites have mentioned the pro's and cons about different ways of doing this, which has left me a bit confused about how secure my code is.

If possible, can anyone have a look at the code below and let me know what they think. I have posted this question on https://codereview.stackexchange.com/questions/30814/hashing-passwords-for-website-is-this-secure but as off yet, no one has replied.

The steps I have took are as follows:

Create random salt
Add random salt and email together to create salt for password (email will be encrypted in database)
Hash password and salt and store in database

public const int HashBytes = 128;
public const int DefaultIterations = 10000;

    //Create random bytes for salt
    public static string SaltSHA256()
    {
        const int minSaltSize = 8;
        const int maxSaltSize = 16;
        var random = new Random();
        int saltSize = random.Next(minSaltSize, maxSaltSize);
        byte[] saltBytes = new byte[saltSize];
        var rng = new RNGCryptoServiceProvider();
        rng.GetNonZeroBytes(saltBytes);
        HashAlgorithm hash = new SHA256Managed();
        byte[] bytes = hash.ComputeHash(saltBytes);
        return Convert.ToBase64String(bytes);
    }

    //Create salt using email and public static string SaltSHA256()
    //Store email and public static string SaltSHA256() in database
    public static string SaltRfc2898(string email,string hashedSalt)
    {
        var salt = new Rfc2898DeriveBytes(email, Encoding.UTF8.GetBytes(hashedSalt), DefaultIterations);
        return Convert.ToBase64String(salt.GetBytes(HashBytes));
    }

    //Hash password and salt
    public static string PasswordHashRfc2898(string password,string salt)
    {
        var hashedPassword = new Rfc2898DeriveBytes(password, Encoding.UTF8.GetBytes(salt), DefaultIterations);
        return Convert.ToBase64String(hashedPassword.GetBytes(HashBytes));
    }
    //Get salt and password from database based on username
    //Salt in from data created by public static string SaltSHA256()

    public static bool DoPasswordsMatch(string password,string salt)
    {
        //Password would be pulled from db based on username
        byte[] testPassword = Convert.FromBase64String("basestring");

        //Salt would be pulled from database based on username
        var saltFromDatabase = salt;

        //Hash password and salt
        var hashUserInputAndSalt = PasswordHashRfc2898(password, saltFromDatabase);

        //Convert to byte[] ready for comparison
        byte[] convertUserInputFromBase64 = Convert.FromBase64String(hashUserInputAndSalt);

        //Compare and return true or false
        return convertUserInputFromBase64.SequenceEqual(testPassword);

    }

You are using Rfc2898DeriveBytes, which implements PBKDF2: that's good.

You are producing a whooping 128 bytes of output, which is total overkill for password verification. 128 bits, i.e. 16 bytes, are sufficient. 128 bytes don't harm, except that they make for bulkier strings to store in your database.

You are using 10000 iterations, which might be a bit low. Higher is better. 10000 is not bad, but chances are that your server can handle ten times as many, and this would make attacks ten times harder. I suggest that you try several values, and make the count as high as is tolerable on your system, relatively to the expected workload (namely, the number of connecting users per second).

Encoding issues are best kept separate, at the storage level. The salt, the PBKDF2 output, and the password are all sequences of bytes. Rfc2898DeriveBytes can encode a String password for you, but expects the salt to be "some bytes", and produces an output which is "some bytes". For storage into the database, either use the abilities of that database to process binary data, or apply some encoding, like Base64. So, use Convert.FromBase64String() and Convert.ToBase64String() before writing and after reading, respectively. Your mixture of Base64 and UTF-8 is confusing and makes reading (auditing) your code a harder task.

Your salt generation is weird:

There is no point in making the salt length variable. Just go for 16 bytes.
There is no point in avoiding bytes of value 0. A salt is a sequence of bytes, not of characters, and 0 is not special.
There is no point in hashing the salt.

A proper salt for PBKDF2 is a sequence of at least 8 bytes, and unique (as much as possible). 16 bytes filled with the output of a strong PRNG are a good way to do that. A GUID would also work (salts need not be random, they just need to be reused as rarely as possible by normal systems, and GUID do that). In .NET, if you want to generate a good salt, simply do that:

byte[] salt = Guid.NewGuid().ToByteArray();

Alternatively, Rfc2898DeriveBytes can generate the salt for you. Upon user registration or password change, do this:

Rfc2898DeriveBytes h = new Rfc2898DeriveBytes(password, saltSize, iterations);
byte[] hashedPassword = h.GetBytes(hashSize);
byte[] salt = h.Salt;
// then store salt and hashedPassword in the database

and, upon verification:

byte[] salt = ... // read from database
Rfc2898DeriveBytes h = new Rfc2898DeriveBytes(password, salt, iterations);
byte[] hashedPassword = h.GetBytes(hashSize);
// compare hashedPassword with the stored value

You can invoke a separate PRNG like RNGCryptoServiceProvider() and do things yourself; that's what you do, and though it is weird, it is not weak. However, it is simpler to use what the system already provides. Simpler code usually means less bugs.


Deleted files and their traces Lets say we delete various files , from hard disk  A, with shift - delete , windows 8 . Then we copy new files to the same hard disk A. Then those new files we just copied there to hard disk A, we copy to a USB stick , or to a DVD.
Those new copied files are now laying to a total different hard disk drive B . Is there anyway , those new copied files that came from the hard disk A , but now laying in the different hard disk B , to include any traces of the previous deleted files from hard disk A , so that recovery software be able to recover , if we run the recovery software from the hard disk B ?
I only used normal windows explorer copy and paste, for copying the files.

It depends on how you copy them.

If you do a bitwise copy, aka exactly replicating every single bit from one disk to the other, you are copying over "slack space" which is where the recovery tool will work.
If you do a file copy, then the empty space of the disk is ignored, and only the segments of data attached to a file header will copy over. The recovery tool cannot see the slack space attached to the other disk.


TLS integration of webapplications Let's say I am a developer/maintainer of an open-source-webapplication distributed via docker.
Any server-admin can install (using docker) and host this webapplication on his server with his own domain.
So the webserver itself is "included" in the docker-image, the user can simply run a container and use the webapplication.
Now I wonder:
What is the best-practice regarding tls-integration of such a  webapplication?
I think about the following options:

The webapplication generates a self-signed-certificate or something similar and provide the webservice as HTTPS. Obviously untrusted by every browser, but maybe a little bit better than not using HTTPS.
The webapplication provide a simple HTTP-server without caring about encryption because it is the server-admin's task to generate and use a certificate for their domain. In this case i would probably force that the server-admin uses something like nginx for example as reverse-proxy which provides a secure connection (using a trusted certificate) for the user.
(Any completely different approach?)

Disclaimer: The scenario described is quite generic in terms of licensing of the said software, therefore I will consider it as open-source, where the provider is not legally bound to how the software is used, nor the consequences of misconfigurations.
A valid approach would be to deliver the application only with HTTP enabled, and also provide the necessary documentation on how to configure HTTPS, leaving the choice and responsibility in the hands of the system administrator.
The company I work for operates in this exact scheme, and it enables the customers to easily run and test the application since HTTPS is not required, whilst properly guiding customers/system administrators on how to configure HTTPS, that is always a requirement for production environments.


plain FTP (no encryption) Person A want to send important excel files to Person B using plain FTP (no encryption). Person A says the "issue with private key encryption is that its tough to maintain across the company. Sharing private keys is not safe." Person B suggests to encrypt the excel file before sending but Person A says its not possible.

Are there any other ways to make this transfer safe or encrypted in transit? All I can think of is SFTP but it may affect the speed of the file transfer.

SFTP is an FTP-like solution that utilizes the SFTP protocol (NOT the same thing as FTP tunneled over SSH Wikipedia:SFTP). You would need sftp-server installed on the server. That would be a secure way to transfer files. It supports compression too, I believe, so possibly it would be faster than FTP?

With the size of Excel files and the speed of modern internet it would likely not be noticeable either way.

Otherwise, if you have SSH enabled I would use scp to copy the files over SSH.


Do client certificates provide protection against MITM? I'm looking for a way to protect clients from a MITM attack without using a VPN, and ToR.  My thought is that client certificates might do the job, but I'm not entirely sure since not too much server or browser support has been extended in this area.

Can anyone tell me if Client Certificates provide any MITM protection?

Is that protection just for the authentication exchange or does it protect the entire TLS session?

Is there any good resource for studying this in deep detail?

A man-in-the-middle attack is when an attacker inserts himself between client and server, and impersonates the client when talking to the server, and impersonates the server when talking to the client. "Impersonation" makes sense only insofar as there is an expected peer identity; you cannot impersonate an anonymous client.

From the point of view of the server, if the client shows a certificate and uses his private key as part of a CertificateVerify message (as described in the SSL/TLS standard, section 7.4.8), and the server validates the client certificate with regards to a set of trust anchors which does not include an hostile or incompetent root CA, then the server has a guarantee that it is talking to the right client (the one identified by the client certificate). The guarantee holds for all subsequent data within the connection (it does NOT extend to data exchanged prior to the handshake where the client showed a certificate, in case that handshake was a "renegotiation").

This means that a client certificate indeed protects against the specific scenario of a rogue CA injected in the client trust store. In that scenario, the "attacker" succeeded in making the client trust a specific root CA that is attacker-controlled, allowing the attacker to run a MitM attack by creating on-the-fly a fake certificate for the target server (this is exactly what happens with some "SSL content filtering" proxies that are deployed in some organizations). Such MitM breaks client certificate authentication, because what the client signs as part of a CertificateVerify message is a hash computed over a lot of data, including the server certificate -- in the MitM scenario, the client does not see the "right" certificate and thus computes a wrong signature, which the server detects.

From the point of view of the client, if a client certificate was requested by the server and shown by the client, then the client knows that the true server will detect any MitM. The client will not detect the MitM itself; and if there is an ongoing MitM attack, then the client is really talking to the attacker, and the attacker will not tell the client "by the way, you are currently being attacked".

In that sense, a client certificate prevents a true MitM (aka "two-sided impersonation") but does not protect against simpler frauds (one-sided impersonation, i.e. fake servers).

Bottom line: In the presence of SSL with mutual client-server authentication (both send a certificate to the other), a successful MitM requires the attacker to plant rogue CA in both the client and the server. However, if the attacker can plant a rogue CA in the client only, the client is still in a rather bad situation (even though a complete MitM is thwarted).


172.16.33.197, 127.0.0.1 IP addresses in visitor logs I have a website running Apache and PHP. I see that there are visitors with IP addresses 172.16.33.197 and 127.0.0.1. These addresses do not belong to our network. I get the visitor IP addresses with following code snippet.

function GetUserIP() {

    if (isset($_SERVER)) {

        if (isset($_SERVER["HTTP_X_FORWARDED_FOR"]))
            return $_SERVER["HTTP_X_FORWARDED_FOR"];

        if (isset($_SERVER["HTTP_CLIENT_IP"]))
            return $_SERVER["HTTP_CLIENT_IP"];

        return $_SERVER["REMOTE_ADDR"];
    }

    if (getenv('HTTP_X_FORWARDED_FOR'))
        return getenv('HTTP_X_FORWARDED_FOR');

    if (getenv('HTTP_CLIENT_IP'))
        return getenv('HTTP_CLIENT_IP');

    return getenv('REMOTE_ADDR');
}

Why can I see that this IP address visiting my website?
Does this indicate a security breach or a problem with my code?

Yes. If the user alters the HTTP_X_FORWARDED_FOR header, or any of the  user-supplied headers you're checking with that code, they can forge the source IP. Ignore those headers and just use the REMOTE_ADDR value.


PenTesting - Configuring vulnerabilities on XP SP 1/2/3 & Server 2008 I've been creating test ranges using VMWare and an isolated network to play around with, and configuring endpoint workstations to be the receiving end of penetration tests.

I've found that the "easy" exploits are ms03_026_dcom and ms08_067_netapi, but of course I want to expand my configuration horizons so I am trying to configure other holes in the workstations.

I've tried configuring IIS Web & FTP servers to be extremely insecure (ended up with IIS 5.1 and 6.0 I believe) but found none of the exploits I tried worked.

Question: What are some good vulnerable services, 3rd party software, or configuration settings I can try that stray from plain old RPC and SMB?

I'd recommend combining a search of Metasploit modules with software from Oldversion as being a good starting point for this kind of research.

You can search Metasploit based on exploit reliability and then see if you can find the appropriate software version on the site.

Another option would be to look at some of the pen test/CTF labs for the kinds of exploits they line up.


Why do public key certificate "Trust anchor"? Does this introduce a single point of failure? When you look at currently used concept of Root CA (primarily in SSL/TLS context), you can see a single-point-of-failure vulnerability, which means, if your private key is disclosed, you automatically lose whole chain.

Current State of Trust Chain topology

Means, you start with one self signed certificate, declared as Root CA Certificate (see http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x160.html ), which then signs other certificates (not necessarily intermediate)

Disclosing private key for Root CA Certificate, will force you to revoke whole chain.

Possible Ring topology

I think about topology, where you have both-way signed certificates, where each CA is signed by at least two others. This could boost some security params of certificates, such as

compromising single CA will not mean revokation of whole chain (compromising CA_1 won't remove whole chain of neither CA_2 or CA_3)
creating fake CA will require you to fake at least two of them, so you can create valid chain

So the questions are:

What led creators of public key certificates to use SPoF vulnerable chain?
Is there anything, I'm missing on ring topology?

I can think of many reasons.
The first one, is economical. Effectively, getting a certification is costly, and the higher you are on the chain, the more expensive it gets. Using, what you propose might theoritically be interesting, but it will cost twice as much to companies (don't forget, CA are economical entities that sell their services, they won't do it for free).
Some studies have pushed your solution further and have proposed even P2P certification, here is one paper that talks about it. However, the problem with distributed certification (in opposition to centralized) is the difficulty to control and establish normes and rules.

Finally, if we look at the solution you propose i can see some inherent problems in it. At least, in the way you present it there is no hierarchy CA-3 is certifiyng CA-1 and vice versa, but clearly one has to be a higher authority and that one can't be certified by a lower authority.


AutoRecon is taking too long to complete AutoRecon is a multi-threaded network reconnaissance tool which
performs automated enumeration of services. It is intended as a
time-saving tool for use in CTFs and other penetration testing
environments (e.g. OSCP).

https://github.com/Tib3rius/AutoRecon
However, I notice that it's taking too long complete. I've tested it on one of my VM a few hours ago and it's not fully completed till now.
It says that There are 2 tasks still running ...
Has anyone using this tool before? Did you experience the same problem?

Yes, I've noticed that it often takes a long time, sometimes just some tools get stuck.
This happens, for example, if the application responds with a redirect to every gobuster request or if it responds to every nikto test. In both cases the scan duration increases dramatically.
You can stop the scan and check in the results/[target]/scans folder which task has not been completed or check the errors file results/[target]/scans/_errors.log to see if something went wrong


Challenge Response with a Tan Book? i am trying to secure a connection between a Mobile Device (Client) using a webApp and a Home Device (Server) in a potentially unsafe Wifi Network.

The communication is asynchronous and i am trying to prevent "replay attacks".

I was thinking about Challenge Response, but the overhead of "ask for challenge, receive challenge, send message with solved challenge" is a performance issue for us.

So i was thinking about using some sort of TAN Book approach like online baking does it:

Initially the Client would ask for a set of Challenges that it stores.
The Server would store those Challenges and keep track of how many are already used.

If only n Challenges are left, the Server creates new Challenges and sends them with the next response to the Client. This way, the Client should almost always have enough Challenges without the overhead of Asking for them first before every request.

Example:

Client wants to log in and asks for challenges first, giving his username/userid.
Server creates n Challenges and stores them for the given userid, then sends them to the user.
Client sends challenge-id and hash(challenge, shared-secret).
Server compares stored challenge (identified by challenge-id) hashed with shared secret and if correct, returns success and deltes challenge since it was now used.

then it gets easier

Client wants to call API Endpoint X on Server, sends request with added Headers (challenge-id, hash(challenge, shared-secret))
Server checks challenge and uppon success deletes it, executes method x and returns response. In response it adds a new challenge in the header (i.e. challenge_id-xyz: 45egrgh3gw43gw43zrezh54egh44zg54b54esb...54sreh5j)

if the client is low on challenges

Client wants to call API Point X, sends Request with Challenge in Header
Server checks Challenge, upon success deletes it, realizes the client is low on challenges (due to low amount of stored challenges) and creates new ones. It sends Response for API Point X and adds new challenges in the headers.

Is there already a concept like this and if not, does this sound to much like "bake your own crypto" or does it sound legit?
Or is there a better way to do this without to much http overhead?

Well in answer to your question as to whether there's a better way to do this, I'm wondering if a slightly simpler solution which I've used previously might be up to the task.

Rather than generating a pre-defined list of challenges and transmitting them, have the client and server each add a predictable incremental value to the hash you pass in the header. Both the client and the server keep count of the number calls/responses for the session and can reject any received with duplicate (re-used) hashes. The incremental value can be as simple as a count, or could be some simple maths function performed on the count if you're feeling particularly paranoid.

It would look something like this:

Client wants to log in and sends a login request with userid &
hash(some sensible combination of shared secret with userid or some
such).
Server examines the hash and if correct, returns success and a
session token.

Now for each call made:

Client calls API endpoint X on server, with added header hash(session-token, incremental value)
Server verifies the hash matches the session-token & the next incremental value expected for this session, if it does it sends the response from the endpoint also signed with hash(session-token, next incremental value).
The client verifies the response header contains a hash of the session token and the next incremental value it was expecting.

and repeat.

If any request/response arrives with a re-used hash in the header, the incremental value will be out of sequence and the client/server can reject it. Also there's no need to worry about generating, transmitting and maintaining a list of challenges for the session.

Downsides here involve problems caused making multiple calls and them getting out of sequence either due to network issues or the design / requirements of the application. Ways around this involve adding a central point to the client to marshal/queue all requests and responses for the session, or alternatively create a separate session for each thread or conversation within the client application. That's extra consideration during development maybe, but if your requirement to keep traffic to a minimum is important enough it might be worth the effort.

Comments and thoughts are very welcome.


Some bot keeps posting this to my server Some bot keeps posting strings like this to my server. What do they mean and what's the best way from preventing them?

RaxfkI/IZARdmslPRT3qzmMmaAmJOQ1i3lJWx9f4jJBQ0fVChoXCF3hlRjvticMkgEQxR7RKxb8uWfcbQa9jRqW8JFfOAykAsg7Nkf6MdScjE0bgyo0757jvOKqamcMA/xicZs_/S26J7PFUu2H/TMrJxwhAoAyvoFYavKcqWRccoZKCKAStUxJ6V8nqaXfIc6PL9dVRxWqSPyEUL7Y212kGO9fET70YOJj0lw/hkHUuRzRBSn/LXRE8RJVSGW5HmsLVbrG9Rp_I/omjALqCtBMZ/spkWrRYRK2uOotRCNLNVdQz23ioYLUB3TIpZc6wCwz6HpZe7hhOzlikAZW22acDDAOicP7/i9jaHvvC5ine85J1D7QAd3Nuz6/ZsaQN4koSktdDoK8evUIvHCTpcCxnI/SaH6fmIhtuRaDsEK4K
EaMIk9rLYLRC5UGCKDcSS2GcXmsKekjiO3OPn79AZ/g67w6ensoQufXWcCJaKFq_GEe7/k3qPwbWDyWd1wY/lgptLoFqn_7EE6vUg0WRX/e9DX3vvlZHB2_kkPDGPw2cIL2c8fbEScsQcePT1gNzcCwATzFUgK7SHN2rv01C6jW2qiLzoVPB53Fb9Go9HfAAKmgOj4NYhKSnK7eQW5_M5q9q_EjqO62pj7ohVofKlog7lvQ0h80uwtYjA0DDPbbkBFWFbik5ZULv_KgVhwnx9IUPVRyzXAi2W5KWExWH8u_Lm2wOaNJZHvXagCPIMO4ThHNfpT_5v9mtUfBQR14D1VRnbVHOIg
Rq1ckN7PZJp1PEjQqFJJjzDLdlC666M1FPfhEGF6cqUER4lAw8aIkJKSUc4VgU1lzfx32AyKmQbbjbrmJCEpAVjfhyunmVj7Adh/uK4WEuiwLiQlNs0qWqjtEAJg4b7sAAuODrzS48FtO975UIUlsT85Wj9uzknsqH9M1k0WrCgg7ngkAlcJmlKryDzMtxdQ8RJR75wU77ADuD8tB1Op1Yby2V/Cb4fgH3KQTmU_qSXUNgH5BHXCY_MRSCwbGQVvzsgGwqbcjboZmtACFc850IgPg1Yx9yuLxJfsciGRTUy8B/6QSZjfRGC0ujFOMJ6OUVE2f/owbx6GJKp_ULiIPE42rFEdA6Y5jtoCLMxhT_qzYUaUOcv9WmMwYMkpC9oWHe8SYieEYQ

I've got over 2400 requests like this. They're all posted to my server's IP, not the domain name.

My server keeps throwing a MethodNotAllowedHttpException which is caught by my error handler, which is how I know this keeps happening. I don't think it's causing any harm but if they're eating my server resources, I'd like to prevent that.

One possible way to prevent uploads and attacks as you have described and many more is to install apache mod_security with OWASP ModSecurity CRS rules.

They can also be applied to ngnix, and it will most likely protect you from:

SQL Injection (SQLi)
Cross Site Scripting (XSS)
Local File Inclusion
(LFI)
Remote File Inclusion (RFI)
Remote Code Execution (RCE)
PHP
Code Injection
HTTP Protocol Violations
Shellshock Session Fixation
Scanner Detection
Metadata/Error Leakages
Project Honey Pot Blacklist
GeoIP Country Blocking

If you servers are not running on apache, you can however have it server as reverse proxy, and protect your web-application.

Once you have mod_security enabled and configured, you can go further and install and configure fail2ban to ban IP's trying to hack you like this:

Install fail2ban as per your system (yum install or apt install fail2ban...)
Create /etc/fail2ban/filter.d/modsec.conf
Put the following to that file:

# Fail2Ban configuration file
#
# Author: Florian Roth

[Definition]
failregex = \[.*?\]\s[\w-]*\s<HOST>\s
ignoreregex =

Then put this in /etc/fail2ban/jail.conf

 #
 # HTTP servers
 #

 [modsec]
 enabled  = true
 filter   = modsec
 action   = iptables-multiport[name=ModSec, port="http,https"]
 sendmail-buffered[name=ModSec, lines=5, dest=hostmaster@rietta.com]
 logpath  = /var/log/apache2/modsec_audit.log
 bantime  = 172800
 maxretry = 3

 [apache]
 enabled  = true
 port        = http,https
 filter   = apache-auth
 logpath  = /var/log/apache*/*error.log
 maxretry = 6

Then make sure that your fail2ban and apache are restarted.

Another way is to purchase some pre-configured device like sophos UTM with web application firewall, it's a good way if you are owning datacenter with servers, because UTM will off-load your web servers from that task (FYI, it's actually running mod security also, plus some additional features like package inspection, antivirus...)


Minimum requirements for storing last 4 digits of credit card number? We have a merchant website that uses Autorize.net's CIM and AIM. Our users may have multiple credit cards so we'd want to give them opportunity to distinguish between credit cards that they use on site. Currently we think about storing cardholder name, 4 last digits of CC number and its expiration date.

What are the minimum requirements that should be held to store this sensitive data?

Edit: PCI DSS says:

  The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed or transmitted, PCI DSS requirements do not apply.

So cardholder name and expiration date can be stored without being compliant. But what about 4 last digits of PAN?

Cardholder name, 4 last digits of CC number and its expiration date are all NOT sensitive data. The cardholder name and expiration date only require protection if you are storing them with the full primary account number, not the truncated 4 digit number.

If you are storing, processing, or transmitting cardholder data then you must meet all of the other PCI DSS requirements that kaushal mentions, but for the items you listed, you don't need to do anything special to protect them.

See pages 7 and 8 of the PCI DSS for more information on this:
https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf


TCP reset attack, number of Reset Packets I'm reading up on the TCP reset attack, and my understand is that for a third party to interfere with a communication they have to send a reset packet to terminate the communication between the two parties involved. and for the reset packet to be accepted, it's sequence number has to be in the receiver's window.

But since TCP sequence numbers are so large and there are many possibilities for RCV.next and RCV.wnd, how is it possible for an attacker to generate a reset packet to terminate the connection? Is it just a brute-force type attack where they have to generate as many RST packets as possible? Is there a minimum number of packets that could work? I Feel like this might be a little time-consuming and difficult.

What are the capabilities of your attacker? Usually TCP resets are performed by someone with visibility of the network. For example, Comcast got sued (and lost) for killing BitTorrent communications with TCP resets, but since they were inspecting the packets, they knew the sequence numbers to use.

Also, realize that 32 bits is only 4 billion-ish possibilities, and you can divide that by the size of the window you estimate. You can also expect to have to try only half of those on average before hitting the right one. Any TCP implementations whose sequence numbers start at 0 are easy to brute force, and it's only a few GB of traffic to kill even a connection with randomly initialized sequence numbers.


Is a server which FTP credentials were kept in a machine with Firefox being used compromised after the latest firefox vulnerability? Since the vulnerability was specifically targeting FTP passwords in Windows machines there were used with things like Filezilla, can a server which SFTP credentials were kept in a windows machine using Firefox be considered already compromised? If so, what can be done to remedy that?

First, I edited your question following your comment to @FiascoLabs answer regarding the fact you are talking about SFTP instead of FTP.

Coming back to your question properly:

  can a server which SFTP credentials were kept in a windows machine
  using Firefox be considered already compromised?

I prefer to discuss this question from different sides.

For the already problem, the answer is Yes and No. I mean it depends if you visited a website (server) that hosted the malicious script then you may have been a victim already. But this scenario has unlikely happened to you because the malicious script has been hosted on two main domains 93.115.38.136 and 185.86.77.48 which have been inactive since August 8th, 2015 after the intervention of the Ukrainian government.

The second side that you seem to be interested in through your question is related to SFTP: if you look to the list of files of which the malware is interested you can see:

But as the linked stated, this occurs during the first stage of the attack only, we do not know how much deep the file scanning is done by this script. Also, I may mention that exploit does not care if you are running your protocols over TLS/SSL or not.

  If so, what can be done to remedy that?

Is it so or not, you seriously need to upgrade your Firefox version to Firefox 39.0.3 in which the bug is fixed so that, even if you have not been trapped by the moment, you avoid being targeted by this malicious script (that could be modified to extend for instance the list of files to probe) in the case it would have been hosted elsewhere and you visit the site by accident or in purpose.


Protecting Health Care Database I am doing a minor project on information security in which i am implementing techniques listed below to protect a HEALTH CARE database.

Preventing SQL Injection (using prepared statements,validating,using a tokenization algorithm)
Preventing CSRF attack (inserting a hidden token in the form)
Preventing Brute Force attack (locking account after 5 unsuccessful attemts)
Preventing XSS
Validating every input
Initiating Session only on cookies
Implementing negative database.(http://en.wikipedia.org/wiki/Negative_database)
Encrypting Confidential Information
limited privilege for every user

EDIT
I am also implementing these points which i dont post earlier bcz i thought they are less important. but the answers here clearly shows the importance of these points:

Audit Log
Strong password
Secure connection using session_set_cookie_params
Access Control

So now my question is- Is there anything left that i m forgetting?? i know a few of them like security on network layer etc. I am running my project on localhost so i think i cant do anything on network layer.

SSL Connection to the server so no one can sniff passphrases or data
over the network.
Don't forget your backup: it should be encrypted too. The key should be stored independently so if someone gains access to the backup he cannot use the data.
Depending on your country of residence there can be legal requirements for health data protection.
Manage access permissions: make sure that if someone loses access permissions the account gets canceled.
Limit access to certain IP-addresses. In the ideal case the local network. It is pretty unlikely that someone from another continent needs access so don’t be afraid to block whole countries.
Block too easy passwords. Password123 and similar should not be possible! If an attacker gets hold of enough usernames someone will have a weak password. Using multiple IPs / a botnet an attacker can circumvent your brute force protection.


VeraCrypt mounted container safety If I mount encrypted container, it stays in encrypted state until file is opened. At this moment, file is fetched in memory and decrypted - VeraCrypt - Beginner's Guide.

Can malicious program open a file from mounted container? Should I worry about data in memory when working with files?

Can malicious program open a file from mounted container?

If the volume is mounted, any process that has the rights to read the mounted filesystem will be able to open files in it exactly as if it were unencrypted. As soon as it is mounted, it is not encrypted at all from the perspective of the computer. This encryption can only provide data-at-rest security. That is, if the computer is ever stolen and someone gets their hands on the encrypted volume, they will not be able to decrypt it without knowing the original password you used.

  Should I worry about data in memory when working with files?

The issue is not that the files are present in memory so much as the fact that the data is not being protected when the volume is mounted. The system will happily decrypt what you ask! When you try to access a file, whether it's present on a partition that is encrypted or not, the requesting program will tell the operating system kernel (the core of the operating system) what file it wants to access. The kernel will then perform all the steps necessary to read the file, including transparently decrypting it and handing the decrypted data to the requesting application.


How to cryptographically guarantee that data came from a trusted application on a mobile device? I'd like to have an open source application generate data and sign it in such a way that anyone with access to the data alone can know for sure it was generated by that open source code.

More specifically the application runs on a mobile device, say Android, and is not a trusted party. It generates data by processing device's sensor readings like camera, gps, etc with an open source algorithm. The data is then presumibly signed and uploaded to a database.

The idea is that someone who gets access to the data (observer) can cryptographically confirm that it was generated by a known version of the open source application. The observer does not have access to the runtime environment.

Is it possible to ensure that the application is a known, official version, or is it possible to circumvent?

You requirement has 2 major flaws:

it is not possible to securely include a secret in an application: by decompilation, the end user will always be able to find it. All you can do is obfuscation (google for it if you do not know).

Best practices in security recommends that a secret is to be accessed by very few people (idealy one single owner). That way, if you can confirm that the secret has been used, you can assume that the data was produced by a secret owner. And everything that is not a secret should be assumed to be known by an attacker. That does not mean that is should be publicly known, but the security should not depend on it.

In contrast, obfuscation consists in making something hard but not impossible to decode. It is often used in Javascript, because the script has to be interpretable by a browser, but some authors do not want that anyone can easily re-use their scripts. But if some one really wants to, it is always possible to understand what the script actually does.

Even in the case of compiled software, it is always possible to run the software through a debugger to identify at what point the data is encrypted and how.
I am sorry but there is no point in it (except software royalties protection but that is not the right tool IMHO): what should matters is who sent the data, or at least what specific installation (what machine or group of machine) sent it.

If you really want to know if the software was used by a legitimate user, each one should have a private key and the software should use that key