Profile

Cover photo
Enrico Tagliavini
68 followers|85,276 views
AboutPostsPhotosVideos

Stream

 
Found by accident article [1] on +Forbes  while googling staff. Let me cite two parts:

1) "If any more evidence was needed that the username-password paradigm is a flawed form of authentication, the Twitch breach has provided."

This is so damn annoying. No. please repeat after me. NO. Security is as weak as the weakest link in the chain. Here the issue can be user side, if the user happen to use a weak password, or server side, for example if the password is stored in clear text or with weak / insecure  hashing algorithm. So pray tell which authentication algorithm is immune from such deficiencies? I would really love to know, since it would make my work easier if we could adopt such authentication mechanism I could spend less time hardening my server and do something else.

TBO twitch has done a good thing in this regard: use a password manager auto generating passwords, still the user needs to generate a very good one, protecting all the others. If the user is already able to do so the password manager becomes less useful. They also gave decent examples (see [2]):

Bad: Applesauce1! – You’re using different character types, but the majority of the password is a single word from the dictionary
Okay: ILoveGreenApplesauce – You’re using multiple words and lots of characters, but the words are too common.
Good: !70v3Gr33n@pple$auce?– You’re using multiple words and lots of characters with uncommon substitutions. Good job.

Now I don't agree with the good one. While is looks secure, it is not much more. This is the same password as the okay one, suffering from the same defect, the words are common and the numbers are leet speaking, which is a very well known rule. If it is a rule no entropy, but still, not a totally bad suggestion. A more correct one would have been "do not make a sentence, use random, unrelated words from the dictionary".

You might think about asymmetric keys, like SSH and certificates, but they are not portable, as in you cannot memorize them and carry them with you without a physical device. A cracker will never be able to crack your mind and steal the data from there, they mush crack the device you are inputting in or the server on the other side. You can encrypt them, but again..... you need a password to do so. Crap!

For sure there will always be users going for damn low quality password, it is quite challenging to make a good password quality checker. But to be honest as most people learnt their computer needs an anti virus most of them can understand the password quality problem, if explained. The very famous Xkcd comic did quite a good job, I used it to explain it to my Mom (a person powering on the monitor when asked to power on the computer) and she does goddamn awesome passwords, likely better than me myself.

2) "Web security expert Troy Hunt told FORBES more than eight was surprisingly restrictive."

EDIT: I misread this, my apologize, the quote that follows says "“But what’s disheartening about this is that users have apparently baulked at creating passwords longer than eight characters so are clearly not getting the message on what constitutes a strong ‘secret’.”"

[1] http://www.forbes.com/sites/thomasbrewster/2015/03/24/amazon-twitch-hacked-passwords-nabbed/
[2] http://blog.twitch.tv/2015/03/important-notice-about-your-twitch-account/
((The comic illustrates the relative strength of passwords assuming basic knowledge of the system used to generate them. A set of boxes is used to indicate how many bits of entropy a section of the password provides. The comic is laid out with 6 panels arranged in a 3x2 grid.
1
Add a comment...

Enrico Tagliavini

Shared publicly  - 
 
Well I'm not alone. Thank you :)
In a previous post we talked a lot about the “Product-centric” approach to DevOps but what does this mean for the role of the Agile “Product Owner”? So what is the traditional role of the Product O...
1
Add a comment...
 
Let me set aside the problems I have with Canonical for a moment.

This is cool, I'm happy to see someone else other than the KDE project with Plasma Active is working on something like this. I love Linux as I can found it in the desktop, like Gentoo, Fedora and Ubuntu. Android, on the other end, is a super frustrating experience for someone like me, Apple stuff is not even an option. I need deep control and freedom on the software I use (both in what I can do and how can I modify it), I can only make few exceptions. The ability to run an entire proper Linux desktop on my phone / tablet gives me a super high degree of freedom.

And I also want x86 (again for freedom reasons), ARM makes me sick with their closed nature.

I cannot wait to see what Plasma active will be able to do when based on KF5 (if not already, I kind of lost the track of mobile stuff in a while) and Wayland.

These kind of devices can make me happy of spending more than 500 euro on a phone or tablet and to actually make an internet contract for my phone (yes I don't have one, because 1. the costs are ridiculously high and 2. what do I need it for? I'm on my PC 12+ hours a day anyway I don't have to check the mail for that hour I'm not. With this kind of devices however the game changes a bit).

That said since I need more than one device (like one phone and one tablet or two phones) I still need more conventional one. The #Jolla phone and tablet and FirefoxOS phones are for sure an option.
1
Add a comment...

Enrico Tagliavini

Shared publicly  - 
 
After 123 days of uptime I rebooted my main server today. Was running gentoo hardened sources 3.14.7 and before rebooting had a memory leak of about 8GB. slabtop revealed this was dentry stuff. Updated to kernel 3.14.33-r1 (again hardened sources from gentoo indeed). Hopefully the memory leak will not come back :)
1
Add a comment...

Enrico Tagliavini

Shared publicly  - 
 
Well that's bull crap and not appreciated at all :(
Phoronix is the leading technology website for Linux hardware reviews, open-source news, Linux benchmarks, open-source benchmarks, distribution screenshots, interviews, and computer hardware tests.
1
Thomas Pfeiffer's profile photoEnrico Tagliavini's profile photo
2 comments
 
+Thomas Pfeiffer yes indeed it is a nice thing, provided I have the possibility of adding keys to the whitelist. Forcing me to use their BIOS/firmware or to remove the security feature is not a good thing. It is like UEFI secure boot. The first proposal by Microsoft was totally preventing you to run Linux and all other non Microsoft approved OSes. Then they added the option (not mandatory to implement though) to change the whitelist, but only few vendors are actually doing so, or to disable secure boot. The latter option grants you the ability to boot any OS, but you loose the security part, which is not nice.

I have an Haswell laptop here, a thinkpad 440s. The BIOS is really not the best. I had to update it for the UEFI security issues and it broke some stuff. Nothing preventing the use of the system, but annoying stuff regardless. I would seriously consider the option of migrating to coreboot on this system given what's provided by the vendor is not of top quality, but apparently I can't (and I understand why it is not supported as well).
Add a comment...
Have him in circles
68 people
Francesco Riosa's profile photo
Mokhtarone Ben's profile photo
Putry ayu's profile photo
Nicolò Mazzali's profile photo
oscar felipe gugnoni's profile photo
Fabio Erculiani's profile photo
Canek Peláez's profile photo
Paolo Accordini's profile photo
Elia Schneider's profile photo

Enrico Tagliavini

Shared publicly  - 
 
Many thanks to LWN for sharing this. http://lwn.net/Articles/637745/

You don't need to be a conspiracy theory fanboy to understand this is a very critical problem and a very deep technical issue in the software and it must be solved. The same way you update your software to use the latest SIMD instructions and latest CPUs so you should do for encryption and security.
 
Deprecating Old Crypto in a Linux Distro: A tale of something that looked obvious but .. there's a lesson in it somewhere.

While working on my Linux distro project at work, one of the things I recently wanted to do is phase out old crypto.

Yes we all read Bruce Schneider's text and how important it is, but nothing drives it home like reading The Guardian articles followed
by OpenSSL downgrade attacks in the last year or two.

Now, nothing should be defaulting to some of the antique crypto, but the only way to know 100% sure  that the algorithms in question aren't being used, is to just not compile them into the various crypto libraries of your distro.

So.. step 1 was to look at the algorithm list of openssl:

arjan@clr:~$ openssl ciphers

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DH-RSA-DES-CBC3-SHA:DH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DH-RSA-DES-CBC-SHA:DH-DSS-DES-CBC-SHA:DES-CBC-SHA




A few things stand out immediately.

RC4. This like seriously predates MD5, and MD5 is already suspect.

DES. Yes really. DES. in 1995 I worked at a company as an intern that made DES chips that you could use to brute force DES. In 1995, when Twin Peaks was on TV  and you measured transistor sizes of a chip in micrometers not nanometers.

MD5. The general consensus seems to be that for crypto, you shouldn't use MD5 anymore. I'm not talking about SHA1, where one can argue that existing uses are still ok, but MD5.

I decided to draw my first line there, stick to the consensus and all that.

The good news is that OpenSSL is very configurable, and it's pretty easy to say

no-rc4 no-des no-md5

on the configure line (and for good measure, I added no-ssl2 and no-ssl3).

At this point, I thought I was on a roll, removing old crypto is easy, lets finish this 15 minute project before the project meeting starts.

So now on to the bad news. And sadly, there is plenty to be had.

openssl does not even compile with the no-md5 option:

make[1]: Entering directory '/builddir/build/BUILD/openssl-1.0.2a/ssl'
In file included from s3_srvr.c:171:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from s3_clnt.c:158:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
....


Ok, so MD5 is technically not insane broken for small packets, and
it's just consensus not so much hard earned proof, so maybe deprecating md5 is a project for another day.

openssl does not even compile with the no-des option:

make[2]: Entering directory '/builddir/build/BUILD/openssl-1.0.2a/apps'
../libcrypto.so: undefined reference to `EVP_des_ede3_wrap'

or when you fix that, it does not pass its test suite (I'll spare you the details). 

Now here I had to draw a line. 20 years ago DES was not secure.. never mind today. I wouldn't  be surprised if someone will chime in and say that their smartwatch can brute force DES in realtime now.
So.. fixing it is.

I suppose the good news is that no-rc4 went just fine.

The success story then, with the list of crypto from openssl after no-rc4 and no-des:

$ openssl ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA

no DES, no RC4.




But, as it was a Monday, the misery only started there (Dave Jones should have taught me that misery is like lawyers, it always comes in pairs).

I threw the no-rc4/no-des package into our build system, and in no time the world came apart on me. Half the distro broke!
Well not half, but several very important pieces.

It turns out that components like curl, libcurl (so anything speaking http), wget, openssh, mariadb, ...

all hard-code DES usage. Now, I'll give curl credit, with creative use of configure options, you can make it not compile DES in, but you can't then make it pass its testsuite.

There must be a lesson in here somewhere.

One, our team will be fixing these projects to not require DES (or RC4), and we'll send those patches to the upstream projects of course.

But more, and this is a call to action: If you're working on an open source project that uses crypto, please please don't opencode crypto algorithm usage.
The algorithm may be outdated at any time and might have to go away in a hurry. 
And if you have to use a very specific algorithm anyway (for compatibility or otherwise), at least be kind and make a
configure option for each algorithm in your project, so that when things go bad (be it in 5 or 20 years), its very feasible to disable the algorithm entirely. 
29 comments on original post
1
Add a comment...
 
No srsly +Oracle takes care of your security, they even enable TLS when you download java (well thanks for that TBO)! Well, they are trying hard, but you know.... this fscking conspiracist make these security things so hard to use!
1
Add a comment...
 
Holy cow only 4 euros for The Witcher 2 and it is available for Linux! Ok is not the greatest of the ports, but works decently afaik. To buy or not to buy? It is the price of two damn coffees.

On a related note: Torchlight II available for Linux!?!! Might play it again since I left when I was almost at the end of it.

And, as last question, to switch or not to switch to Fedora for my gaming OS?
Enjoy a captivating story, dynamic combat system and beautiful graphics in the second installment in the RPG saga about the Witcher, Geralt of Rivia.
1
Add a comment...
 
So #Firefox 36 was released with a good news (HTTP/2.0) and a very bad news, for Linux users (well at least I'm affected): rendering performance dropped and regressed sharply! You might know with Firefox 33 Off Main Thread Compositing got enabled by default on Windows (and if I understood correctly OS X and Android came first, at least with partial support). Linux is the only one missing, OTMC is still disabled by default on Linux due to some issue still to be solved, but is marked as mostly working, see [1]. My best guess is that main thread compositing is simply rotting slowly (well not really a guess, see [2], that's a post from Oct 2013...). Now in most cases this regression is not that bad, unless you are "forced" to watch 60 fps 720p streams with Adobe flash (hello +Twitch, what about releasing some non flash based solution, at least opt-in like youtube does? Yes Firefox doesn't support MSE yet and it sucks.... but I would not mind too much to use Chromium for twitch until Firefox can support MSE or whatever you will choose.... if I can avoid flash at least, provided that's not something coming from Apple working only on Apple coff coff).

Back to topic, if you are so unfortunate to have to use flash, a nice optimized piece of software sucking between 60% and 90% of your mighty x86 CPU resources [3], Firefox starts having rendering serialization issue (VLC needs like 10% of one single core to say a lot IIRC). Firefox 35 was working very well for some reason, 36 is terrible. Well main thread compositing is less and less maintained, OMTC "mostly works", let's give it a shot. Well it works pretty well for me. I used it like only 15 minutes for now, performance is on par with Firefox 35, maybe a little bit better when loading multiple tabs (and under CPU load due to other programs), but it is hard to say for sure. That said if Firefox 36 is sending you back to the '90 (which were cool btw) you can set the env variable MOZ_USE_OMTC=1 to temporarly enable OMTC. If it doesn't work for you, just unset it and you'll be like before. So again the magic line is:

export MOZ_USE_OMTC=1
firefox

hope it will work for you as well. Please +Mozilla Firefox get this ready soon!

[1] https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositing
[2] https://mozillagfx.wordpress.com/2013/10/28/removing-old-opengl-layers/
[3] On a related note, I really recommend everybody to install the needed gstreamer plugins / libraries (mainly the libav one), go to https://www.youtube.com/html5, request html5 and enjoy. libav support is needed to enable H.264 support for Firefox in Linux. Regardless of the lack of MSE it works like a charm.
Overview. See BenWa's blog post about OMTC (note, however that the Java part in the blog post only applies to Android). Current status. Shipped on all platforms except Linux (almost there on Linux as of Oct 6th 2014). Goals. The main goal is to improve responsiveness. this architecture has the ...
1
Enrico Tagliavini's profile photo
 
So there is something that confuses me a little. Looking at about:support OMTC is not reported to be enabled, still my experience changed dramatically by setting this environment variable. Maybe it was just a fluke, but it was not looking like so, I restarted firefox many times before even starting thinking about enabling OMTC. So there might be a bug in about:support. That said if you want to squash any doubt there is a config setting available in about:config. WARNING you warranty is void if you do this. Make a backup, pray and hold your butt

layers.offmainthreadcomposition.enabled = true

this should give you the following in about:support

GPU Accelerated Windows    0/1 Basic (OMTC)

and for the real brave you can even enable openGL acceleration with

layers.acceleration.force-enabled = true

be aware for me setting this last option breaks, Firefox locks up after short usage. This is not recommended for daily usage for me.
Add a comment...

Enrico Tagliavini

Shared publicly  - 
 
Ok this is a real pile of bull crap +Lenovo. I will keep this very well in my mind next time I by a PC. I'm pretty sure there are really few companies out there with clean hands, but at least make some damn effort not to let me know and give me at least the benefit of a false sense of security, do you mind? :/
Lenovo is being lambasted for its use of a visual search technology called Superfish, as many believe it poses a privacy problem by intercepting users' traffic to display adds. But the more serious concern is that it could be abused by hackers to attack other Lenovo laptop users.
1
Add a comment...
 
Yesterday I tried firefox hello for the first time (and it actually worked!). It looks quite interesting, quality is good I have to say. It really has the potential to become my favourite video conferencing tool, we will see.

Thank you +Mozilla Firefox 
1
Add a comment...
People
Have him in circles
68 people
Francesco Riosa's profile photo
Mokhtarone Ben's profile photo
Putry ayu's profile photo
Nicolò Mazzali's profile photo
oscar felipe gugnoni's profile photo
Fabio Erculiani's profile photo
Canek Peláez's profile photo
Paolo Accordini's profile photo
Elia Schneider's profile photo
Links
Basic Information
Gender
Male