And this is why nobody encrypts passwords correctly.
-
Masochist.
Another big 'ol pile of WTF out of further exploring this server configuration:
It's not running Apache AT ALL. It's running IIS*4*. In addition to MySQL, there's also a SQL Server 7.0 available. So what the client told me was a standard LAMP configuration is actually a really rusty, ancient WIMP.
-
@morbiuswilters said:
@Weng said:
Either your googlefu is better than mine or you just know way too much random shit.
I've done hardcore PHP development for 5 years now. Sadly, I know way too much about working around the defects of PHP and the environments and configurations it is often run under.
After spending one week with ASP.net, I've vowed never to go back to PHP.
-
It felt the same after trying ROR !
but without the part where microsoft drains my bank account to buy licenses
-
@morbiuswilters said:
Having a hash collision in the
160-bit-or-so password space is damn near impossible. It's
certainly not the kind of concern anyone else has, even with
something like 128-bit MD5. Hash collisions are a concern when building
a message digest of some arbitrary-length data, such as a several MB
file. Considering how much effort it takes to generate a collision with
lowly MD5, even when you can pad with plaintext with as many arbitrary
bytes as you want, it's not a serious attack vector against hashed
passwords.FTFY.
Of course, 160-bit is SHA1. You're looking at a 448-bit space, and I'm looking at 512 bits. I find myself concerned with this for a few reasons:
- I've *had* an account compromise because my 26 character password hashed via SHA1 had a collision with a (IIRC) 4 char string, and someone found it by brute-forcing the hash.
- It's not like it's a separate attack vector: if the attacker manages to break the hash, they don't find out whether they hit a collision or the 'real' value. So they're not trying anything different to do this. If anything, it's easier than generating a hash collision with several MB file.
- I've worked through the math, and realize that if one is using a password longer than the hash bits, and the hash does not encode length, there's usually going to be at least one shorter password that'll match the hash. (If the hash *does* encode length, that's a completely separate issue, but more for those who use short passwords - that's not me, so it's not really my concern.)
Using SHA512, I can theoretically safely use passwords up to 64 characters - which is more than I'd do. But sometimes I'll go for a 50 character passphrase. Since I don't count characters when creating the passphrases, that's a bit too close to the 56 byte limit for bcrypt for my comfort. And so long as my password/passphrase is over 20 characters, I don't *care* if some cracker's running through possibilities at 500 billion per second. Yeah, with a 'b'. We're talking about over 2^126 possibilities here (since my passwords have more than 64 characters to choose from), and that'll take over 2^87 seconds to run through. Odds are, the password would be found in the first half of that, so well over 2^80 seconds to break the password. I plan on changing it before that time expires. Also, I plan on expiring before that time expires.
(Of course, on systems where MD5 is in use, I'm not going to set a password longer than 16 chars, and I'm very much bothered by the fact that the math there works out to less than a second to break that at 20 million attempts per second, even with considering all shorter passwords and all possible bytes. As you've stated so many times, MD5+salt is roughly the same as plain text, in the hands of the wrong person.)
However, in the end, the advantage of bcrypt is basically you can safely have a password that is one or two characters shorter than you can with SHA512. I'd rather have my website allow many simultanious logins while responding relatively quickly, and require my users to type in a couple extra characters.
-
@Weng said:
Another big 'ol pile of WTF out of further exploring this server configuration:
It's not running Apache AT ALL. It's running IIS4. In addition to MySQL, there's also a SQL Server 7.0 available. So what the client told me was a standard LAMP configuration is actually a really rusty, ancient WIMP.
Jesus Fuck.
There's nothing wrong with running PHP on IIS, but ... IIS4 shouldn't even exist anymore. They're running Windows Fucking NT Fucking 4. (Windows 2000 shipped with IIS 5.)
-
@ltouroumov said:
It felt the same after trying ROR !
but without the part where microsoft drains my bank account to buy licenses
Fight the power.
-
@blakeyrat said:
@ltouroumov said:
It felt the same after trying ROR !
but without the part where microsoft drains my bank account to buy licenses
Fight the power.
well basically because i DON'T have the budget for: a microsoft server + licences + visual studio + sql server + whatever other things i need
(and also because ruby is really cool)
-
@stratos said:
OWASP says that injection is currently the #1 vulnerability for web sites. Just because a lot of people talk about it doesn't mean it will be solved. Injection is a lot like password management in that a lot of people have their own bad implementation and think their just fine.Yay another thread about the least important part of securing your website.
I don't understand the obsession people have with this. There are a thousand things more important for security then hashing your passwords, yet it's the only thing this forum is capable of discussing apparently, at least on a regular basis that is.
I'm just going to blame over awareness. People have been hammering on its importance too long and now it's the first thing anyone thinks about when thinking of security. A bit similar to SQL injection, which thankfully has died away a bit.
-
@ltouroumov said:
I have a $100,000 VMware cluster that I bought $6,000 of Microsoft licenses for. Since I bought Datacenter edition, I can fill the cluster up with VMs running ASP.Net until it chokes. Microsoft server licenses are not that expensive. On the other hand, SQL Server is getting a bit pricey. But, if my choices were to pay for SQL Server or run MySQL for free, I'd pay every time.It felt the same after trying ROR !
but without the part where microsoft drains my bank account to buy licenses
-
@ltouroumov said:
well basically because i DON'T have the budget for: a microsoft server + licences + visual studio + sql server + whatever other things i need
I rent my servers from Amazon, and they worry about licenses. (I mean, I'm paying for them indirectly, but it's still cheap so I don't care.) As for VS, I just use the Express version which has everything I need in it, and is free.
@ltouroumov said:
(and also because ruby is really cool)
I'll take your word for that. I tried to get into it once, but it was a few years back and all the tutorials used MySQL, which basically gives me a throbbing headache if I even think about using that POS database. So... yeah. (Seriously, I've been meaning to look into RoR again, just haven't had time.)
-
@lolwtf said:
glibc has a potential excuse - C doesn't support such nice things as optional/variable parameters, and they were hacking this functionality into an existing API that they couldn't really go about changing. PHP's problem is that things are generally just direct mappings to the original API, rather than using the language's features to handle such insanity internally.
I can see wanting to keep compatibility with code ported from C, but that doesn't mean you can't add a crypt_sane() or something that handles the API better.glibc's best excuse is that it was trying to hack something better than DES into the existing /etc/shadow format (which, having borrowed /etc/passwd's hashing mechanism, was already a few years behind the curve). Shadow passwords require the salt be stored with the password, and storing the hash algorithm in the string lets you mix algorithms within the same shadow file. In addition, most implementations will strip off any parts of the salt that don't make sense when doing the evaluation (e.g. "QWERTYUIO" as salt becomes "QW" and "$1$QWERTYUI$OPASDFGHJKLZXCVBNM" becomes "$1$QWERTYUI$"). So, legacy code evaluating strcmp(crypt(password,hash),hash) mostly just works, which is quite helpful in this exact use case.
That said, no, none of the above makes it a good general-purpose solution for storing passwords. You could argue that the real WTF is that PHP implemented a function that's only really useful if you have read access to /etc/shadow, but I might then argue that the real WTF is any assumption that the PHP language was truly was "designed" from the get-go.
(Others have suggested useful solutions like mcrypt; I'm just defending libc's honor, here.)
-
@Jaime said:
@stratos said:
I'm just going to blame over awareness. People have been hammering on its importance too long and now it's the first thing anyone thinks about when thinking of security. A bit similar to SQL injection, which thankfully has died away a bit.
OWASP says that injection is currently the #1 vulnerability for web sites. Just because a lot of people talk about it doesn't mean it will be solved. Injection is a lot like password management in that a lot of people have their own bad implementation and think their just fine.I wasn't talking about the existence of the flaw, I was talking about the mindless jammering about the problem.
@morbiuswilters said:
...
I actually think the current focus if any focus should exist should be on CSRF. Especially with AJAX stuff and REST interfaces becoming more prominent this becomes easier and easier to exploit without good protection.
We haven't had many big exploits in the wild, well perhaps that router attack a while back, but beyond that only click jacking really got in the picture with a few twitter exploits and the likes.
-
@Jaime said:
OWASP says that injection is currently the #1 vulnerability for web sites.
Yeah. And you won't find a single person here who doesn't know how to do that shit correctly. Hence there's no point yelling about it. All the people throwing around unsanitized strings willy nilly are beyond the reach of TDWTF because they're ignorant as fuck. Damn near every programmer has their own conflicting set of ideas about password hashing and there's virtually no consensus except among actual security people - where the general consensus is "(time) Expensive is better." - which leaves bcrypt as the frontrunner.
-
I'm no expert on this topic, and I do have a project with a security audit coming up, so.
- Blowfish is symmetric i.e. decryption (not just hash-matching) is possible, which is at least theoretically bad if you don't need/want that, right?
- I understand the concept of dictionary-attacking a one-way hash, but how much slower is Blowfish compared to other methods?
I'm currently using SHA1 as it appeared to be the best option built into the stack (ASP.NET 3.5 in this case).
-
@blakeyrat said:
There's nothing wrong with running PHP on IIS, but ... IIS4 shouldn't even exist anymore. They're running Windows Fucking NT Fucking 4. (Windows 2000 shipped with IIS 5.)
I have a Firefox extension that puts the server string in my status bar and still see more IIS4 servers than IIS5 for some reason. The main IIS4 server I remember (auspost.com.au) was recently upgraded to IIS6.
-
@Weng said:
Morbs, if for some unfathomable reason I find myself in the reprehensible position of being in the same place as you,
He'll be like "Hey".
And you'll look around, confused, wondering, "Did I hear someone say Hey?"
And then you'll look down and be all, "Oh hey Morbs!"
-
@Who_the_Fuck said:
Of course, 160-bit is SHA1. You're looking at a 448-bit space, and I'm looking at 512 bits. I find myself concerned with this for a few reasons:
I was referring to the plaintext, not the hash. But I did mean 160 bits (although even 160 bytes is short enough to make collisions near impossible).
@Who_the_Fuck said:
I've *had* an account compromise because my 26 character password hashed via SHA1 had a collision with a (IIRC) 4 char string, and someone found it by brute-forcing the hash.
You are full of shit. Most likely, it was compromised some other way. Brute-forcing a hash collision with a maximum plaintext length of around 20 bytes would require so much computational power it's more likely you'd guess an AES-128 key. What is far, far, far more likely is that somebody just brute-forced your actual password. If it was hashed with MD5 or SHA, this is quite do-able.
@Who_the_Fuck said:
It's not like it's a separate attack vector: if the attacker manages to break the hash, they don't find out whether they hit a collision or the 'real' value. So they're not trying anything different to do this. If anything, it's easier than generating a hash collision with several MB file.
Of course it's easier to generate a hash collision with a several MB file. Since it's a password, though, with a maximum length, this is not at all relevant. Obviously, you don't want to use a password hashing scheme where collisions are trivial to generate, but even lowly MD5 is good enough to make this near-impossible. The real, primary concern of password hashing (once you've made hash collisions a non-issue by using a cryptographic hashing scheme, and once you've made pre-compute attacks a non-issue by using per-user salts) is that someone is going to guess the actual password via brute force. This is several orders of magnitude easier than generating a hash collision (which, by the way, doesn't give the attacker your actual password so the only compromise is to your login in this software and not anywhere else you might use the same password). Even assuming you are telling the truth, it's anecdotal and meaningless. Mathematically, the risk of brute forcing the real password is far larger than the risk of engineering a hash collision. It's as if you left the door to your house unlocked and somebody robbed you by sealing themselves in the foundation when the house was built and emerging 10 years later when you were at work: now you've become convinced that the best way to protect your home from robbery is by studiously x-raying every square inch of your foundation, even while you still insist on leaving your door unlocked. Real security is about trade-offs and probabilities and you are on the wrong side of the numbers here.
@Who_the_Fuck said:
I've worked through the math, and realize that if one is using a password longer than the hash bits, and the hash does not encode length, there's usually going to be at least one shorter password that'll match the hash. (If the hash *does* encode length, that's a completely separate issue, but more for those who use short passwords - that's not me, so it's not really my concern.)
So every cryptographer is wrong: hash collisions are the new biggest threat to password hashing, and brute-force and dictionary attacks are insignificant. That God we have a mildly retarded man posting anonymously to a message board to set the experts straight. Can you also tell us how it's possible to generate free electricity from water and spirit energy but your work was suppressed by the oil companies?
@Who_the_Fuck said:
Using SHA512, I can theoretically safely use passwords up to 64 characters - which is more than I'd do. But sometimes I'll go for a 50 character passphrase. Since I don't count characters when creating the passphrases, that's a bit too close to the 56 byte limit for bcrypt for my comfort. And so long as my password/passphrase is over 20 characters, I don't *care* if some cracker's running through possibilities at 500 billion per second. Yeah, with a 'b'. We're talking about over 2^126 possibilities here (since my passwords have more than 64 characters to choose from), and that'll take over 2^87 seconds to run through. Odds are, the password would be found in the first half of that, so well over 2^80 seconds to break the password. I plan on changing it before that time expires. Also, I plan on expiring before that time expires.
Nobody gives a fuck if your password is 50 characters long. The entire point is to protect weak passwords, dipshit. Software developers take the responsibility of protecting their users' information as best as possible. Security-savvy users are going to use long, randomly-generated passwords that are unique to that service. What's the benefit of even hashing them, then? The reason passwords are hashed is to prevent a compromise of one service's password database from permitting compromise of other services where the same password was used. (A much smaller, fringe benefit is that a compromise of the password database doesn't allow an attacker to just plug the plaintext passwords into the login field and go crazy. However, that's of marginal utility, because if somebody has compromised your password database it's likely they've got access to cookies which would possibly allow them to hijack your session or even just the raw data the application itself is trying to protect. The point is, thinking passwords are hashed to prevent an attacker who gains access to the password DB from logging in to the service is rather simplistic thinking of an attack vector that is far less important than the "using the password to compromise other services" angle.)
@Who_the_Fuck said:
However, in the end, the advantage of bcrypt is basically you can safely have a password that is one or two characters shorter than you can with SHA512. I'd rather have my website allow many simultanious logins while responding relatively quickly, and require my users to type in a couple extra characters.
The CPU overhead of bcrypt is significantly more than MD5/SHA, but if it's actually causing performance problems then your software fucking sucks. As for "requiring your users to type in a couple extra characters".. are you actually saying that you set a minimum password length longer than 56 bytes? What in the fuck? Regardless, you haven't proven anything. Hash collisions are a trivial concern compared to the very real possibility of brute-forcing of the actual password. bcrypt protects against the latter far better than even SHA512. And I suppose SHA512 is slightly less likely to suffer from the former if your password is over 56 motherfucking bytes. To return to the home security analogy: your front door is an unlocked screen door, your windows are left wide open even when you aren't home, but goddamn you are proud that the air vent 20-feet up on the side of the house has thick steel bars to prevent any burglar from crawling through your air shafts. Good fucking job, retard.
-
@emurphy said:
Blowfish is symmetric i.e. decryption (not just hash-matching) is possible, which is at least theoretically bad if you don't need/want that, right?
It's still a type of hashing algorithm, it just uses a symmetric cipher as the basis. To answer your concern: no, it's not any more possible to "decrypt" a bcrypt hash than it is a SHA hash.
@emurphy said:
I understand the concept of dictionary-attacking a one-way hash, but how much slower is Blowfish compared to other methods?
A lot. Just on a lark, I decided to write a little Ruby script that ran through 100k rounds of SHA1 and bcrypt. Of course, they were both hashing the same plaintext and they were run independently of each other. This was run on my laptop, which has something like a 2ghz dual core proc. SHA1 ran through 100k rounds in 0.603s. bcrypt took so fucking long doing 100k rounds that I scaled it back to 1000 rounds, which still took 173s. Extrapolating, it would take 17300s to run 100k iterations of bcrypt, making bcrypt a little over 28,000 times slower. (In the interests of fairness, I re-ran SHA1 with 1000 iterations to make sure my assumption was correct: it completed in 0.064s, which is not 100 times faster. This is likely due to the SHA1 runs completing so quickly that the start-up time of Ruby itself came into play.)
Of course, this is hardly the most scientific of tests. However, another thing to note is that the Ruby implementation of SHA1 is going to be comparatively slow. Much faster, hardware-level implementations exist which would push the number of hashes per second much, much higher. Of course, the Ruby implementation of bcrypt is hardly the fastest, either, but algorithmic differences make the optimizations possible in bcrypt much smaller in magnitude.
Finally, it took my lowly laptop 1.7s to run through 10 bcrypt hashes. For an application (web or not) that is not much CPU time. How many logins are you really going to be verifying per minute? Even if it's hundreds, you likely already have significant hardware to handle that level of traffic, and the overall percentage of requests which kick off a bcrypt run would be small, thus the impact on CPU would be small. Additionally, you might be concerned about denial-of-service attacks hammering the login form. Hopefully, your app already implements a throttling mechanism to prevent automated hammering of the login, but if not this becomes more important as it would be possible for a motivated attacker to repeatedly hit the login page in an attempt to drive up CPU time and create a DoS condition.
-
@emurphy said:
Blowfish is symmetric i.e. decryption (not just hash-matching) is possible, which is at least theoretically bad if you don't need/want that, right?
It uses the password to generate an encryption key and encrypts the salt with that key, the resulting ciphertext is the hash. You can't simply decrypt it because you would need the password to do so.This is where I don't get a 100% warm and fuzzy using Blowfish for password hashing... I don't know how secure it is against the scenario where you have the plaintext and ciphertext and you want to derive the key. Stretching an SHA algorithm seems to me to be using an algorithm as it was designed, so the core cryptanalysis holds. I feel the Blowfish technique would need some cryptanalysis by someone a lot smarter than me before I completely trust it. The fact that it hasn't been broken yet isn't good enough.
-
@bertram said:
@dhromed said:
Your post count is 1. I don't think you have this kind of flaming clout just yet.
Your post count is 4,532. I don't think you have much going on in your life just yet.
-
@Jaime said:
This is where I don't get a 100% warm and fuzzy using Blowfish for password hashing... I don't know how secure it is against the scenario where you have the plaintext and ciphertext and you want to derive the key. Stretching an SHA algorithm seems to me to be using an algorithm as it was designed, so the core cryptanalysis holds. I feel the Blowfish technique would need some cryptanalysis by someone a lot smarter than me before I completely trust it. The fact that it hasn't been broken yet isn't good enough.
Modern ciphers tend to be secure against known-plaintext attacks. There are some weaknesses when using less than the full 16 rounds, but it also requires numerous plaintexts encrypted with the same key. There are no known known-plaintext weaknesses in blowfish, making it as secure in this regard as AES.
-
The biggest threat to password security is actually that 99% of the things asking for a password don't really need one. If everything in your life has locks on it, you're much more likely to leave the important things unlocked, or (the analogy stretching here like a hobbit trying to change a lightbulb) fit the same lock to everything.
The best standard password system we could have would only accept three-digit numerical passwords. No-one (or not many people, there's always one) would be stupid enough to use that for anything that needs to be secure, and there's no way that cracking, guessing, extorting, or otherwise divining the password will allow access to anything important. If the whole point is to secure the information your users are giving you, then don't ask them a question that's likely to lead to them telling you the password they use for everything.
-
Funny thing happened to me yesterday. My father lent me a suitcase and a combination lock as I'm going on vacation.
Turns out the 3-digit combination he had on that lock, picked completely at random, or so he tells me, matches exactly the combination I use on my gym locker.
What are the odds of that?
-
@Zecc said:
What are the odds of that?
1 in 1 000 000
That's sarcasm, right?
Just making sure.
You never know.
¬_¬
-
I never could quite get my head around probabilities.
1/1000 was my first intuition, yes, but then somehow 1/1000000 sounded better. But now on third thought 1/1000 seems to be the right answer.
1/1000000 would be the probability of us both having a certain combination, but what the combination is doesn't really matter in this case, only that it's a match.
-
Simple probabilities like this (which we're assuming is completely random and don't have any Bayesian relationships with other events) are trivial to calculate. Each digit has an independent 1 in 10 chance of matching a given digit, so to match the other 3-digit combination it's 1/10 * 1/10 * 1/10 = 1/1000.
As you said, if there was a third platonic ideal combination that both combination had to match, it would then be (1/10) ^ 6. But that would be silly.
-
@Xyro said:
Each digit has an independent 1 in 10 chance of matching a given digit, so to match the other 3-digit combination it's 1/10 * 1/10 * 1/10 = 1/1000.
I prefer to think there's 1000 different numbers between 000 and 999, but that works too
-
@Xyro said:
Simple probabilities like this (which we're assuming is completely random and don't have any Bayesian relationships with other events) are trivial to calculate. Each digit has an independent 1 in 10 chance of matching a given digit, so to match the other 3-digit combination it's 1/10 * 1/10 * 1/10 = 1/1000.
As you said, if there was a third platonic ideal combination that both combination had to match, it would then be (1/10) ^ 6. But that would be silly.
Depends on how the lock works. If it's a L/R/L type, you can't spin it right to 8, then left back to 8. There would be a certain number of impossible combinations that couldn't physically be used.
You need to know how the lock works before you can talk about probabilities.
-
@blakeyrat said:
You need to know how the lock works before you can talk about probabilities.
Good point; when I heard "suitcase", I was thinking of this for some reason: [url]http://www.briefcases.us/images/briefcase-lock-480.jpg[/url] ... except oh wait that's not a suitcase, that's a briefcase. Ah, mornings!
-
@Xyro said:
@blakeyrat said:
You need to know how the lock works before you can talk about probabilities.
Good point; when I heard "suitcase", I was thinking of this for some reason: http://www.briefcases.us/images/briefcase-lock-480.jpg ... except oh wait that's not a suitcase, that's a briefcase. Ah, mornings!Well, two points:
1) I used to use an aluminum briefcase with a lock like that (but 4 digits), and it also had a certain number of impossible combinations. If I remember correctly, it wouldn't allow combinations that were one digit straight across like 1-1-1-1, 5-5-5-5, 3-3-3-3, etc. I know for sure that 0-0-0-0 wasn't allowed. So... I'm still not saying anything without knowing how the lock works.
2) If you're using one of those on your luggage, you might as well not bother with a lock at all. The type of people who break into luggage don't care if they break your lock or not, and those locks can be broken in a fraction of a second-- if you're going to lock up, use a sturdy-looking lock so they'll skip your suitcase and go for the shitty lock next door. As is, you're just relying on luck to keep goons out of your luggage anyway, in which case you might as well not bother with a lock.
-
@Zecc said:
@Xyro said:
Each digit has an independent 1 in 10 chance of matching a given digit, so to match the other 3-digit combination it's 1/10 * 1/10 * 1/10 = 1/1000.
I prefer to think there's 1000 different numbers between 000 and 999It is the same thing.
1/10 * 1/10 * 1/10 = 1 / 10*10*10
-
@Xyro said:
I was referring to multiple-dial locks, not single-dial. Like the one Xyro thought about, except in padlock shape and not built into the luggage.@blakeyrat said:
You need to know how the lock works before you can talk about probabilities.
Good point; when I heard "suitcase", I was thinking of this for some reason: http://www.briefcases.us/images/briefcase-lock-480.jpg ... except oh wait that's not a suitcase, that's a briefcase. Ah, mornings!
@blakeyrat said:If you're using one of those on your luggage, you might as well not bother with a lock at all. The type of people who break into luggage don't care if they break your lock or not, and those locks can be broken in a fraction of a second-- if you're going to lock up, use a sturdy-looking lock so they'll skip your suitcase and go for the shitty lock next door.
Another good point. Not to mention it's possibly easier to cut through the luggage material than to break the lock. That why I carry light and keep the suitcase by my hand.
@dhromed said:It is the same thing.1/10 * 1/10 * 1/10 = 1 / 10*10*10
I know that. It's just a mental shortcut.
-
@Xyro said:
Simple probabilities like this (which we're assuming is completely random and don't have any Bayesian relationships with other events) are trivial to calculate.
If we're really going for a bit more accuracy, we should take into account that his dad isn't a random person. What's the probability of him coming into contact (concerning the lock) with his dad sooner than with a random person? The higher that one is, the smaller the odds of same combination become.
To compare, you having the same code as the president of the USA is almost precisely 1000, because the president is basically a random purpose, unless you work at the white house.
All in all, you havingthe same combinatiog as someone else is practically 1, because I'm sure there are many, many, many\d{3} locks out there.
The odds of you having the same combo as your dad might be a lot smaller than 1/1000, because he is now, according to the problem statement, a non-random person, and thus has a non-equal probability.
-
@Zecc said:
@dhromed said:
It is the same thing.1/10 * 1/10 * 1/10 = 1 / 10*10*10
I know that. It's just a mental shortcut.You're a liar.
Liar.
>:(
-
@Zecc said:
I was referring to multiple-dial locks, not single-dial. Like the one Xyro thought about, except in padlock shape and not built into the luggage.
I knew I was getting those telepathic vibes from somewhere.
@dhromed said:
All in all, you havingthe same combinatiog as someone else is practically 1, because I'm sure there are many, many, many\d{3} locks out there.
Usually those kinds of locks are not set by the user, however. As such, even though father and son share similar influences and combination locks, the factors responsible for the combination sequence are assumed to be random. That is, each encounter with a new lock is like a random encounter, even if the lock is owned by a non-random person.The odds of you having the same combo as your dad might be a lot smaller than 1/1000, because he is now, according to the problem statement, a non-random person, and thus has a non-equal probability.
Nevertheless, we should also note the enormous psychological effects of catching similar sequences as well. One has surely seen tens or perhaps even hundreds of combination locks and other sequences that do not have the same sequence as the gym locker, and naturally one thinks nothing of it. Only when the sequence is the same does it suddenly feel odd and improbable.
-
@Xyro said:
Usually those kinds of locks are not set by the user, however.
Not the case. At least, mine was set by me. And I know my father's is user-settable.@Xyro said:One has surely seen tens or perhaps even hundreds of combination locks and other sequences that do not have the same sequence as the gym locker, and naturally one thinks nothing of it. Only when the sequence is the same does it suddenly feel odd and improbable.
I only have one father, as far as I can tell.I think it's more the case of us having a tendency to pick similar numbers.
-
Definitely lower than 1/1000 then!
-
@Xyro said:
<font size="1">(I assume you meant higher than 1/1000)</font>Definitely lower than 1/1000 then!
See, that's the kind of thing I don't get about probability theory.
"My father and I have the same 3-digit combination"
"Oh, there's a 1 / 1000 probability of that happening"
"And btw, the digital root is 7"
"Oh, in that case the probability raises to 1 / 110 (since you aren't idiots who use 007)"
WTF?
-
@Zecc said:
Not to mention it's possibly easier to cut through the luggage material than to break the lock. That why I carry light and keep the suitcase by my hand.
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss
-
Bear in mind that the results of asking people to pick a three digit number are not in any way random.
-
@Zecc said:
@Xyro said:
Higher, lower, it's all the same in the end. Yeah, I meant the lower number would be lower, which would make it higher. >.>Definitely lower than 1/1000 then!
<font size="1">(I assume you meant higher than 1/1000)</font>The arithmetic of probability is fairly straightforward, the tricky bits is plugging in all the information you have. It's easily 1/1000 assuming these digits were completely random. But they were not, which changes everything. Since both sequences were picked by two humans that share genetics, environment, and inside jokes, and other common influences, it's not at all surprising to see you both came up with the same "random" number. As dave mentioned, humans are very poor at picking random numbers. Determining the probability of all that human stuff is a study unto itself.
Anyway, I did the math (for which this post is too small to contain), and the probability is 1/27.
That also happens to be the probability of determining someone's password in under an hour if you use message digesting algorithms to hash it.
-
@davedavenotdavemaybedave said:
@Zecc said:
Hah, I'm only packing clothes. And it's not even my good underwear.Not to mention it's possibly easier to cut through the luggage material than to break the lock. That why I carry light and keep the suitcase by my hand.
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss@Xyro said:
The arithmetic of probability is fairly straightforward, the tricky bits is plugging in all the information you have.
That's exactly what bothers me in probability. Why would the fact of adding some seemingly irrelevant information, like the digital sum being 7, or the child being a boy born on a Tuesday, change probability?
-
@davedavenotdavemaybedave said:
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss
But with my gun locked up, how am I going to shoot the baggage handlers stealing my luggage?
-
@morbiuswilters said:
@davedavenotdavemaybedave said:
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss
But with my gun locked up, how am I going to shoot the baggage handlers stealing my luggage?
Just bring two guns. Duh.
-
@davedavenotdavemaybedave said:
@Zecc said:
Not to mention it's possibly easier to cut through the luggage material than to break the lock. That why I carry light and keep the suitcase by my hand.
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-lossAnd when traveling in the US also add TSA to the list of people who are interested in locked baggage.
About 8 years ago I was traveling to the US and brought with me a bunch of photographic equipment as checked luggage in a Pelican case with the nice Pelican locks on it. The case happily traveled internationally to LAX with no problems. I picked the case up and went to the domestic transit check-in (before you completely leave the international arrival terminal) and dropped it off with my other checked luggage bound for my 2 leg domestic trip across the US. Due to traveling continuously for about 28 hours I didn't immediately notice at the other end that the locks had been cut off my Pelican case. Apparently the TSA decided somewhere en-route that they wanted to inspect the inside of the case and had cut the locks off, looked around and then put the cut-off locks back into the case along with a nice pamphlet saying that my case had been inspected. I was pissed when I realized what had happened. This was in the early days of the TSA tomfoolery so it wasn't really common knowledge that the TSA would cut locks off bags - and in over 10 years of previous international flying this was the first time a lock had been cut off any of my bags. What pissed me more was that after inspecting the bag they didn't seal it up with some sort of security tie
And sometime between the TSA helpfully cutting the locks off and me receiving the bag a camera was stolen out of it (could even had been the TSA person for all I know). The upside of this act was that in a case with about $2000 of lenses, a film SLR camera, quality flash and expensive light meter, the thief stole a pissy little obsolete digital camera that was actually the cheapest thing in the case. I can only assume that he/she was either too dumb to recognize the value of the other equipment, or only could recognize a dig cam, or could only slip the dig cam into their pocket.
-
@Zecc said:
That's exactly what bothers me in probability. Why would
Generally, where they're independent, it doesn't. The boy born on a tuesday, and other similar problems, are akin to proving that 1=2 - a form of mathematical humour. Note that this is different to the Monty Hall problem, which is about conditional probability being phrased to sound independent - this is the reverse, in that independent probability is being phrased as conditional. The correct answer to the 'boy born on a tuesday', as well as the general 'two sons' problem is 0.5.
the fact of adding some seemingly irrelevant information, like the
digital sum being 7, or the child being a boy born on a Tuesday, change probability?
-
@morbiuswilters said:
http://www.armyrecognition.com/singapore_singaporean_small_heavy_weapons_uk/cis_40_mm_automatic_grenade_launcher_singapore_singaporean_army_pictures_technical_data_sheet_uk.html@davedavenotdavemaybedave said:
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss
But with my gun locked up, how am I going to shoot the baggage handlers stealing my luggage?
The CIS 40 has various mounting options for different tactical applications, the CIS 40 can be mounted on ... an integrated remote control weapon station.
-
@morbiuswilters said:
@davedavenotdavemaybedave said:
Don't forget, putting a lock on the case means 'valuables inside, come and get me' to a certain kind of baggage handler. Best solution: http://lifehacker.com/5448014/pack-a-gun-to-protect-valuables-from-airline-theft-or-loss
But with my gun locked up, how am I going to shoot the baggage handlers stealing my luggage?
The point is moot, as any baggage handler who stole your luggage would end up killing themself about 10 seconds after opening it. *shudder*
-
@Weng said:
I'm here primarily to bitch and a little bit to learn - which I've accomplished
Me too@Weng said:cuntpunching
*writes it down*
-
Cuntpunching: it's a skill.
