• EndlessRant (unregistered)
    • FIRST
    • FRIST
  • Pero perić (unregistered)

    Unique comment: first

  • warlaan (unregistered)

    It shows time and again that the human mind is not capable of understanding random. Just remember the dwtf where someone appended a random number to a guid to make sure it was REALLY unlikely to get a duplicate.

  • Anonymous Coward (unregistered)

    Those 'experts' may want to read up on the Birthday Paradox.

  • (cs) in reply to warlaan
    warlaan:
    It shows time and again that the human mind is not capable of understanding random. Just remember the dwtf where someone appended a random number to a guid to make sure it was REALLY unlikely to get a duplicate.

    It's not just random most don't understand..

    I had the following discussion yesterday with two colleagues. There was a box for recycling batteries and it said on the box:

    "Put here your used batteries: (...)alkaline batteries, cellphone batteries, other wireless equipments batteries."

    I asked my colleagues "What about batteries existing in wired equipments?" Their response "Batteries don't make sense on wired equipments". Me: "What about an UPS?"

    This is the difference between a programmer: requirements list in -> code out, and an engineer/architect/developer: requirements in -> solution out

    In today's story, the "Experts" were programmers, and not good ones at it...

  • (cs)

    FFS. WTF. And many other shortisms containing the letter F.

    The jolly[*] Experts have forgotten the most important thing about this task. The real linking information should be the device IDs. Each device needs a way of finding the device ID of its partner-to-be, in this case via the server. It is harder than pairing Bluetooth devices because it is mediated by the server, but it isn't hard. Users presumably don't want to have to enter whole device IDs, so supporting some sort of "friendly mode" number would be a requirement, but like all user-oriented friendly-mode data, it should not be the main key in any table.

    Device 1 sends its device ID to the server, and asks for a number. The server generates a number and stashes it alongside the device ID in the database, along with an expiry date/time. The number then goes down to the device. The device displays the number, and the user enters it on device 2. Device 2 sends this number and its device ID to the server. The server finds the number in the "waiting" table and transfers the pairing (combination of device IDs) to the "complete" table.

    You have some constraints:

    • The TTL of entries in the waiting table should be no longer than about five minutes, possibly less.
    • The friendly-mode numbers should be long enough to provide a reasonably low probability of collisions during generation.
    • The friendly-mode numbers should be short enough to make them easy to enter without screwing up - screwing up creates the possibility that my device will wind up paired with yours. Including at least one check digit would help, using an algorithm that makes detecting transpositions easy. (e.g. digit6 = (5digit1 + 4digit2 + 3digit3 + 2digit4 + 1*digit5) MOD 10)
    • Not implemented by Experts. Ordinary experts are OK, but not Experts.
    • You should perform your own WTF detection on my proposal, because I haven't done the deep analysis.

    I can be reasonably sure that this procedure will work better than what the Experts came up with. The uniqueness constraint only has to work for data with a TTL of five minutes or so.

    And their database-server relationship is a serious WTF as well, if one failed insert can stuff up all database activity.

    [*] "jolly" as used here does not mean "happy"...

  • (cs) in reply to edgsousa
    edgsousa:
    Me: "What about an UPS?"
    Most UPSes that I've used have had lead-acid batteries, which aren't processed by the same recycling methods as the dry-cell batteries normally used in wireless equipment.
  • Maurizio (unregistered) in reply to edgsousa

    There is a lot of music equipement that is (or can be) battery powered and it is not wireless.

  • (cs) in reply to Steve The Cynic

    I'm not saying it could be processed. I was just responding to the "batteries don't make sense in wired equipments", as well pointing the flaw in the box listing: I could put all kind of batteries (rechargeable or not). Why not an UPS battery? My wireless equipment can't have also a lead acid battery?

  • Isikyus (unregistered) in reply to edgsousa

    An example of a device which has a lead acid battery, but no wires: a car.

  • Isikyus (unregistered) in reply to Isikyus

    To clarify: I know a car has wires; but it doesn't plug into mains power.

  • Simon (unregistered)

    This discussion about the Battery Box perfectly shows what the problem with most "technical" people is: they are too literal sometimes. While it certainly is part of being a "technical" person, there are situations where being 100 percent techically correct is, well, unnecessary. This usually ends up in very abstract, generic descriptions of stuff, nobody really understands anymore. Kind of like the legalese lawyers tend to produce.

  • faoileag (unregistered) in reply to Isikyus
    Isikyus:
    To clarify: I know a car has wires; but it doesn't plug into mains power.
    You are so 20th century! In this day and age cars plug into some sorts of mains as well. I mean, if not, how would you get them recharged?
  • eVil (unregistered)

    To achieve true randomness, you need to cage an ill educated teenager, give them a phone, and hook it up to some kind of voice detection device. Then, every time you need a number, simply return the number of times they said/txted the word 'random' in an inappropriate context in the last second.

    It should give you a reasonably even distribution across the range of unsigned 32 bit integers, with no cyclical repetition.

  • Daniel (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    FFS. WTF. And many other shortisms containing the letter F.

    The jolly[*] Experts have forgotten the most important thing about this task. The real linking information should be the device IDs. Each device needs a way of finding the device ID of its partner-to-be, in this case via the server. It is harder than pairing Bluetooth devices because it is mediated by the server, but it isn't hard. Users presumably don't want to have to enter whole device IDs, so supporting some sort of "friendly mode" number would be a requirement, but like all user-oriented friendly-mode data, it should not be the main key in any table.

    Device 1 sends its device ID to the server, and asks for a number. The server generates a number and stashes it alongside the device ID in the database, along with an expiry date/time. The number then goes down to the device. The device displays the number, and the user enters it on device 2. Device 2 sends this number and its device ID to the server. The server finds the number in the "waiting" table and transfers the pairing (combination of device IDs) to the "complete" table.

    You have some constraints:

    • The TTL of entries in the waiting table should be no longer than about five minutes, possibly less.
    • The friendly-mode numbers should be long enough to provide a reasonably low probability of collisions during generation.
    • The friendly-mode numbers should be short enough to make them easy to enter without screwing up - screwing up creates the possibility that my device will wind up paired with yours. Including at least one check digit would help, using an algorithm that makes detecting transpositions easy. (e.g. digit6 = (5digit1 + 4digit2 + 3digit3 + 2digit4 + 1*digit5) MOD 10)
    • Not implemented by Experts. Ordinary experts are OK, but not Experts.
    • You should perform your own WTF detection on my proposal, because I haven't done the deep analysis.

    I can be reasonably sure that this procedure will work better than what the Experts came up with. The uniqueness constraint only has to work for data with a TTL of five minutes or so.

    And their database-server relationship is a serious WTF as well, if one failed insert can stuff up all database activity.

    [*] "jolly" as used here does not mean "happy"...

    Why use random at all? Just use sequential numbering in the temporary connection table, then remove all lines once connection has been established or the connection has timed out. That way there is no risk of collision at all and likely the user will never see a number higher than 10 (depending on how much the system is used of course).

  • faoileag (unregistered)

    This story reminds me of a company I worked for a long time ago... in order to get access to a online community, you had to call a 0900 number, listen to some gibberish for 5 minutes and then write down a PIN, which would give you 24 hours of access. The PIN had 4 digits. I told the project lead that I thought that 4 digits in my opinion was definitely not enough (I'll leave the reasons for the reader as an exercise), but was rebuffed. So I wrote a small script that automatically tried PINs on the community's login page, ran it a few times, got valid PINs in less than two hours with just a handful of users being present in the system, and sent him the script together with the results. Reluctantly he then changed the number of digits to 6.

    Lesson learned: when it comes to access code security some people have a very low risk awareness. If those people are project leads, it's up to the developer to make them see the light. Which is ok, it's your company, it's your job etc etc. But if you outsource such critical functionality to some self-acclaimed (offshore) "Experts", you will not get that feedback, because the contractor has no vested interest in getting your system airtight. He will develop to specs, and if your specs are lousy, a lousy soilution is what you'll get.

    Which is why I would never outsource: the amount of time it takes to think things through and develop watertight specs can easily be in the same region as developing the solution incrementally inhouse.

  • (cs)

    Gosh. If only the pesky framework vendors could provide some way to generate a Globally Unique ID...

    Do you know what would be good, too? Once they had found some way to devise a Globally Unique ID [ I'm gonna shorten that to "guid" (tm) ] they could maybe try encapsulating it into a type so that the experts, and us amateurs, could use it easily?

    And maybe, just maybe, in Oracle 13 or SQL Server 2016, we could get native support for this "guid" invention in the database?

    Ahhh... we can but dream...

  • Kent (unregistered)

    It seems to be one of the hardest concepts to get across to non-technical people -- and even technical people, far too often: in computer networks of any kind, you never know who you're talking to.

    People will impulsively say "oh we'll just look at the device ID" as if "problem magically solved". How will you see the device ID? "The device will send it." OK that's called trusting the user. Users can lie. Devices can lie. Software can lie.

    "But what are the chances of someone else guessing my device ID?"

    So you admit it could happen. You're just hoping it doesn't happen very often. Still, how do you want the system to behave in those rare cases when it does happen? You don't care? Random behavior? System crash? Money stolen? Which outcome do you want?

    "I don't want to think about it."

    OK, now we're getting closer to the truth. So back off a step and admit you didn't think about your "solution" either.

    1. I can guess thousands of device IDs per minute.
    2. My computer doesn't get tired. It is willing to keep guessing for years if I tell it to.
    3. I don't need to guess your ID, I only need to guess someone's ID.

    Leave designing to designers and go back to painting your toenails or whatever it is you supposedly do to add value around here.

  • Charlie (unregistered) in reply to Kent
    Kent:
    1. I can guess thousands of device IDs per minute. 2. My computer doesn't get tired. It is willing to keep guessing for years if I tell it to. 3. I don't need to guess your ID, I only need to guess someone's ID.
    2a. I can get a million bots to help me with the guessing.
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)
    ... and that delays were advancing more than the project.
    So what else were the delays advancing?
  • faoileag (unregistered) in reply to skotl
    skotl:
    If only the pesky framework vendors could provide some way to generate a Globally Unique ID...
    If I recall correctly, there are GUID libraries available.

    Solutions that can be found on the internet tend to center around a machine's MAC-address.

    MAC-addresses in a way already are guids and will all be used up in the not-too-far-away future (an extended MAC-address format is already in the planning stages, I think).

    skotl:
    And maybe, just maybe, in Oracle 13 or SQL Server 2016, we could get native support for this "guid" invention in the database?
    And why would you need that? Just use a string to store your guids.
  • (cs) in reply to Daniel
    Daniel:
    Why use random at all? Just use sequential numbering in the temporary connection table, then remove all lines once connection has been established or the connection has timed out. That way there is no risk of collision at all and likely the user will never see a number higher than 10 (depending on how much the system is used of course).
    You could do that, I suppose. I'd generally prefer to see a friendly-number generation method that doesn't just hand out serial numbers, though. We are conditioned by common usage to expect "security" keys like these numbers to be semi-long digit strings (or alphabetic, or alphanumeric, or...), and small numbers will raise our suspicions that something is up. There is also the risk if certain things go wrong of odd collisions e.g. I get distracted, and push the "let me enter a pairing code" button on my device 2 after my device 1 has timed out and after your device 1 got assigned my old number. Long numbers reduce the possibility that your device got my old number. With the small-sequential method that you suggest, it's moderately likely at busy times, and very likely at quiet times.

    Use of alphabetic or alphanumeric sequences is advantageous because the number of possible codes of a particular length is much higher than for pure decimal-numeric. Restricting the maximum length is a critical factor for the human user, while maximising the number of combinations is a critical factor for the database. 266 is larger than 108 (308915776 vs 100000000), and if you borrow one slot for a check digit, that's still 11881376 versus 10000000. If you assume that six digits / letters is the maximum usable, then I'd definitely go for alphabetic at least, maybe even alphanumeric.

    The key thing to remember is that the pairing codes are for people first and computers second. Make them align with people's expectations, not the convenience of programmers. You can also help distinguish them by including a fragment of the device ID or serial number in the code. If you extend the device ID to 8 characters, you get 6 hex characters from the bottom 24 bits of the device's MAC address and 2 full alphanumeric from the "random" process. Using full alphanumeric, you can code the bottom 24 bits of the MAC in five characters, and then add two characters of random and one check digit for the eight. Sounds like a win to me.

    (EDIT: note the assumption that the device ID is a MAC address...)

  • faoileag (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    ... and that delays were advancing more than the project.
    So what else were the delays advancing?
    The fines for late delivery of the product the "Experts" were hired to help develop?
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Isikyus
    Isikyus:
    To clarify: I know a car has wires; but it doesn't plug into mains power.
    A cell phone has wires inside it, too. And if you don't plug it into mains power every day or three, with wires, it stops working. (Unless you have one of those silly inductive pad chargers, but those still have coils of wire in them.)
  • fa2k (unregistered) in reply to Daniel
    Daniel:
    Steve The Cynic:
    Device 1 sends its device ID to the server, and asks for a number. The server generates a number and stashes it alongside the device ID in the database, [...] The device displays the number, and the user enters it on device 2.

    Why use random at all? Just use sequential numbering in the temporary connection table, then remove all lines once connection has been established or the connection has timed out. That way there is no risk of collision at all and likely the user will never see a number higher than 10 (depending on how much the system is used of course).

    I could then enter 1 on my device at any time and I could likely pair with someone else's device. That would probably be a security issue.

  • (cs) in reply to Kent
    Kent:
    It seems to be one of the hardest concepts to get across to non-technical people -- and even technical people, far too often: in computer networks of any kind, you never know who you're talking to.

    People will impulsively say "oh we'll just look at the device ID" as if "problem magically solved". How will you see the device ID? "The device will send it." OK that's called trusting the user. Users can lie. Devices can lie. Software can lie.

    "But what are the chances of someone else guessing my device ID?"

    So you admit it could happen. You're just hoping it doesn't happen very often. Still, how do you want the system to behave in those rare cases when it does happen? You don't care? Random behavior? System crash? Money stolen? Which outcome do you want?

    "I don't want to think about it."

    OK, now we're getting closer to the truth. So back off a step and admit you didn't think about your "solution" either.

    1. I can guess thousands of device IDs per minute.
    2. My computer doesn't get tired. It is willing to keep guessing for years if I tell it to.
    3. I don't need to guess your ID, I only need to guess someone's ID.

    Leave designing to designers and go back to painting your toenails or whatever it is you supposedly do to add value around here.

    Ah, so you want to add another layer of WTF to the product by introducing a security requirement that wasn't immediately apparent.

    These aren't described as e.g. secure elements for bank transactions and if they were, well, there are extensive protocols for identification and authentication of communications with such devices. All such protocols are at least resistant to simple brute force guessing, and other elements can be layered over the simple protocol in order to increase their resistance.

    Of course, the RWTF here is that they have devices that can be / are paired via a server. Bluetooth pairing by passage of PIN codes is reasonable because it is done locally, usually in the presence of trustable devices. (And, of course, if you manage to sneak in and pair with my headset when I tell it to pair, I'll notice that because my headset won't work with my phone, but will allow me to use yours to make calls if you have voice dialling...)

    You have to answer some occasionally-difficult questions, like "can I lose enough in an attack, including cost-to-fix, to justify the expense of this defence?". For the Bluetooth phone and headset, the cost of the defence had better be really close to zero, because if I wind up with my headset paired with the attacker's phone, he loses when I accidentally call some 0900 premium number, not me. That's not true if he manages to sneak in exactly the same brand+model of headset as the one I went to buy, and tricks me into pairing with his, but my defence is to not activate voice dialling (which I don't want active anyway - I've never had much success with it, so I don't see why I should burn battery life on it). And fixing the mis-pair is a simple case of repeating the pairing process until I manage to get my devices correctly paired. For a banking secure element, the cost of defending can (should) be higher because my losses are greater and the attacker's gains are higher.

  • Skandranon (unregistered) in reply to fa2k
    fa2k:

    I could then enter 1 on my device at any time and I could likely pair with someone else's device. That would probably be a security issue.

    The primary key would keep counting up even after the rows are cleared, that's why he said "probably not see a number over 10 digits".

  • Les (unregistered) in reply to Skandranon

    Nevertheless, if I mis-type the last digit, I will likely pair with a device on the system, but not the one I intended.

  • Valued Service (unregistered)

    Solution:

    Get the user to type a full GUID and stop being "user friendly" if it compromises robustness. A GUID is what it takes to ensure uniqueness, otherwise we'd have something other than a GUID.

    Device A displays GUID.

    Device B inputs GUID. Sends to server.

    Hit finish on Device A.

    Device A sends to server.

    If they match, pairing is complete.

    That way device A can't send whatever it wants to server that device B wouldn't have a way of knowing what that was.

  • (cs) in reply to Valued Service
    Valued Service:
    Solution:

    Get the user to type a full GUID and stop being "user friendly" if it compromises robustness. A GUID is what it takes to ensure uniqueness, otherwise we'd have something other than a GUID.

    Device A displays GUID.

    Device B inputs GUID. Sends to server.

    Hit finish on Device A.

    Device A sends to server.

    If they match, pairing is complete.

    That way device A can't send whatever it wants to server that device B wouldn't have a way of knowing what that was.

    You. You are what's wrong with modern application design, especially design by small teams of technical people. "No, we don't need the app to be usable -- it just has to be secure/standards compliant/inflate my ego".

    If your app required typing a 32-character length string on a smartphone correctly in less than 5 minutes, I'd probably start looking to your competitor's products, or worse, if I really needed the app and there were no alternatives, design one of my own.

    A randomly generated 6-character string with some built-in check (modulo?) is sufficiently secure (the key expires after 5 minutes anyway) and does not cause your users to loathe your application and curse it to the eighth circle of hell.

  • Christian (unregistered)

    The ID was used as a socket number for communication between the two devices. Think "remote control" pairing remote with device it should control. It was deemed safe enough as it was also checked if the same subnet is present. Not really convincing me either, but hey, I'm not the expert, right?

    The Device ID was used as a seed, and then some random number added to the seed. IE: A random number...

    The story goes on:

    After this stellar patch to which they said I have to add it to the production system before they do any more work (and so I did) I was fed up with the stupidity of this.

    I told them to simply add a check, since their code already has access to the db, to see if the generated key is present. If it is, generate a new one, repeat until you find one, stop at 10 tries and return a proper error.

    The solution we got: Look up if the key exists. If it does, throw an exception with the response from the db server from the lookup (something along the lines, 1 entry found), which a) shows up on the users screen and b) halts the entire application.

    It's sad when a Dilbert comic seems more real to you than what you experience in your job in 2013....

  • (cs) in reply to warlaan
    warlaan:
    It shows time and again that the human mind is not capable of understanding random. Just remember the dwtf where someone appended a random number to a guid to make sure it was REALLY unlikely to get a duplicate.

    The worst part is that deterministic can't be explained to most of them either.

    That's why we see code like this:

         if (a > 0)
     {
        println("The result is:" . a);
     }
     if (a > 0)  // just in case we swapped universes since the previous if
     {
        whatever;
     }
  • (cs) in reply to faoileag
    faoileag:
    skotl:
    If only the pesky framework vendors could provide some way to generate a Globally Unique ID...
    If I recall correctly, there are GUID libraries available.

    Solutions that can be found on the internet tend to center around a machine's MAC-address.

    MAC-addresses in a way already are guids and will all be used up in the not-too-far-away future (an extended MAC-address format is already in the planning stages, I think).

    skotl:
    And maybe, just maybe, in Oracle 13 or SQL Server 2016, we could get native support for this "guid" invention in the database?
    And why would you need that? Just use a string to store your guids.

    Sigh... the sarcasm was clearly wasted on you, wasn't it? I meant that every decent language / framework already supports guids (and they are no longer based on MAC addresses and the changes of any two being non-unique are infinitesimally small) and that databases already support guids as a type.

    OK, next time I will post the boring, fact-filled version rather than attempt to be pithy.

  • Daniel (unregistered) in reply to fa2k
    fa2k:
    Daniel:
    Steve The Cynic:
    Device 1 sends its device ID to the server, and asks for a number. The server generates a number and stashes it alongside the device ID in the database, [...] The device displays the number, and the user enters it on device 2.

    Why use random at all? Just use sequential numbering in the temporary connection table, then remove all lines once connection has been established or the connection has timed out. That way there is no risk of collision at all and likely the user will never see a number higher than 10 (depending on how much the system is used of course).

    I could then enter 1 on my device at any time and I could likely pair with someone else's device. That would probably be a security issue.

    Hmm, yeah, if that is a concern then sure, random would be useful. (captcha:) causa security.

  • IN-HOUSE-CHAMP (unregistered)

    DEVICE ID'S ARE NOT ALWAYS UNIQUE. MAYBE STEVE THE CYNIC NEEDS TO READ THIS.

    https://code.google.com/p/android/issues/detail?id=10603

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    For the Bluetooth phone and headset, the cost of the defence had better be really close to zero, because if I wind up with my headset paired with the attacker's phone, *he* loses when I accidentally call some 0900 premium number, not me. That's not true if he manages to sneak in exactly the same brand+model of headset as the one I went to buy, and tricks me into pairing with his, but my defence is to not activate voice dialling (which I don't want active anyway - I've never had much success with it, so I don't see why I should burn battery life on it). And fixing the mis-pair is a simple case of repeating the pairing process until I manage to get my devices correctly paired. For a banking secure element, the cost of defending can (should) be higher because my losses are greater and the attacker's gains are higher.

    This is exactly why we have such poor security in so many products: Because, "It's someone else who loses so why do I care?"

    How about if it's his headset "accidentally" paired with your phone and you're the one paying for his $20 per minute 900 number?

    And the best part is, you paid much more for that cool, luxurious, voice dialing (because you always pay more for luxury) then you would have paid for security--and you had to turn off that luxury you paid for in order to defend yourself from his attack.

    Their are a lot of anti-social people in society. That's why we have to have locks on our doors and windows; to keep those anti-social people out.

    Companies that make systems and software won't do that: If they were building a house, none of the doors or windows would have locks; anyone could just walk into the house and help themselves. And the company response? "Well, just nail all those doors and windows shut, and no problem."

  • wtferswtf (unregistered)

    What is going on in the WTF comment section?

    guid's? Are you people seriously expecting end users to fill all of that in to pair devices?

    The reason they picked a smaller number (and it's not a good reason) is because if you make it larger, the user now has to do more work.

    The WTF in this story isn't the appalling lack of statistics on display. It's this method they chose of pairing the devices in the first place.

    Despite the title, the solution to this problem is not "Try More Random"

  • RASG (unregistered) in reply to IN-HOUSE-CHAMP
    IN-HOUSE-CHAMP:
    DEVICE ID'S ARE NOT ALWAYS UNIQUE. MAYBE STEVE THE CYNIC NEEDS TO READ THIS.

    https://code.google.com/p/android/issues/detail?id=10603

    OK!!1

    STOP YELLING!!!1!

  • Valued Service (unregistered) in reply to SeySayux
    SeySayux:
    Valued Service:
    Solution:

    Get the user to type a full GUID and stop being "user friendly" if it compromises robustness. A GUID is what it takes to ensure uniqueness, otherwise we'd have something other than a GUID.

    Device A displays GUID.

    Device B inputs GUID. Sends to server.

    Hit finish on Device A.

    Device A sends to server.

    If they match, pairing is complete.

    That way device A can't send whatever it wants to server that device B wouldn't have a way of knowing what that was.

    You. You are what's wrong with modern application design, especially design by small teams of technical people. "No, we don't need the app to be usable -- it just has to be secure/standards compliant/inflate my ego".

    If your app required typing a 32-character length string on a smartphone correctly in less than 5 minutes, I'd probably start looking to your competitor's products, or worse, if I really needed the app and there were no alternatives, design one of my own.

    A randomly generated 6-character string with some built-in check (modulo?) is sufficiently secure (the key expires after 5 minutes anyway) and does not cause your users to loathe your application and curse it to the eighth circle of hell.

    You are what's wrong with any software that needs to be secure. The reason why random retail sites are exploited and easily hacked causing millions of damage to people and countless hours wasting on resolving disputes with banks and accountants and else.

    Why the hell are you pairing a smartphone over a network without just using bluetooth or some other solution? Why do you need to pair to printer to print.

    If pairing like this is the only solution, then the user better be prepared to input a significantly secure key.

    Hacking up security with a randomized 6 digit string is not a solution. Not to mention having to increase server code complexity 10 fold to ensure you don't accidentally pair up the wrong device. (Looking at you Sprint. Sending the wrong text messages to the wrong phones)

    If you don't like the solution, then look for another one, don't blame the security for being non-user-friendly.

    Go ahead, look for a competitor or write one yourself, but when your bank account is hacked and you're spending months fixing your credit score, don't come crying to me.

  • SQLServer User (unregistered) in reply to skotl

    we can dream if we are in .... 2000? because SQL Server 2005 already supports GUIDs.

  • Hasse (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    edgsousa:
    Me: "What about an UPS?"
    Most UPSes that I've used have had lead-acid batteries, which aren't processed by the same recycling methods as the dry-cell batteries normally used in wireless equipment.

    The Lead-Acid cells in the rest of the world commonly goes under the name accumulator to distinguish them from just batteries. In effect everything called a rechargeable battery is an accumulator, if not rechargeable then it is a battery.

  • SQLServer User (unregistered) in reply to skotl
    skotl:
    Gosh. If only the pesky framework vendors could provide some way to generate a Globally Unique ID...

    Do you know what would be good, too? Once they had found some way to devise a Globally Unique ID [ I'm gonna shorten that to "guid" (tm) ] they could maybe try encapsulating it into a type so that the experts, and us amateurs, could use it easily?

    And maybe, just maybe, in Oracle 13 or SQL Server 2016, we could get native support for this "guid" invention in the database?

    Ahhh... we can but dream...

    SQLServer User:
    we can dream if we are in .... 2000? because SQL Server 2005 already supports GUIDs.

    And now it make sense!

  • Geoff (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    FFS. * The friendly-mode numbers should be long enough to provide a reasonably low probability of collisions during generation.

    Really just no wrong, totally wrong. What you do is let the server generate the friendly keys. Device A calls a web service, which inturn evokes a stored procedure that works on the [dev_id, friendly-mode_num, ttl] relation. The procedure using transactions to avoid any races, returns a value that unique among non-expired ttls. The Web service sends the pairing number back to device A, user enters the number on device B

  • (cs) in reply to Valued Service
    Valued Service:
    You are what's wrong with any software that needs to be secure. The reason why random retail sites are exploited and easily hacked causing millions of damage to people and countless hours wasting on resolving disputes with banks and accountants and else.
    Did you just call me a SQL injection vulnerability? Because I believe you just did.
    If pairing like this is the only solution, then the user better be prepared to input a significantly secure key.

    Hacking up security with a randomized 6 digit string is not a solution. Not to mention having to increase server code complexity 10 fold to ensure you don't accidentally pair up the wrong device. (Looking at you Sprint. Sending the wrong text messages to the wrong phones)

    If you don't like the solution, then look for another one, don't blame the security for being non-user-friendly.

    Go ahead, look for a competitor or write one yourself, but when your bank account is hacked and you're spending months fixing your credit score, don't come crying to me.

    Congratulations on completely missing the point and showing what an utter moron you are. I wouldn't let you near any UI design, just as much as I'd would let you near any security design.

    Security is determined in function of how secure something has to be. For a bank account, sure, go ahead and ask me to type a longer string. For pairing two devices? Especially two devices with limited input capabilities?

    There is this joke about asking a user to type an 11-digit prime to continue. While admittedly very secure, coming up with an 11-digit prime is a rather compicated task for an end user. That also why we don't say "Please copy this 4096-bit coprime", which several magnitudes more secure than a measly random 128-bit number as you are suggesting.

    Security should not be something that complicates a user's interface. On the other side, user friendliness is not a good reason for a sloppy security. Your job as a designer is to find the golden mean. And apparently, you seem to be unable to do so. Any design that requires a user to remember and write down large amounts of data, especially on an interface not designed to do so, is a crappy design.

    If the application really needs to be secure, and you feel the only way is to transfer a key of significant length, why not use a QR code?

    As a software developer, I'd expect you are able to:

    a) see the problem (we need to transfer a large enough key) b) come up with a solution (let the user type a key) c) see potential problems with your solution (typing in a long key on a smartphone is very annoying) d) consider alternative solutions (shorter key? other way of transferring key?) and their respective problems.

    Since you can't seem to be able to do either c) or d) and you still want to call yourself a developer, I'd say that you're either 1) incompetent 2) unable to see your own mistakes or 3) drunk.

  • (cs)

    Of course the most random, secure method would be to have each user write the first 50 digits that they can think of in Sharpie on a busted BMW E46 window regulator (those are not in short supply) and mail it to "Secure Connections, Box 3500 Harvard Square, Cambridge, MA 02238" and wait 6-8 weeks for the other device to be paired.

  • Anymouse (unregistered) in reply to faoileag
    faoileag:
    MAC-addresses in a way already are guids
    Not even close. Anyone can change their MAC address on most modern hardware. I got a Motorola cable modem from Amazon that I could not used because its MAC address was already in use on Comcast's network.
  • verisimilidude (unregistered)

    Reminds me of rvar = rand() + rand() / 2; which was justified as twice as random as calling the function once.

  • ben (unregistered) in reply to verisimilidude

    you're missing these: ()

  • Re: Try More Random (unregistered) in reply to Coyne
    Coyne:
    Their are a lot of anti-social people in society. That's why we have to have locks on our doors and windows; to keep those anti-social people out.

    "That person doesn't want to socialize with me? I need to be damn sure he can't get into my house!"

  • (cs) in reply to Re: Try More Random
    Re: Try More Random:
    Coyne:
    Their are a lot of anti-social people in society. That's why we have to have locks on our doors and windows; to keep those anti-social people out.

    "That person doesn't want to socialize with me? I need to be damn sure he can't get into my house!"

    You're confusing anti-social with non-social.

Leave a comment on “Try More Random”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article