What does “in-house hash function” mean?











up vote
33
down vote

favorite
1












In security news, I faced a new term related to hash functions: it is reported that the "in-house hash function" used in IOTA platform is broken (i.e. Curl-P hash function). You can find the complete paper introducing the vulnerability here.



But I do not understand if the term of "in-house" represents a specific type of hash function? And in general, what does "in-house" mean here?










share|improve this question




















  • 70




    I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
    – Mike Ounsworth
    Nov 21 at 14:22






  • 35




    It means the same thing that "homeowner wiring" means to electricians.
    – Eric Lippert
    Nov 21 at 20:23






  • 12




    @EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
    – Nic Hartley
    Nov 21 at 22:03






  • 2




    “in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
    – Mawg
    Nov 22 at 13:03















up vote
33
down vote

favorite
1












In security news, I faced a new term related to hash functions: it is reported that the "in-house hash function" used in IOTA platform is broken (i.e. Curl-P hash function). You can find the complete paper introducing the vulnerability here.



But I do not understand if the term of "in-house" represents a specific type of hash function? And in general, what does "in-house" mean here?










share|improve this question




















  • 70




    I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
    – Mike Ounsworth
    Nov 21 at 14:22






  • 35




    It means the same thing that "homeowner wiring" means to electricians.
    – Eric Lippert
    Nov 21 at 20:23






  • 12




    @EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
    – Nic Hartley
    Nov 21 at 22:03






  • 2




    “in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
    – Mawg
    Nov 22 at 13:03













up vote
33
down vote

favorite
1









up vote
33
down vote

favorite
1






1





In security news, I faced a new term related to hash functions: it is reported that the "in-house hash function" used in IOTA platform is broken (i.e. Curl-P hash function). You can find the complete paper introducing the vulnerability here.



But I do not understand if the term of "in-house" represents a specific type of hash function? And in general, what does "in-house" mean here?










share|improve this question















In security news, I faced a new term related to hash functions: it is reported that the "in-house hash function" used in IOTA platform is broken (i.e. Curl-P hash function). You can find the complete paper introducing the vulnerability here.



But I do not understand if the term of "in-house" represents a specific type of hash function? And in general, what does "in-house" mean here?







hash terminology






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 at 16:44









Anders

48.5k22139158




48.5k22139158










asked Nov 21 at 14:06









sas

509148




509148








  • 70




    I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
    – Mike Ounsworth
    Nov 21 at 14:22






  • 35




    It means the same thing that "homeowner wiring" means to electricians.
    – Eric Lippert
    Nov 21 at 20:23






  • 12




    @EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
    – Nic Hartley
    Nov 21 at 22:03






  • 2




    “in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
    – Mawg
    Nov 22 at 13:03














  • 70




    I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
    – Mike Ounsworth
    Nov 21 at 14:22






  • 35




    It means the same thing that "homeowner wiring" means to electricians.
    – Eric Lippert
    Nov 21 at 20:23






  • 12




    @EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
    – Nic Hartley
    Nov 21 at 22:03






  • 2




    “in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
    – Mawg
    Nov 22 at 13:03








70




70




I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
– Mike Ounsworth
Nov 21 at 14:22




I believe the definition of "In-house hash function" is "Don't use our product, we have no idea what we're doing". (see Steffen's answer for a less cheeky response)
– Mike Ounsworth
Nov 21 at 14:22




35




35




It means the same thing that "homeowner wiring" means to electricians.
– Eric Lippert
Nov 21 at 20:23




It means the same thing that "homeowner wiring" means to electricians.
– Eric Lippert
Nov 21 at 20:23




12




12




@EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
– Nic Hartley
Nov 21 at 22:03




@EricLippert Be fair. There's less of a chance of a catastrophic fire and loss of life with homeowner wiring.
– Nic Hartley
Nov 21 at 22:03




2




2




“in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
– Mawg
Nov 22 at 13:03




“in-house” is a term which, if heard several times at an interview causes one to lose desire to be offered the job. Generally speaking, “in-house” can be seen as the polar opposite of “industry standard”.
– Mawg
Nov 22 at 13:03










3 Answers
3






active

oldest

votes

















up vote
91
down vote



accepted










From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".



Here it means developing your own hash algorithm instead of using a public one. Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.



See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.






share|improve this answer



















  • 73




    Hearing "in-house" with anything security related is always a HUGE red flag.
    – Marie
    Nov 21 at 16:35






  • 7




    And hearing "in-house" with anything crypto related is an even larger red flag even more often.
    – NieDzejkob
    Nov 21 at 21:47






  • 1




    Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
    – jpmc26
    Nov 21 at 21:49










  • In short, in this context, "in-house" means "trouble"!
    – Muzer
    Nov 22 at 9:53


















up vote
3
down vote













In the context of cryptography "in-house" is a synonym for "questionable origin and unverified strength".



It specifically means that they developed their own hashing function (or in other cases encryption, key-exchange scheme, etc.).



This, in cryptography, is a Bad Idea with capital letters. While developing your own library of common functions or your own webservice framework or whatever can have a perfectly good use-case, cryptography is one of the fields where a tiny mistake can make the whole thing incredibly fragile in a way that you will never find out. If you build your own webserver ("our high-performance in-house webserver...") and there's a problem, you have a good chance of finding out sooner rather than later because it crashes, or sends the wrong files, or performs badly. But if your crypto algorithm has a problem that destroys its cryptographic strength, you have to be very lucky that someone who breaks it actually tells you. The people who try to break it are almost certain to be attackers, because very few cryptographers waste their time on some in-house crypto hack. They know to stick with public algorithms where it actually matters if they find something, to more than one company.






share|improve this answer




























    up vote
    -13
    down vote













    I agree with the answer given an hour before this one about in-house meaning, "non-standard and probably not very sophisticated or rugged." There may still be one argument in favor of using an in-house hash. That is, it may be different enough from the standard ones out there that a hacker may decide it is too much work to figure out how to reverse engineer it. Even if you accept this argument, this sort of do-it-yourself approach should only ever be used to protect very low-value data.






    share|improve this answer

















    • 30




      This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
      – Zefiro
      Nov 21 at 18:21






    • 7




      It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
      – Tom W
      Nov 21 at 19:04






    • 1




      @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
      – supercat
      Nov 21 at 19:52






    • 2




      @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
      – David Schwartz
      Nov 21 at 20:14








    • 2




      @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
      – Nic Hartley
      Nov 21 at 22:06











    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',
    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
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198134%2fwhat-does-in-house-hash-function-mean%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    91
    down vote



    accepted










    From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".



    Here it means developing your own hash algorithm instead of using a public one. Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.



    See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.






    share|improve this answer



















    • 73




      Hearing "in-house" with anything security related is always a HUGE red flag.
      – Marie
      Nov 21 at 16:35






    • 7




      And hearing "in-house" with anything crypto related is an even larger red flag even more often.
      – NieDzejkob
      Nov 21 at 21:47






    • 1




      Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
      – jpmc26
      Nov 21 at 21:49










    • In short, in this context, "in-house" means "trouble"!
      – Muzer
      Nov 22 at 9:53















    up vote
    91
    down vote



    accepted










    From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".



    Here it means developing your own hash algorithm instead of using a public one. Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.



    See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.






    share|improve this answer



















    • 73




      Hearing "in-house" with anything security related is always a HUGE red flag.
      – Marie
      Nov 21 at 16:35






    • 7




      And hearing "in-house" with anything crypto related is an even larger red flag even more often.
      – NieDzejkob
      Nov 21 at 21:47






    • 1




      Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
      – jpmc26
      Nov 21 at 21:49










    • In short, in this context, "in-house" means "trouble"!
      – Muzer
      Nov 22 at 9:53













    up vote
    91
    down vote



    accepted







    up vote
    91
    down vote



    accepted






    From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".



    Here it means developing your own hash algorithm instead of using a public one. Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.



    See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.






    share|improve this answer














    From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".



    Here it means developing your own hash algorithm instead of using a public one. Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.



    See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 21 at 16:26

























    answered Nov 21 at 14:16









    Steffen Ullrich

    112k12195258




    112k12195258








    • 73




      Hearing "in-house" with anything security related is always a HUGE red flag.
      – Marie
      Nov 21 at 16:35






    • 7




      And hearing "in-house" with anything crypto related is an even larger red flag even more often.
      – NieDzejkob
      Nov 21 at 21:47






    • 1




      Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
      – jpmc26
      Nov 21 at 21:49










    • In short, in this context, "in-house" means "trouble"!
      – Muzer
      Nov 22 at 9:53














    • 73




      Hearing "in-house" with anything security related is always a HUGE red flag.
      – Marie
      Nov 21 at 16:35






    • 7




      And hearing "in-house" with anything crypto related is an even larger red flag even more often.
      – NieDzejkob
      Nov 21 at 21:47






    • 1




      Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
      – jpmc26
      Nov 21 at 21:49










    • In short, in this context, "in-house" means "trouble"!
      – Muzer
      Nov 22 at 9:53








    73




    73




    Hearing "in-house" with anything security related is always a HUGE red flag.
    – Marie
    Nov 21 at 16:35




    Hearing "in-house" with anything security related is always a HUGE red flag.
    – Marie
    Nov 21 at 16:35




    7




    7




    And hearing "in-house" with anything crypto related is an even larger red flag even more often.
    – NieDzejkob
    Nov 21 at 21:47




    And hearing "in-house" with anything crypto related is an even larger red flag even more often.
    – NieDzejkob
    Nov 21 at 21:47




    1




    1




    Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
    – jpmc26
    Nov 21 at 21:49




    Also see Is my developer's home-brew password security right or wrong, and why?, although I suspect Dave's algorithm was much, much worse than IOTA's.
    – jpmc26
    Nov 21 at 21:49












    In short, in this context, "in-house" means "trouble"!
    – Muzer
    Nov 22 at 9:53




    In short, in this context, "in-house" means "trouble"!
    – Muzer
    Nov 22 at 9:53












    up vote
    3
    down vote













    In the context of cryptography "in-house" is a synonym for "questionable origin and unverified strength".



    It specifically means that they developed their own hashing function (or in other cases encryption, key-exchange scheme, etc.).



    This, in cryptography, is a Bad Idea with capital letters. While developing your own library of common functions or your own webservice framework or whatever can have a perfectly good use-case, cryptography is one of the fields where a tiny mistake can make the whole thing incredibly fragile in a way that you will never find out. If you build your own webserver ("our high-performance in-house webserver...") and there's a problem, you have a good chance of finding out sooner rather than later because it crashes, or sends the wrong files, or performs badly. But if your crypto algorithm has a problem that destroys its cryptographic strength, you have to be very lucky that someone who breaks it actually tells you. The people who try to break it are almost certain to be attackers, because very few cryptographers waste their time on some in-house crypto hack. They know to stick with public algorithms where it actually matters if they find something, to more than one company.






    share|improve this answer

























      up vote
      3
      down vote













      In the context of cryptography "in-house" is a synonym for "questionable origin and unverified strength".



      It specifically means that they developed their own hashing function (or in other cases encryption, key-exchange scheme, etc.).



      This, in cryptography, is a Bad Idea with capital letters. While developing your own library of common functions or your own webservice framework or whatever can have a perfectly good use-case, cryptography is one of the fields where a tiny mistake can make the whole thing incredibly fragile in a way that you will never find out. If you build your own webserver ("our high-performance in-house webserver...") and there's a problem, you have a good chance of finding out sooner rather than later because it crashes, or sends the wrong files, or performs badly. But if your crypto algorithm has a problem that destroys its cryptographic strength, you have to be very lucky that someone who breaks it actually tells you. The people who try to break it are almost certain to be attackers, because very few cryptographers waste their time on some in-house crypto hack. They know to stick with public algorithms where it actually matters if they find something, to more than one company.






      share|improve this answer























        up vote
        3
        down vote










        up vote
        3
        down vote









        In the context of cryptography "in-house" is a synonym for "questionable origin and unverified strength".



        It specifically means that they developed their own hashing function (or in other cases encryption, key-exchange scheme, etc.).



        This, in cryptography, is a Bad Idea with capital letters. While developing your own library of common functions or your own webservice framework or whatever can have a perfectly good use-case, cryptography is one of the fields where a tiny mistake can make the whole thing incredibly fragile in a way that you will never find out. If you build your own webserver ("our high-performance in-house webserver...") and there's a problem, you have a good chance of finding out sooner rather than later because it crashes, or sends the wrong files, or performs badly. But if your crypto algorithm has a problem that destroys its cryptographic strength, you have to be very lucky that someone who breaks it actually tells you. The people who try to break it are almost certain to be attackers, because very few cryptographers waste their time on some in-house crypto hack. They know to stick with public algorithms where it actually matters if they find something, to more than one company.






        share|improve this answer












        In the context of cryptography "in-house" is a synonym for "questionable origin and unverified strength".



        It specifically means that they developed their own hashing function (or in other cases encryption, key-exchange scheme, etc.).



        This, in cryptography, is a Bad Idea with capital letters. While developing your own library of common functions or your own webservice framework or whatever can have a perfectly good use-case, cryptography is one of the fields where a tiny mistake can make the whole thing incredibly fragile in a way that you will never find out. If you build your own webserver ("our high-performance in-house webserver...") and there's a problem, you have a good chance of finding out sooner rather than later because it crashes, or sends the wrong files, or performs badly. But if your crypto algorithm has a problem that destroys its cryptographic strength, you have to be very lucky that someone who breaks it actually tells you. The people who try to break it are almost certain to be attackers, because very few cryptographers waste their time on some in-house crypto hack. They know to stick with public algorithms where it actually matters if they find something, to more than one company.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 23 at 11:08









        Tom

        4,379628




        4,379628






















            up vote
            -13
            down vote













            I agree with the answer given an hour before this one about in-house meaning, "non-standard and probably not very sophisticated or rugged." There may still be one argument in favor of using an in-house hash. That is, it may be different enough from the standard ones out there that a hacker may decide it is too much work to figure out how to reverse engineer it. Even if you accept this argument, this sort of do-it-yourself approach should only ever be used to protect very low-value data.






            share|improve this answer

















            • 30




              This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
              – Zefiro
              Nov 21 at 18:21






            • 7




              It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
              – Tom W
              Nov 21 at 19:04






            • 1




              @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
              – supercat
              Nov 21 at 19:52






            • 2




              @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
              – David Schwartz
              Nov 21 at 20:14








            • 2




              @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
              – Nic Hartley
              Nov 21 at 22:06















            up vote
            -13
            down vote













            I agree with the answer given an hour before this one about in-house meaning, "non-standard and probably not very sophisticated or rugged." There may still be one argument in favor of using an in-house hash. That is, it may be different enough from the standard ones out there that a hacker may decide it is too much work to figure out how to reverse engineer it. Even if you accept this argument, this sort of do-it-yourself approach should only ever be used to protect very low-value data.






            share|improve this answer

















            • 30




              This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
              – Zefiro
              Nov 21 at 18:21






            • 7




              It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
              – Tom W
              Nov 21 at 19:04






            • 1




              @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
              – supercat
              Nov 21 at 19:52






            • 2




              @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
              – David Schwartz
              Nov 21 at 20:14








            • 2




              @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
              – Nic Hartley
              Nov 21 at 22:06













            up vote
            -13
            down vote










            up vote
            -13
            down vote









            I agree with the answer given an hour before this one about in-house meaning, "non-standard and probably not very sophisticated or rugged." There may still be one argument in favor of using an in-house hash. That is, it may be different enough from the standard ones out there that a hacker may decide it is too much work to figure out how to reverse engineer it. Even if you accept this argument, this sort of do-it-yourself approach should only ever be used to protect very low-value data.






            share|improve this answer












            I agree with the answer given an hour before this one about in-house meaning, "non-standard and probably not very sophisticated or rugged." There may still be one argument in favor of using an in-house hash. That is, it may be different enough from the standard ones out there that a hacker may decide it is too much work to figure out how to reverse engineer it. Even if you accept this argument, this sort of do-it-yourself approach should only ever be used to protect very low-value data.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 21 at 18:16









            Peter Knibbe

            23




            23








            • 30




              This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
              – Zefiro
              Nov 21 at 18:21






            • 7




              It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
              – Tom W
              Nov 21 at 19:04






            • 1




              @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
              – supercat
              Nov 21 at 19:52






            • 2




              @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
              – David Schwartz
              Nov 21 at 20:14








            • 2




              @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
              – Nic Hartley
              Nov 21 at 22:06














            • 30




              This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
              – Zefiro
              Nov 21 at 18:21






            • 7




              It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
              – Tom W
              Nov 21 at 19:04






            • 1




              @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
              – supercat
              Nov 21 at 19:52






            • 2




              @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
              – David Schwartz
              Nov 21 at 20:14








            • 2




              @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
              – Nic Hartley
              Nov 21 at 22:06








            30




            30




            This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
            – Zefiro
            Nov 21 at 18:21




            This line of reasoning - relying on an attacker not knowing the implementation details and hoping that they won't find out - is named "Security by Obscurity". Since this is only a slowdown, rarely really a barrier, it is generally frowned upon and strongly recommended against. One area where it still does make sense is if your assets drop rapidly in worth in a short time (days to months) and an attack after one year is much less of an impact. Most game and movie DRM / copy protection schemes fall under this category.
            – Zefiro
            Nov 21 at 18:21




            7




            7




            It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
            – Tom W
            Nov 21 at 19:04




            It's almost a trope at this point that whenever a "why is X bad?" question is posted, there will be an answer that says, paraphrasing, "well it's not that bad, because at least the attackers won't know how your version works". In other words, an appeal to Security by Obscurity. And yes, I get that this answer doesn't reject the premise, but others have done.
            – Tom W
            Nov 21 at 19:04




            1




            1




            @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
            – supercat
            Nov 21 at 19:52




            @Zefiro: There is a difference between "hoping that an attacker doesn't find out", and considering the cost/benefit ratios for possible attacks. To be sure, the risk of a popular encryption or hashing scheme being defeated may be slight, despite the level of research into attacks on them, but the probability of a scheme no prospective attackers would care about being defeated might be even lower.
            – supercat
            Nov 21 at 19:52




            2




            2




            @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
            – David Schwartz
            Nov 21 at 20:14






            @Zefiro This reasoning is not about an attacker not knowing the implementation details. I think you need to read it again. It's about an attacker not having sufficient motivation to bother trying to break the algorithm. (It's still wrong, but not because it's security by obscurity, because it's not security at all. The problem is that you're very likely to drastically overestimate how much security you actually have, and that's exactly what happened here.)
            – David Schwartz
            Nov 21 at 20:14






            2




            2




            @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
            – Nic Hartley
            Nov 21 at 22:06




            @supercat The problem is that normally, it's just security by obscurity. If you, say, shuffle an otherwise secure hash before storing (and unshuffle on retrieval and comparison), sure, that does extremely little for security, but it doesn't harm it. If all that's done is the shuffle, that's... very bad. And it's the latter case that's normally done, not the former. So people say "don't ever use it", because that's a good rule of thumb, and once you're experienced enough to know the difference, you're experienced enough to know when to ignore rules of thumb.
            – Nic Hartley
            Nov 21 at 22:06


















            draft saved

            draft discarded




















































            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.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • 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%2f198134%2fwhat-does-in-house-hash-function-mean%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

            A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

            Calculate evaluation metrics using cross_val_predict sklearn

            Insert data from modal to MySQL (multiple modal on website)