8 ms·

If this is real, I'll be stunned if the auditor keeps his job. Then again, after working at startups my whole career, maybe I'm just naive about how messed up

If this is real, I'll be stunned if the auditor keeps his job. Then again, after working at startups my whole career, maybe I'm just naive about how messed up the real world is.

patio11 15y ago
Customers of a particular gigantic consulting company have to be routinely dissuaded from "passwords similar to any old passwords should not be allowed", which is often in bid documents. To a man, when told the requirement is unsound, they suggest infinite retention of passwords in plaintext plus Levenstein distance and ask the consultancy why their engineers couldn't come up with that obvious solution themselves. The reason for this requirement to repeatedly pop up in bid documents is misapplication of a poorly drafted standard by people who are theoretically experts at enforcing it's normative intent. I would love to throw in an additional anecdote here, but it would violate a confidence. Pretend that $500k had been allocated to produce a list of plain text passwords and a combination of bureaucratic inertia, competence issues, and internal politics made that requirement an unstoppable freight train. That gives you the flavor of it.
- reitzensteinm 15y ago
  While that is an absolutely ridiculous requirement, couldn't it be satisfied securely by creating on the order of 1-10k modifications of each password when created, and hashing those? That would be enough to add numbers to the end, switch case, reverse, randomly change letters etc. It's a lot of trouble to go through just because of the ignorance of a client, but it would be enough to check that magic box on the requirements list and be done with it, rather than having to go to all of the trouble of trying to educate the client and risk them going elsewhere.
  - jmah 15y ago
    It's 3am and I've been drinking, but this seems feasible: When the user changes their password, encrypt the old password with a key derived from the new one (you have both in plaintext at this point, when entering old/new passwords). Then hash the new one as usual. Then when the user goes to change their password again, you have the plaintext of the current one, which unlocks the previous password, and so on back in the chain. You can then compare the new password with previous passwords for similarity.
    - swixmix 15y ago
      I like this idea, but I don't think it can be enforced. If I "forget" my password, then all the history is lost with it.
      - stcredzero 15y ago
        If the old password is "forgotten" and can't be retrieved by the user who made it up, then it doesn't seem like that big a risk.
        jbri 15y ago
        The issue is that once your users figure out the system, they'll always "forget" what their password was once it's getting around to expiring.
        erikano 15y ago
        The method I am about to mention here is based on that which was outlined earlier by somebody else [1]. As I will mention further down, the method I suggest here will give the administrator and the CEO the opportunity to conspire and retrieve users passwords without the affected users knowledge, but I will here assume that such could not happend and that if they really wanted to do so, they could find other means anyway (keylogging, etc.) First time: On his client, the user is asked to enter a password which is checked to comply with password rules. This password is salted and hashed before it is stored on a central machine. n-th time: On his client, the user first enters password "n - 1" which is then salted and hashed and sent to the central machine for comparison. If hashes match, you may enter the new password "n" which is checked to comply with password rules. Password "n - 1" is then encryted with password "n" and stored on the central machine. Password "n" is stored on the central machine in two forms: 1) Salted and hashed. 2) Encrypted with a public key. Password "n" is encrypted with a public key and stored on a he central machine. Also, when this machine stores the new public key encrypted password, it deletes its own records of any previous public key encrypted password for the user in question. Through recursion, all old passwords ("n - 2" ... "1") are decrypted and the new password is checked so that it does not match any previous password and that it is not a simple permutation of any of those. If the user forgets his password, the administrator physically logs into a machine which is very tightly secured. This machine does not allow inbound connections of any kind over the network and can only make outbound connections to the central storage machine. Furthermore, the machine does not allow the usage of any removable media (CD, DVD, USB stick, etc.). The drives of the machine in strongly encrypted, as is the private key which is stored on this machine. In order to decrypt the disc of the machine, two passwords are needed. One of the passwords is held by the administrator, the other by the CEO of the company. The same goes for the private key which also has two passwords, both of which are needed to decrypt it. Thus, two people must be involved in order to decrypt the password for a user. Once the administrator and the CEO has logged into the machine, they connect to the central storage and retrieve the encrypted key for the user and then they open their shared private key and decrypt the password. After the user has been given his old password, he must create a new password following the procedure described above. That way, the administator and the CEO does not know the users new password (unless they conspire to do so, but that would be breach of trust). http://news.ycombinator.com/item?id=2820976 http://news.ycombinator.com/item?id=2820976
  - swixmix 15y ago
    A better method would be to save previous password hashes when a password is changed, then check hashes of permutations of the new password against the previous ones.
    - palish 15y ago
      That would verify they aren't bouncing from password A to password B and back to A again... but that's all.
      - swixmix 15y ago
        That would only be true if it didn't keep history. Let's assume my previous two passwords are "love123" and "hate098". If I try to use a new password "love124", then the permutation checker (which, for the moment, knows the new password in plaintext) should check the hash of "love123" and reject it.
        palish 15y ago
        Oh. If you write a permutation checker that happens to output one of your old passwords, then yeah, that'd work. I wonder if that's feasible. It's an interesting idea. Computing hashes is relatively cheap, so I wonder if, say, 1,000 "permutation checks" would be enough. (Although if you're using bcrypt to store passwords, which you should be, then apparently it's not so cheap.) But.. 26 letters in the alphabet + ten digits = 36... and 36^n grows really, really fast. So maybe you'd need way more than 1k permutation checks.
    - zizee 15y ago
      That was my first thought too, but it does not satisfy the "similar" part of the requirement.
      - saurik 15y ago
        It does, because if the new password is similar to the old one, you can either modify the old one to get the new one or modify the new one to get the old one.
  - nikcub 15y ago
    If you are storing passwords properly with bcrypt, then the 1-10k permutations will take far too long to calculate, especially considering that you need to give the user feedback on their new password choice being ok or not within ~100ms (Edit: so the match might be quick, but pre-comp of the hashes and storing them is not. how the hell would you store 1-10k hashes associated with a user anyway? :) )
    - robtoo 15y ago
      When setting a password, you compare the new password to the old hashes, which were calculated the last time the password was changed. So user feedback should be speedy enough. Only once the password is deemed acceptable does the system need to pre-calculate the hashes for the next time the password is changed. Of course, pre-calculating 10,000 bcrypt hashes might be too computationally expensive anyway, but the user wouldn't see a delay.
      - nikcub 15y ago
        you are right - I have it the wrong way around. still you need to do the calculations and find somewhere to store all of those hashes but I can't think of any other way of making 'similar to' work
      - gus_massa 15y ago
        If you use a different salt for each modification of the old password, you must compute the all the hashes of the new password. Another problem is that to prevent the use of the very old passwords, you should keep the hashes of the modifications. To make the comparations fast, you have to use the same hash. Now you have a list of #password-changes * #passwords-modifications, and if an intruder get them, it is possible to make a mini-rainbow attack.
    - reitzensteinm 15y ago
      What kind of bcrypt run times should be targeted? In my back of the envelope calculations I used 100ms per core, which would make 80/s on an 8 core machine, or 12.5s for 1k hashes and 2 minutes for 10k. Which doesn't seem unreasonable. You can give the user feedback on their new password choice after just one hash. The permutations would be stored from their last password set, so it would just be a simple lookup to determine whether a given new password is similar to an old one. I'm in no way recommending this - it was just an amateur guess at a method to fulfill the requirements without exposing a massive security vulnerability.
- jefffoster 15y ago
  Has any work been done to solve reusing passwords with homomophic encryption? (this is a scheme that allows you to perform operations on the encrypted text without decrypting it).
- robtoo 15y ago
  Lots of security standards require passwords to have at least one digit. Lots of security standards require passwords to be changed every so often. The end result? A user starts with the password "Seekrit1" when they join the company, then the next month they change to "Seekrit2", "Seekrit3", and so on. This is hardly what the security policy intended, so stopping that happening isn't actually a bad idea. Obviously storing a complete password history in plaintext (which would even have to be online for the consultants' plan to work) is ridiculous, but pre-calculating a bunch of hashes of similar passwords every time a new password is set would certainly be feasible. Changing passwords is usually a rare occurrence, but making this at least slightly computationally-expensive shouldn't be a problem. Of course, the more expensive the password-hashing algorithm, the fewer "similar" passwords you would reasonably be able to pre-calculate, which is an odd trade-off to have to make a call on. One thing to be wary of, though: by pre-calculating and storing a bunch of hashes of similar strings, this opens you up to (what might be called) a related plaintext attack. I have no idea if existing password hashes are specifically designed to be resistant to this, but would guess not. (edit: I didn't think this sentence through correctly. Thanks, Joachim)
  - brazzy 15y ago
    > Lots of security standards require passwords to be changed every so often. Which is almost as idiotic as storing a complete password history in plaintext, because it pretty much guarantees that passwords either (as you note) follow a simple pattern, or if that is made impossible, are written down in an easily accessible place.
    - fab13n 15y ago
      A very convenient place to store and retrieve them is under a "passwords" folder in your private mail account or your Dropbox, both of which get synchronized with your unprotected smartphone...
    - wisty 15y ago
      Draconian password schemes lead to really insecure user behavior. For example, an iTunes account requires upper-case, lower-case, and a number; but it doesn't tell you that until you try "insecure" passwords. So I bet a lot of users, feeling really frustrated, just use their name (capitalized), and birthday, rather than the semi-secure password the they wanted to use (or in my case, a fairly strong pass-phrase with no numbers).
- fmw 15y ago
  You could require users to enter their old password when changing it. That way, you can compare two plain-text passwords without the need for plain-text storage (or pre-computing, like other commenters suggested).
  - robtoo 15y ago
    This works well to make sure that your new password isn't similar to your old password. Unfortunately, it can't be extended to make sure that the new password isn't similar to the password from two generations back.
    - fmw 15y ago
      You are correct, of course. Eventually some user would figure out they can rotate "aaaaa" and "bbbbb" every other week to avoid having to remember a better password. That being said, they could just follow up with "ccccc" instead of revert to "aaaaa" (or go through the words of some pop song, which would arguably be a somewhat safer pattern to follow). In other words: creative users will find ways to cheat whatever measure you come up with. The only solution is giving them no choice in the matter and to randomly generate passwords for them, but that opens up another can of worms as they will start writing them down on post-it notes attached to their monitors. The only real solution is educating users. Comparing to the previous password (provided by the user when changing it) is close enough to the spec to be able to get away with it in most circumstances (possibly combined with saving a history of password hashes, so you can see if people don't repeatedly use the same password).
    - jcrites 15y ago
      Actually, I think there is a technical solution. Say that the password system keeps a complete history of a user's plaintext passwords, stored encrypted using the current password as a symmetric key. Administrators cannot access this password list without the current password. When a user changes his password, he enters the current password and a proposed new password. The system uses the current password to decrypt the list of previous passwords. It checks the proposed password against the list. If accepted, the old password is added to the list, and it's encrypted using the new password and stored. Are there any threats against this scheme, or will it work?
- deleted 15y ago
  [deleted]
- Someone 15y ago
  You do not have to retain plaintext passwords to implement that. Just remember the past X hashes, generate all passwords within edit distance D of the new one, and compare the two lists. Edit distance 3, even with "letter stays letter, digit stays digit, random additions and removals" will already give millions of variants, so this may be impractical, but impossible? No.
  - Someone 15y ago
    Oops, I should remember to check whether my replies are still useful after taking a break for a couple of hours. Finishing a once-original reply and hitting submit not always is the best idea. Apologies.
praptak 15y ago
"maybe I'm just naive about how messed up the real world is" I'm afraid you might be. Having read the auditor's responses I recognized the tone instantly. Idiots like this do exist - they advance by throwing around lots of buzzwords and touting their "years of experience" which is often enough to bamboozle their equally incompetent superiors.
rickmb 15y ago
I'm afraid you are naive. This is not a lone idiot in an otherwise sane industry. People like this can thrive and remain blissfully ignorant because the entire ecosystem around them is incompetent, from senior executive to junior trainee. In our industry, entire companies operate in complete isolation, basing their practices on the knowledge of their most "senior" engineer who was there at the beginning, however clueless that engineer might be. Companies like this can continue to operate successfully for many years, moving from one client to the other, and you will find them in any niche of the software industry, including startups.
- marchdown 15y ago
  Why won't someone expose them?
  - Tyrannosaurs 15y ago
    Because as with this instance they threaten to sue. And being right in a court of law just means you win, it doesn't mean that you don't get your time, energy and money sapped so really, where's the benefit for the person exposing them?
  - smackfu 15y ago
    Expose them publically? Because that would you get you in trouble with your job at nearly every company. Expose them within the company? Only works if your management supports you, and they are probably only doing a security audit so they can get a piece of paper with some initials on it. They just want it to go away, not to hire another auditor to start from scratch.
jasonlotito 15y ago
To be fair, startups aren't any different. They do things they shouldn't do just as often. I honestly wish I could share some stories, but I can't. Suffice it to say, don't assume a startup is better just because it's backed by YC or some other fund.
- sharjeel 15y ago
  All startups do things they shouldn't do; they are in the business of experimentation, iterations and improvements. However the important thing is that most of the startups realize their mistakes, acknowledge them, learn from them and move on. In this case, the guy is insistent upon being a nutcase.
  - jasonlotito 15y ago
    Sorry, I'm not referring to mistakes. Instead, I'm referring to start-ups doing things they know they shouldn't be doing in the first place. Taking the short cuts that can/will cause real harm. I'm not talking about ignorance here. I'm talking about Russian Roulette.
mbesto 15y ago
> maybe I'm just naive about how messed up the real world is. Try coming into Enterprise software :)
levigross 15y ago
Then again, after working at startups my whole career, maybe I'm just naive about how messed up the real world is. I second this... Working in a startup every time I see someone having to work around corporate BS to get something simple done, this comes to mind.

If this is real, I'll be stunned if the auditor keeps his job. Then again, after working at startups my whole career, maybe I'm just naive about how messed up the real world is.

patio11 15y ago

Customers of a particular gigantic consulting company have to be routinely dissuaded from "passwords similar to any old passwords should not be allowed", which is often in bid documents. To a man, when told the requirement is unsound, they suggest infinite retention of passwords in plaintext plus Levenstein distance and ask the consultancy why their engineers couldn't come up with that obvious solution themselves. The reason for this requirement to repeatedly pop up in bid documents is misapplication of a poorly drafted standard by people who are theoretically experts at enforcing it's normative intent. I would love to throw in an additional anecdote here, but it would violate a confidence. Pretend that $500k had been allocated to produce a list of plain text passwords and a combination of bureaucratic inertia, competence issues, and internal politics made that requirement an unstoppable freight train. That gives you the flavor of it.

reitzensteinm 15y ago
While that is an absolutely ridiculous requirement, couldn't it be satisfied securely by creating on the order of 1-10k modifications of each password when created, and hashing those? That would be enough to add numbers to the end, switch case, reverse, randomly change letters etc. It's a lot of trouble to go through just because of the ignorance of a client, but it would be enough to check that magic box on the requirements list and be done with it, rather than having to go to all of the trouble of trying to educate the client and risk them going elsewhere.
- jmah 15y ago
  It's 3am and I've been drinking, but this seems feasible: When the user changes their password, encrypt the old password with a key derived from the new one (you have both in plaintext at this point, when entering old/new passwords). Then hash the new one as usual. Then when the user goes to change their password again, you have the plaintext of the current one, which unlocks the previous password, and so on back in the chain. You can then compare the new password with previous passwords for similarity.
  - swixmix 15y ago
    I like this idea, but I don't think it can be enforced. If I "forget" my password, then all the history is lost with it.
    - stcredzero 15y ago
      If the old password is "forgotten" and can't be retrieved by the user who made it up, then it doesn't seem like that big a risk.
      - jbri 15y ago
        The issue is that once your users figure out the system, they'll always "forget" what their password was once it's getting around to expiring.
        erikano 15y ago
        The method I am about to mention here is based on that which was outlined earlier by somebody else [1]. As I will mention further down, the method I suggest here will give the administrator and the CEO the opportunity to conspire and retrieve users passwords without the affected users knowledge, but I will here assume that such could not happend and that if they really wanted to do so, they could find other means anyway (keylogging, etc.) First time: On his client, the user is asked to enter a password which is checked to comply with password rules. This password is salted and hashed before it is stored on a central machine. n-th time: On his client, the user first enters password "n - 1" which is then salted and hashed and sent to the central machine for comparison. If hashes match, you may enter the new password "n" which is checked to comply with password rules. Password "n - 1" is then encryted with password "n" and stored on the central machine. Password "n" is stored on the central machine in two forms: 1) Salted and hashed. 2) Encrypted with a public key. Password "n" is encrypted with a public key and stored on a he central machine. Also, when this machine stores the new public key encrypted password, it deletes its own records of any previous public key encrypted password for the user in question. Through recursion, all old passwords ("n - 2" ... "1") are decrypted and the new password is checked so that it does not match any previous password and that it is not a simple permutation of any of those. If the user forgets his password, the administrator physically logs into a machine which is very tightly secured. This machine does not allow inbound connections of any kind over the network and can only make outbound connections to the central storage machine. Furthermore, the machine does not allow the usage of any removable media (CD, DVD, USB stick, etc.). The drives of the machine in strongly encrypted, as is the private key which is stored on this machine. In order to decrypt the disc of the machine, two passwords are needed. One of the passwords is held by the administrator, the other by the CEO of the company. The same goes for the private key which also has two passwords, both of which are needed to decrypt it. Thus, two people must be involved in order to decrypt the password for a user. Once the administrator and the CEO has logged into the machine, they connect to the central storage and retrieve the encrypted key for the user and then they open their shared private key and decrypt the password. After the user has been given his old password, he must create a new password following the procedure described above. That way, the administator and the CEO does not know the users new password (unless they conspire to do so, but that would be breach of trust). http://news.ycombinator.com/item?id=2820976 http://news.ycombinator.com/item?id=2820976
- swixmix 15y ago
  A better method would be to save previous password hashes when a password is changed, then check hashes of permutations of the new password against the previous ones.
  - palish 15y ago
    That would verify they aren't bouncing from password A to password B and back to A again... but that's all.
    - swixmix 15y ago
      That would only be true if it didn't keep history. Let's assume my previous two passwords are "love123" and "hate098". If I try to use a new password "love124", then the permutation checker (which, for the moment, knows the new password in plaintext) should check the hash of "love123" and reject it.
      - palish 15y ago
        Oh. If you write a permutation checker that happens to output one of your old passwords, then yeah, that'd work. I wonder if that's feasible. It's an interesting idea. Computing hashes is relatively cheap, so I wonder if, say, 1,000 "permutation checks" would be enough. (Although if you're using bcrypt to store passwords, which you should be, then apparently it's not so cheap.) But.. 26 letters in the alphabet + ten digits = 36... and 36^n grows really, really fast. So maybe you'd need way more than 1k permutation checks.
  - zizee 15y ago
    That was my first thought too, but it does not satisfy the "similar" part of the requirement.
    - saurik 15y ago
      It does, because if the new password is similar to the old one, you can either modify the old one to get the new one or modify the new one to get the old one.
- nikcub 15y ago
  If you are storing passwords properly with bcrypt, then the 1-10k permutations will take far too long to calculate, especially considering that you need to give the user feedback on their new password choice being ok or not within ~100ms (Edit: so the match might be quick, but pre-comp of the hashes and storing them is not. how the hell would you store 1-10k hashes associated with a user anyway? :) )
  - robtoo 15y ago
    When setting a password, you compare the new password to the old hashes, which were calculated the last time the password was changed. So user feedback should be speedy enough. Only once the password is deemed acceptable does the system need to pre-calculate the hashes for the next time the password is changed. Of course, pre-calculating 10,000 bcrypt hashes might be too computationally expensive anyway, but the user wouldn't see a delay.
    - nikcub 15y ago
      you are right - I have it the wrong way around. still you need to do the calculations and find somewhere to store all of those hashes but I can't think of any other way of making 'similar to' work
    - gus_massa 15y ago
      If you use a different salt for each modification of the old password, you must compute the all the hashes of the new password. Another problem is that to prevent the use of the very old passwords, you should keep the hashes of the modifications. To make the comparations fast, you have to use the same hash. Now you have a list of #password-changes * #passwords-modifications, and if an intruder get them, it is possible to make a mini-rainbow attack.
  - reitzensteinm 15y ago
    What kind of bcrypt run times should be targeted? In my back of the envelope calculations I used 100ms per core, which would make 80/s on an 8 core machine, or 12.5s for 1k hashes and 2 minutes for 10k. Which doesn't seem unreasonable. You can give the user feedback on their new password choice after just one hash. The permutations would be stored from their last password set, so it would just be a simple lookup to determine whether a given new password is similar to an old one. I'm in no way recommending this - it was just an amateur guess at a method to fulfill the requirements without exposing a massive security vulnerability.
jefffoster 15y ago
Has any work been done to solve reusing passwords with homomophic encryption? (this is a scheme that allows you to perform operations on the encrypted text without decrypting it).
robtoo 15y ago
Lots of security standards require passwords to have at least one digit. Lots of security standards require passwords to be changed every so often. The end result? A user starts with the password "Seekrit1" when they join the company, then the next month they change to "Seekrit2", "Seekrit3", and so on. This is hardly what the security policy intended, so stopping that happening isn't actually a bad idea. Obviously storing a complete password history in plaintext (which would even have to be online for the consultants' plan to work) is ridiculous, but pre-calculating a bunch of hashes of similar passwords every time a new password is set would certainly be feasible. Changing passwords is usually a rare occurrence, but making this at least slightly computationally-expensive shouldn't be a problem. Of course, the more expensive the password-hashing algorithm, the fewer "similar" passwords you would reasonably be able to pre-calculate, which is an odd trade-off to have to make a call on. One thing to be wary of, though: by pre-calculating and storing a bunch of hashes of similar strings, this opens you up to (what might be called) a related plaintext attack. I have no idea if existing password hashes are specifically designed to be resistant to this, but would guess not. (edit: I didn't think this sentence through correctly. Thanks, Joachim)
- brazzy 15y ago
  > Lots of security standards require passwords to be changed every so often. Which is almost as idiotic as storing a complete password history in plaintext, because it pretty much guarantees that passwords either (as you note) follow a simple pattern, or if that is made impossible, are written down in an easily accessible place.
  - fab13n 15y ago
    A very convenient place to store and retrieve them is under a "passwords" folder in your private mail account or your Dropbox, both of which get synchronized with your unprotected smartphone...
  - wisty 15y ago
    Draconian password schemes lead to really insecure user behavior. For example, an iTunes account requires upper-case, lower-case, and a number; but it doesn't tell you that until you try "insecure" passwords. So I bet a lot of users, feeling really frustrated, just use their name (capitalized), and birthday, rather than the semi-secure password the they wanted to use (or in my case, a fairly strong pass-phrase with no numbers).
fmw 15y ago
You could require users to enter their old password when changing it. That way, you can compare two plain-text passwords without the need for plain-text storage (or pre-computing, like other commenters suggested).
- robtoo 15y ago
  This works well to make sure that your new password isn't similar to your old password. Unfortunately, it can't be extended to make sure that the new password isn't similar to the password from two generations back.
  - fmw 15y ago
    You are correct, of course. Eventually some user would figure out they can rotate "aaaaa" and "bbbbb" every other week to avoid having to remember a better password. That being said, they could just follow up with "ccccc" instead of revert to "aaaaa" (or go through the words of some pop song, which would arguably be a somewhat safer pattern to follow). In other words: creative users will find ways to cheat whatever measure you come up with. The only solution is giving them no choice in the matter and to randomly generate passwords for them, but that opens up another can of worms as they will start writing them down on post-it notes attached to their monitors. The only real solution is educating users. Comparing to the previous password (provided by the user when changing it) is close enough to the spec to be able to get away with it in most circumstances (possibly combined with saving a history of password hashes, so you can see if people don't repeatedly use the same password).
  - jcrites 15y ago
    Actually, I think there is a technical solution. Say that the password system keeps a complete history of a user's plaintext passwords, stored encrypted using the current password as a symmetric key. Administrators cannot access this password list without the current password. When a user changes his password, he enters the current password and a proposed new password. The system uses the current password to decrypt the list of previous passwords. It checks the proposed password against the list. If accepted, the old password is added to the list, and it's encrypted using the new password and stored. Are there any threats against this scheme, or will it work?
deleted 15y ago
[deleted]
Someone 15y ago
You do not have to retain plaintext passwords to implement that. Just remember the past X hashes, generate all passwords within edit distance D of the new one, and compare the two lists. Edit distance 3, even with "letter stays letter, digit stays digit, random additions and removals" will already give millions of variants, so this may be impractical, but impossible? No.
- Someone 15y ago
  Oops, I should remember to check whether my replies are still useful after taking a break for a couple of hours. Finishing a once-original reply and hitting submit not always is the best idea. Apologies.

praptak 15y ago

"maybe I'm just naive about how messed up the real world is" I'm afraid you might be. Having read the auditor's responses I recognized the tone instantly. Idiots like this do exist - they advance by throwing around lots of buzzwords and touting their "years of experience" which is often enough to bamboozle their equally incompetent superiors.

rickmb 15y ago

I'm afraid you are naive. This is not a lone idiot in an otherwise sane industry. People like this can thrive and remain blissfully ignorant because the entire ecosystem around them is incompetent, from senior executive to junior trainee. In our industry, entire companies operate in complete isolation, basing their practices on the knowledge of their most "senior" engineer who was there at the beginning, however clueless that engineer might be. Companies like this can continue to operate successfully for many years, moving from one client to the other, and you will find them in any niche of the software industry, including startups.

marchdown 15y ago
Why won't someone expose them?
- Tyrannosaurs 15y ago
  Because as with this instance they threaten to sue. And being right in a court of law just means you win, it doesn't mean that you don't get your time, energy and money sapped so really, where's the benefit for the person exposing them?
- smackfu 15y ago
  Expose them publically? Because that would you get you in trouble with your job at nearly every company. Expose them within the company? Only works if your management supports you, and they are probably only doing a security audit so they can get a piece of paper with some initials on it. They just want it to go away, not to hire another auditor to start from scratch.

jasonlotito 15y ago

To be fair, startups aren't any different. They do things they shouldn't do just as often. I honestly wish I could share some stories, but I can't. Suffice it to say, don't assume a startup is better just because it's backed by YC or some other fund.

sharjeel 15y ago
All startups do things they shouldn't do; they are in the business of experimentation, iterations and improvements. However the important thing is that most of the startups realize their mistakes, acknowledge them, learn from them and move on. In this case, the guy is insistent upon being a nutcase.
- jasonlotito 15y ago
  Sorry, I'm not referring to mistakes. Instead, I'm referring to start-ups doing things they know they shouldn't be doing in the first place. Taking the short cuts that can/will cause real harm. I'm not talking about ignorance here. I'm talking about Russian Roulette.

mbesto 15y ago

> maybe I'm just naive about how messed up the real world is. Try coming into Enterprise software :)

levigross 15y ago

Then again, after working at startups my whole career, maybe I'm just naive about how messed up the real world is. I second this... Working in a startup every time I see someone having to work around corporate BS to get something simple done, this comes to mind.