Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:Didn't say it's stupider than stupid. (Score 1) 149

by Fweeky (#48726405) Attached to: 13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites

It's not being used as a key. Key stretching would be pointless. You stretch to get a longer key if your goal is to derive a strong key

You want a strong key! Key stretching isn't just about making a physically longer key, it's about making a stronger one, such as by iterating your hash function a million times.

KDFs are for key derivation. That's why they're called key derivation functions. How is that hard to understand.

This is not in question. What is in question is why it's not exactly what you'd want out of a password hashing function - what difference does it make whether you're going to pass it to AES or to a comparison function?

Comment: Re:Didn't say it's stupider than stupid. (Score 1) 149

by Fweeky (#48697595) Attached to: 13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites

A better choice is a properly vetted hash that's designed as a hash, such as SHA256

... which you then need to, at a minimum, apply salting and key stretching to. Good work, you just rewrote most of PBKDF2, just without the peer review, sane defaults, and for most people, probably in a language where the function call overhead exceeds the cost of the hashing.

Using a KDF as a hash is like using a butter knife as a screwdriver - it gets the job done, and professionals normally use the tool designed for the job rather than substituting.

Hashes are not designed for password storage, that's the entire reason we're having this conversation in the first place. People use KDF's for password storage because that's what they're made for. Anyone who uses a plain old hash has to make a KDF out of it. How are they different?

Comment: Re:no, no, and no (Score 1) 149

by Fweeky (#48691781) Attached to: 13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites

You want the hash algorithm to be SLOW, not "well optimized" ... You don't want it to be computationally complex.

How do you make an algorithm that's slow without being computationally complex? Writing it all in PHP doesn't count.

The algorithm has to be slow because it's a lot of work. Your implementation has to be fast to maximise the security benefit of using it in the first place.

You don't care about turning it into an unpredictable number.

What else do I want a hash function to return?

In fact you sometimes enforce O(1) time, you don't want a longer or different password to take longer to hash, because that facilitates timing attacks.

Pad your inputs and use constant time comparison functions, kids.

Comment: Re:those are key derivation, not for passwords, co (Score 1) 149

by Fweeky (#48690477) Attached to: 13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites

Er, not really? You want a well-optimized function to turn a password into a very big unpredictable number in a way that's computationally complex, and that's precisely what KDFs are made to do. The entire crux of your argument against such use seems to boil down to "but they sometimes let you specify how big a number you want", as if this added complexity and risk somehow massively outweighed that created by rolling your own slow crappy little alternative.

Comment: Re:Just in time. (Score 1) 219

by Fweeky (#48590859) Attached to: Seagate Bulks Up With New 8 Terabyte 'Archive' Hard Drive

I recall reading that the uncorrectable read error rate tends towards the 2TB mark.

12.5TB, assuming the specified 1-in 10^14 bit uncorrectable-read-error rate specified for most consumer drives is accurate. I certainly don't see rates anywhere near that high with my consumer drives, but I could just be lucky.

Comment: Re:Rather late (Score 1) 313

by Fweeky (#48476239) Attached to: Windows 10 To Feature Native Support For MKV and FLAC

I still have two or three recent (i.e. last four or five years) devices that have problems seeking VBR files or displaying the proper duration.

Even foobar2000 has issues with seeking in MP3s. From the FAQ:

Why is seeking so slow while playing MP3 files?

The MP3 format doesn't natively support sample-accurate seeking, and sample accurate seeking is absolutely required by some features of foobar2000 (such as .CUE playback). MP3 seeking can't be optimized neither for CBR files (frame sizes aren't really constant because of padding used), nor for VBR files (both Xing and VBRI headers in those files contain only approximated info and are useless for sample-exact seeking). Therefore MP3 seeking works by bruteforce-walking the MPEG stream chain and is appropriately slow (this gets faster when you pass through the same point of file for the second time because seektables have been built in the RAM).

Comment: Re:Where does this leave independant media players (Score 1) 313

by Fweeky (#48475483) Attached to: Windows 10 To Feature Native Support For MKV and FLAC

You need weird-ass buggy fb2k plugins, but are only missing format support in WMP? Do you play a lot of ancient tracker music or something?

If you find the fb2k interface so intimidating perhaps you'd be better off with its much simpler cousin, Boom. Not sure if it's got much support for particularly oddball media formats though.

Comment: Re:Tempting (Score 1) 181

by Fweeky (#48364849) Attached to: Multi-Process Comes To Firefox Nightly, 64-bit Firefox For Windows 'Soon'

Multi-process architecture... I've not really noticed a problem with the threaded one, and Firefox already sticks flash objects in a separate process. So what's the real draw

Isolation. The same reason you want different apps to have their own processes instead of having the whole of userspace in one big blob. You can give processes reduced privileges to reduce the scope of exploits, hangs and crashes don't take down more than they have to, and leaks don't force you to restart the entire system to recover resources.

Plus it makes for simpler concurrency. Kind of handy when you've got a stop-the-world garbage collector if you can just split the world into many smaller independent units, each able to run at the same time and each with an order of magnitude less work to do and no synchronisation to worry about.

64bit... again, bragging points about how many bits you use, no functional difference to anyone

ASLR is a fuckload more effective when it has a reasonably sized address space to work with, and 2^32 is miles away from being reasonable. It's the difference between an attacker having to guess one of 8 locations and one of 8 billion. Plus, memory mapping things is awesome, and also a fuckload easier with a reasonably sized address space.

And hey, some of us actually use our browsers quite a lot. Mine's eating 5.5G right now. So many windows and tabs, and absolutely no fucking reason whatsoever why that should be considered even slightly unreasonable.

Comment: Re:Per-user salting (Score 1) 223

by Fweeky (#48227203) Attached to: Passwords: Too Much and Not Enough

How many people do per-user salting of the password hash?

People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.

If you're using passwords for authentication in your app, use a recognised key derivation function. Use PBKDF2 or bcrypt and tune them to take at least 100ms to run. If you're extra paranoid, use scrypt and tune it to take 100ms and 16MB of memory. If you're doing anything else without having a well-received peer reviewed academic paper describing it, you might want to reconsider.

Comment: Re:This does pose the question: (Score 4, Interesting) 195

by Fweeky (#47616075) Attached to: Facebook Seeks Devs To Make Linux Network Stack As Good As FreeBSD's

pkgng's made port upgrading much less burdensome - even fairly complex dependency changes can be handled automatically as of 1.3, and the official package repositories are a lot more useful now. They even have stable security-fix-only branches.

I still make my own customised builds, but I make binary packages in an isolated jail using poudriere. 99% of upgrades are a matter of updating its ports tree, running rebuild-packages, and running pkg upgrade on all my machines.

You couldn't pay me to go back to portupgrade/portmaster/portmanager.

Comment: Re:so, I'm in the more than 8 yrs ago camp (Score 1) 391

by Fweeky (#47602585) Attached to: How long ago did you last assemble a computer?

If you're actually that bothered about the data integrity benefits of ZFS, it'd probably have been a good idea to go for ECC memory. Pools can pretty much self-destruct in face of memory corruption, and memory failure rates are not that much different to disk failure rates.

Such bullshit that it's so rare and poorly supported. The actual material cost is tiny - a few more motherboard traces and 1 extra memory chip for every 8. With AMD at least it's mostly a case of finding a good motherboard vendor, instead of the server/workstation board and CPU combo Intel demand.

Elegance and truth are inversely related. -- Becker's Razor