Proprietary RF Protocol Security












2















I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.



It states that




The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...




and




...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.




From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?










share|improve this question







New contributor




Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

























    2















    I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.



    It states that




    The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...




    and




    ...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.




    From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?










    share|improve this question







    New contributor




    Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      2












      2








      2








      I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.



      It states that




      The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...




      and




      ...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.




      From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?










      share|improve this question







      New contributor




      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.



      It states that




      The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...




      and




      ...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.




      From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?







      bluetooth






      share|improve this question







      New contributor




      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question







      New contributor




      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question






      New contributor




      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 4 hours ago









      Oliver.ROliver.R

      112




      112




      New contributor




      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Oliver.R is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          2 Answers
          2






          active

          oldest

          votes


















          2














          This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.



          The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.



          Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.



          You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.



          Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.



          So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.



          That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.






          share|improve this answer

































            1














            That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.



            Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.



            Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.



            So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.



            Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.



            A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.



            In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.






            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "162"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              noCode: true, onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });






              Oliver.R is a new contributor. Be nice, and check out our Code of Conduct.










              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201466%2fproprietary-rf-protocol-security%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              2














              This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.



              The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.



              Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.



              You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.



              Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.



              So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.



              That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.






              share|improve this answer






























                2














                This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.



                The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.



                Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.



                You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.



                Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.



                So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.



                That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.






                share|improve this answer




























                  2












                  2








                  2







                  This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.



                  The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.



                  Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.



                  You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.



                  Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.



                  So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.



                  That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.






                  share|improve this answer















                  This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.



                  The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.



                  Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.



                  You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.



                  Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.



                  So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.



                  That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 3 hours ago

























                  answered 4 hours ago









                  bashCypherbashCypher

                  1,064114




                  1,064114

























                      1














                      That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.



                      Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.



                      Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.



                      So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.



                      Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.



                      A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.



                      In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.






                      share|improve this answer




























                        1














                        That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.



                        Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.



                        Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.



                        So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.



                        Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.



                        A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.



                        In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.






                        share|improve this answer


























                          1












                          1








                          1







                          That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.



                          Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.



                          Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.



                          So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.



                          Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.



                          A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.



                          In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.






                          share|improve this answer













                          That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.



                          Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.



                          Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.



                          So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.



                          Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.



                          A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.



                          In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered 1 hour ago









                          John DetersJohn Deters

                          26.5k24088




                          26.5k24088






















                              Oliver.R is a new contributor. Be nice, and check out our Code of Conduct.










                              draft saved

                              draft discarded


















                              Oliver.R is a new contributor. Be nice, and check out our Code of Conduct.













                              Oliver.R is a new contributor. Be nice, and check out our Code of Conduct.












                              Oliver.R is a new contributor. Be nice, and check out our Code of Conduct.
















                              Thanks for contributing an answer to Information Security Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201466%2fproprietary-rf-protocol-security%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              404 Error Contact Form 7 ajax form submitting

                              How to know if a Active Directory user can login interactively

                              TypeError: fit_transform() missing 1 required positional argument: 'X'