Padding Passwords For Security

Common attacks on passwords involve bruteforcing and using pre-computed ‘rainbow tables’. Avoiding both of these attacks is fairly trivial – for both it’s a matter of length and an uncommon password. The issue is that remembering many different long passwords is difficult, which is where password padding comes in.

Password padding just means that you take your password and add one or two characters repeatedly. For example:

Password: Ninja

Padded Password: !!!Ninja!!!

Ninja is an incredibly common password, a dictionary attack will probably try it immediately. You’d be cracked in seconds. By adding !!! to both ends we’ve made a dictionary attack less likely, bruteforcing will take significantly longer, precomputed hashes are less likely to work, and it’s as easy to remember as Ninja.

Of course !!!Ninja!!! is still not a very secure password. While that padding is great for avoiding attacks it would still be susceptible to dictionary attacks if they decide to bruteforce the padding.  But attackers don’t get points for “close” – they can be one character away or a million and have no idea which.

Take any of your passwords and consider putting some padding on them. It’s a very simple way to improve password security without having to resort to memorizing incredibly long passwords.

Bruteforcing 64bit ASLR

A lot of times we hear that it’s impractical or even impossible to brute force 64bit. It’s been the general consensus that the address space is too large and therefor any attack would be unreliable.

A paper recently set out to attack 64bit ASLR to see how effective bruteforcing can be. It’s important to note that they don’t take any other modern mitigation techniques into account, such as NX.

The paper shows a primitive attack can take as few as 1.3 hours but as many as 34.1 hours. They note that they could optimize and improve the performance quite a bit. But I think that massive variance between the minimum time and maximum time is exactly what makes ASLR powerful – it makes attacks less predictable and less reliable.

The paper then goes on to mention PaX ASLR, which introduces far more entropy into the system. Due to the papers very narrow focus on ASLR it, again, leaves out other mitigation techniques, such as the Grsecurity patchset’s Exploit Bruteforce Prevention. There are actually numerous PaX and Grsecurity mitigation techniques that could be implemented to prevent these attacks but the focus is less about “real world” and more about proving that 64bit ASLR on its own is not enough to prevent bruteforce attacks.

So while it’s clear that on a process that doesn’t use NX or modern mitigation techniques other than ASLR that bruteforcing is potentially possible, it’s incredibly unlikely that you’re running any programs that don’t use those techniques. These attacks also would likely cause program instability, and are still somewhat impractical even if they can be optimized.

Wikipedia Discussion On Iron Browser

For my original Iron Browser blog – see here.

So I got two referral hits from the discussion page for Iron Browser. It seems that someone there wants a “conflict” section explaining that Iron doesn’t actually provide anything that Chromium doesn’t, and nothing of substance compared to Chrome. A really great endeavor.

I’m not optimistic it will be let through. Why? The discussion page is clearly bias.

UPDATE: I posted on the discussion page. I talked to someone there about getting proper sources up. I’m obviously not reputable but my sources are – the issue is that because none of my sources explicitly mention the Iron browser they can’t be used to discredit the browser. Essentially Iron says X and the reputable source says ‘X is false’ but because the reputable source doesn’t say “X is false and therefor Iron is making a false claim’ it can’t be linked – Wikipedia doesn’t allow that type of connection, which they refer to as ‘synthesis’. I think that’s idiotic but I don’t really care – I’ve had thousands of hits on my Iron page so even though users who go to Wikipedia are essentially getting lied to via proxy there are many who have come to my blog and gotten the facts.

To quote:

“Scam” is not accurate

I’ll be reverting some of User:98.207.42.24‘s edits that basically littered this article with the same statement over and over, about how a self-published source compared Chromes and Irons source code and concluded that Iron is a “scam” because of the fashion in which Iron sets privacy values (hard-coded instead of through a user interface).

I have several problems with this:

• For someone that doesn’t want to do research about Google Chrome’s privacy faults before starting up the browser (even for the first time), Iron is helpful. And according to Irons website, that is what it was created for.
• The source is not a reliable source.
• The source is not timestamped so we have no idea when it was created and what has changed since then on Iron and Chrome.
• Iron disables RLZ, Chrome doesn’t.

As far as I can tell Iron was made for comfort and it’s not ment to fool anyone into thinking otherwise.

That’s from user Bitbit. Taking a look at user Bitbit’s page we see he’s obviously anti-Google (there’s a banner dedicated to disliking Google). His bias is obvious because his post is a bit silly, I checked his page because reading his post it seemed clear. I’ll explain why in this post! I want it clear that, unlike my post about the Iron developer, I’m not trying to be insulting here. The Iron developer is throwing out crapware/ scareware whereas this is just one user with his opinions. I’m not going to attack him or his opinions, only explain why his post on the matter is invalid. So many people have fallen for the Iron browser, I don’t blame any of them, and I’ve seen so many users on other forums read the information and immediately state that they’re moving to another browser.

Let’s take this one step at a time.

For someone that doesn’t want to do research about Google Chrome’s privacy faults before starting up the browser (even for the first time), Iron is helpful. And according to Irons website, that is what it was created for.

For someone who doesn’t want to do research? Well… if you’re a user who winds up on Iron’s page it should be obvious that you were looking for a more private alternative to Chromium or Chrome. So the defense that Iron isn’t purporting itself as a more private alternative, only one with a more private default configuration is fairly weak. Furthermore, the Iron developers claims are disingenuous – one really clear example is the “URL Tracker” feature,  a poor choice of name but the Iron developer makes it out to be a privacy issue when it is obviously not (you can read about this all in my original post). Therefor it is far more than a claim of “default configuration” because the developer has made claims that features removed are privacy violates when they are not.

• The source is not a reliable source.
• The source is not timestamped so we have no idea when it was created and what has changed since then on Iron and Chrome.

There are multiple sources available. I found many in my original blog post on Iron. Bitbit didn’t look for any, so naturally he didn’t find them. The information is out there, and I’ve put it all in one place to make things simpler.

Iron disables RLZ, Chrome doesn’t.

As I explained in my original post, RLZ is not a privacy issue. It also does not exist in Chromium.

As far as I can tell Iron was made for comfort and it’s not ment to fool anyone into thinking otherwise.

If you look at the facts from my first post it should be clear that Iron was made for money. It is absolutely designed to fool people – the page is filled with lies.

[…], these are flat-out dry facts, not an opinion

Here are some absolute sourced facts that can be externally verified, and I didn’t go into in my original post. I suggest reading the first post for a full tear down of Iron.

The default installation of Iron contains a bookmark to the Iron forum. On this forum? Ads.

And the default home page? Ads as well!

On its own this is hardly damning. Ad-based software is perfectly fine. Where the issue lies is that this is software designed to make a profit and it does so by playing on users fears. Adware, Scareware, Scamware, all can easily be seen as fitting. In every case it’s a matter of a user being tricked, or scared, into using a software that makes money off of them while providing no actual benefit to that user.

So it’s my hope that Wikipedia does include a section that puts all of the information available in their article. I’ve made use of many sources and they’re free to verify it all. When you search “Iron Browser” on DuckDuckGo Wikipedia is in the result box and it’s the first thing many users will see – providing those users with all of this information is important, it’s what Wikipedia is for. I’ve sourced my original post thoroughly and redundantly. I hope the information in that post is put to good use.

Thanks to whoever said the nice words about the post on that Wikipedia article (no username). I appreciate that.

You can find my original post here: https://insanitybit.wordpress.com/2012/06/23/srware-iron-browser-a-real-private-alternative-to-chrome-21/

HTTP Strict Transport Security Becomes A Standard

HTTP Strict Transport Security, or HSTS for short, is a method for ensuring that all HTTPS traffic remains HTTPS, and can not be tricked into using HTTP. Currently when a website uses HTTPS it’s vulnerable to SSLStrip type attacks, which redirect the browser to HTTP and spoof information that makes it difficult for end users to detect.

HSTS ensures that SSLStrip type attacks can not work.

Firefox and Chrome have both supported HSTS for some time, but hopefully as it’s standardized more websites will support it, ensuring that encrypted connections remain encrypted.

Windows 8 Metro Isn’t So Bad

Windows 8 ships with a new User Interface that’s gotten a lot of flack but the truth is that I’ve found it very easy to adjust to and it hardly differs from Aero for my usage. If you look at the UI as a whole, at every part, then it looks much further from Aero, but if you just focus on the parts that the average person is going to use… it’s really quite similar.

Here’s a picture of what I’m staring at 99% of the time I’m on my computer.

Hardly a major change from Windows Vista or 7. The only noticeable change for me is the start menu, which is now a start ‘screen’.

 

That’s a fairly large difference, but not wholly unwelcome. There are benefits, such as having live tiles and the large icons are easy to read, and there are downsides, such as being taken from whatever you’re doing and being put entirely into this new menu.

It doesn’t interrupt my workflow, personally. 

This isn’t really a review of the UI but I think people should understand that while as a whole the user interface is very different, when you cut down to the bits you’ll interact with, it’s almost identical to Windows 7.

And if you’re after security Windows 8 is going to outperform Windows 7 there, especially after further hardening.

 

Windows 8 With EMET Is Surprisingly Stable

I’m using Microsoft Windows 8 and I have been since just a few days after the official release. Naturally EMET (click here for more info) is one of the first programs I install on any Windows OS and with ATI now supporting ASLR with the 12.7 and up drivers I’ve set my system to the maximum settings for all categories.

Essentially the three major exploit mitigation techniques, DEP, ASLR, and SEHOP, are forced on all executables on the system. The default setting for both DEP and ASLR is Opt-In, which isn’t very secure (though all new programs ship with DEP at this point due to compiler default flags) so by ignoring program settings and forcing these techniques system wide EMET makes the system more secure.

The downside is potential compatibility issues. So far I’ve only had issues with CCleaner’s installer, which does not like ASLR, although CCleaner itself does work fine with ASLR enabled.

Anyone looking to really secure a Windows system against attack should consider setting EMET up this way. To see how to enable ASLR to Always On via EMET just click here.

Remember, to get the full benefit of EMET you should also make use of the per-application settings, which will enforce multiple techniques other than DEP, SEHOP, and ASLR. And if you don’t mind Metro you should consider moving to Windows 8 as it has significantly improved ASLR.

64bit Chrome For Windows Gets A Bit More Progress

Users have wanted a 64bit Chrome browser for quite some time and with Firefox, Opera, and Internet Explorer allhaving 64bit versions(though Firefox does not officially support their 64bit builds) it’s a bit surprising that Chrome hasn’t released one.

The Chromium bug for 64bit support has gotten some activity recently though. We can hope this continues.

The benefits of a 64bit browser are numerous but also variable – 64bit is not magic, you don’t get it to compile for 64bit and suddenly have a super speedy browser, you have to optimize for 64bit and really make sure you take full advantage of the potential that comes along with it.

Some of that potential is directly related to security.

When most people think of 64bit they think of being able to access more RAM. The reason 64bit can access more RAM is because it can address 2^64 bits of data, whereas 32bit can only access 2^32 bits of data. This also means that it can access files of a size up to 2^64bits and that it has an address space of up to 2^64bits (although it’s not that large).

A larger address space will significantly improve ASLR, which relies on randomizing areas of address space. If you want to find random values between 1 and 10, there are only so many times you have to guess no matter how strong the random dumber generator is – make that between 1 and 1,000,000 and things get much harder to guess.

On Windows 8 64bit processes can opt into High Entropy ASLR, which improves the randomization of address space further, by increasing the randomness of memory allocations.

So 64bit Chrome will make things more difficult for attackers, especially on Windows 8.

In terms of performance there may or may not be significant improvements. 64bit comes with a downside, pointers are twice the size, and apparently for a browser that could end up being an issue due to how data is structured. Mozilla was working on 64bit Firefox but dropped the project because the benefits were not outweighing the development costs.

Star the Chromium bug if you’d like to see work on 64bit Chrome and Chromium for Windows continue.

The Wrong Attitude Towards Security

My biggest issue with the security field and the people in it is the attitude towards the user base at large. When a user is infected it’s almost always considered to be their fault – they went to a malicious page, they were tricked into installing a malicious program, they were tricked by a man on the phone, etc, must be their fault.

To look at millions of infected systems and say “the system is fine, the users are the issue” is backwards. Systems are meant to serve users, not the other way around. 

This attitude needs to change if security is going to progress. Security models need to be built around the idea that developers of applications won’t care about security, or know enough to be secure, and the users of those applications either don’t know or don’t care to be secure either.

A security model that assumes users will answer a prompt correctly without providing them with blatant and clear information, will fail. A security model that allows developers to opt into security features will fail.

So until someone takes these issues into account, issues that have historically never wavered, there will be millions of infections.

Chrome Website Permissions UI

Chrome has added a new interface for dealing with website-specific permissions.

It should make allowing and revoking permissions for websites a bit simpler.

Android 4.2 Is Out – How’s The Security?

Android 4.1 introduced multiple security improvements, such as implementing proper ASLR with PIE and fixing numerous information leaks. It seems that 4.2 is all about security, really pushing Android up a few notches.

 

• Application verification — Users can choose to enable “Verify Apps” and have applications screened by an application verifier, prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an application is especially bad, it can block installation.
• More control of premium SMS — Android will provide a notification if an application attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the application to send the message or block it.
• Always-on VPN — VPN can be configured so that applications will not have access to the network until a VPN connection is established. This prevents applications from sending data across other networks.
• Certificate Pinning — The libcore SSL implementation now supports certificate pinning. Pinned domains will receive a certificate validation failure if the certificate does not chain to a set of expected certificates. This protects against possible compromise of Certificate Authorities.
• Improved display of Android permissions — Permissions have been organized into groups that are more easily understood by users. During review of the permissions, the user can click on the permission to see more detailed information about the permission.
• installd hardening — The installd daemon does not run as the root user, reducing potential attack surface for root privilege escalation.
• init script hardening — init scripts now apply O_NOFOLLOW semantics to prevent symlink related attacks.
• FORTIFY_SOURCE — Android now implements FORTIFY_SOURCE. This is used by system libraries and applications to prevent memory corruption.
• ContentProvider default configuration — Applications which target API level 17 will have “export” set to “false” by default for each ContentProvider, reducing default attack surface for applications.
• Cryptography — Modified the default implementations of SecureRandom and Cipher.RSA to use OpenSSL. Added SSLSocket support for TLSv1.1 and TLSv1.2 using OpenSSL 1.0.1
• Security Fixes — Upgraded open source libraries with security fixes include WebKit, libpng, OpenSSL, and LibXML. Android 4.2 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

The really key security features here are the application verification and the premium SMS warnings. The majority of Android malware out there redirects you to Premium SMS services, which will charge you per-text, easy money for criminals. This should prevent most of those infections.

The OS is also, overall, more difficult to exploit. Most infections are due to social engineering and not exploitation, but for those looking to store sensitive information on their phones (hopefully after encrypting them) this should help keep that information safe.

Source:

https://developer.android.com/about/versions/jelly-bean.html