26 ms·

Twitter urges users to change passwords after computer 'glitch'

661 points by petethomas 9y ago

deleted 9y ago
[deleted]
dawnerd 9y ago
So why are they not invalidating exposed passwords like Github did the other day? At the very least they should have a security alert at the top of your feed or something. Edit: Looks like they are alerting users.
- uptown 9y ago
  Because it'd destroy their MAU numbers.
- lucb1e 9y ago
  Github didn't invalidate passwords. They sent an email to affected users (or just everyone?) with a generic password reset link (https://news.ycombinator.com/item?id=16972050 https://news.ycombinator.com/item?id=16972050 )
  - dawnerd 9y ago
    I got forced logged and and required a password reset. That was an invalidation.
    - lucb1e 9y ago
      Oh, then we must have gotten different emails (the one I got was in the linked thread). I didn't know some people got something else!
      - dawnerd 9y ago
        Same email I got. Strange if not everyone was logged out.
  - stordoff 9y ago
    I got the same email, and had my password invalidated (trying to log in just gives "Incorrect username or password"). To add to the speculation in the linked thread, I _did_ recently reset my password, but it was on 28th February.
  - isostatic 9y ago
    I haven't received anything from github, but I use two-factor and oauth tokens, and I don't remember the last time I logged in, let alone changed my password.
djadmin 9y ago
Are Github & Twitter using the same logging tools/service? Btw, Happy World Password Day!
- senoroink 9y ago
  For context: https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/ https://www.zdnet.com/article/github-says-bug-exposed-accoun...
- wybiral 9y ago
  It really makes you wonder how widespread this bad practice is, right? Hashing doesn't help much when you're logging everything first.
- cschep 9y ago
  It would make sense at least from an overlap of Ruby best practices situation. They both started on Rails at least. :)
fatratchet 9y ago
Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.
- xd1936 9y ago
  "[We] are implementing plans to prevent this bug from happening again" sure makes it sound like this bug is still happening. Should we wait a couple of days before changing passwords? Will it end up in this log right now, just like the old one?
  - SahAssar 9y ago
    ~~Sounds more like "we fixed this bug, and will ignore the processes that led to it happening" bullshit to me.~~
    - always_good 9y ago
      And this comment sounds more like "DAE hate twitter." Their response is acceptable and textbook. Doesn't really seem like the appropriate place to wage the battle.
      - SahAssar 9y ago
        Yeah, bad kneejerk response on my part. Sorry.
  - wlesieutre 9y ago
    That sounds more like "We're adding a more thorough testing and code-review process for our password systems to prevent developers from accidentally logging unhashed passwords in the future".
  - 9y ago
vmarsy 9y ago
The reuters article is pretty succint. Here's the tweet about it: https://twitter.com/TwitterSupport/status/992132808192634881 https://twitter.com/TwitterSupport/status/992132808192634881 which links to that blog: https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...
propman 9y ago
We need a regulatory rulebook codified in law by congress that fines companies that make these "mistakes". Enough of a fine will force companies to take these "mistakes" seriously. In Yahoo's case, that might have forced Marissa to actually keep a cybersecurity team and not cut them when she knew the systems were in danger of being compromised. We aren't getting any jail time, but hefty fines that don't stifle growth, just punish negligence and carelessness that are codified and don't need long court hearings to pass are a must.
- zerostar07 9y ago
  "Technology by legislation" - that's the new trend it seems. How about replacing passwords with something technologically superior instead?
  - cpburns2009 9y ago
    Superior technologies such as...?
    - Jach 9y ago
      The obvious one is public-private keys. Servers only ever get your public key.
      - cpburns2009 9y ago
        That's a solution I do like. I was expecting to hear biometrics, email login tokens, or social account logins.
  - maltalex 9y ago
    Replacing passwords won’t suddenly alight large companies interests with yours.
    - zerostar07 9y ago
      ... because twitter has an interest in leaking passwords?
77pt77 9y ago
How is something like this even possible? It just sounds so incompetent.
- deleted 9y ago
  [deleted]
- thln666 9y ago
  seriously? pretty easily. somebody probably left a debug log message in place or something. guaranteed that this happens all the time and most people don't report it.
  - weavie 9y ago
    Indeed. This is probably a good reminder for every developer to just go and check through their logs to see what is there. It can be quite a shock sometimes to find how much can get dumped there..
  - jonjojr 9y ago
    As developer, I can tell you this happens more often than I'd like to admit. debug logs is that necessary evil you need to troubleshoot pesky bugs. Unfortunately some of these debug tools need to be turned on in a live environment to capture those logs for debugging. But also Unfortunately, we are humans and we concentrate on fixing the bug and forget to turn off logging or log unnecessary data.
  - chatmasta 9y ago
    I doubt anyone left something that logged the plaintext password. No reasonable architecture necessitates holding onto a plaintext password for more than one line of code. One possibility is an HTTP server on the request path after TLS termination. But then why is an HTTP server logging the request body? My guess would be some sort of instrumentation process was blindly reading data in memory without distinguishing what the data was, but produced logs that incidentally included passwords.
    - miragle 9y ago
dmourati 9y ago
“We are very sorry this happened,” the Twitter blog said.
- abootstrapper 9y ago
  That stuck out to me too. They skirt admitting blame with that carefully crafted apology.
gingernaut 9y ago
They don't say what the timeframe for this issue is. Have passwords been logged for the last 6 months? Last 3 years? Was this a bug found and fixed last year, and only now are they reporting it?
- softawre 9y ago
  The article does say: > that they were exposed for “several months.”
  - lucb1e 9y ago
    Same as Github it seems. I wonder what library was used, and which other companies use it which hasn't told their users. That'd let us know who isn't as transparent...
- insensible 9y ago
  We must assume the worst.
spike021 9y ago
>Due to a bug, passwords were written to an internal log before completing the hashing process. Hate to speculate, but it sounds possibly like perhaps a debug statement/log level had been enabled for testing and forgotten about?
- mithr 9y ago
  You wouldn't even need that -- just a request log that included the request body without sanitizing it first :)
  - Jare 9y ago
    That would have never happened to me. Not ever!
- abhishekjha 9y ago
  Pretty much. Apparently github did something similar and now people are curious about the library/framework. Why is it so obvious that they both used the same library?
  - swypych 9y ago
    my thoughts exactly, wondering what they are all using.
    - nepthar 9y ago
      Many of twitter's services use this: https://github.com/twitter/finatra https://github.com/twitter/finatra
jonjojr 9y ago
must be the same logging library/framework as github. I want to know which library it is.
- lucb1e 9y ago
  And which other companies use(d) it, so then we know whom to trust (i.e. those who came forward after finding it).
jwilliams 9y ago
The Tweet from the Twitter CTO on this: https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488 "We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do." The "we didn't have to" is a little jarring given the scale of this.
- bomb199 9y ago
  Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - colemickens 9y ago
    I suspect that many more employees at Twitter have access to the logs, than have access to a super computer and pasword hashes. I know I wouldn't trust my password with the number of people that have easy access to logs at other large(ish) tech companies. I really can't imagine why "we didn't have to" was included in that tweet, at all. What other flaps like this have occurred that exposed my creds or personal data to large numbers of employees, that they didn't have and didn't choose to tell us about?
    - cbhl 9y ago
      Even if true, best practice is to strictly restrict access to and create audit trails for reading raw logs from production. Ideally, you'd only need to read raw logs tied to a test account, or, maybe your own personal accounts. Stack traces and exceptions and the like can be anonymized and collated.
    - tptacek 9y ago
flying_sheep 9y ago
This will be my excuse of simply logging everything :-) // logger.log(request.payload);
mrguyorama 9y ago
I haven't actively logged into twitter in almost a year. Does this affect me?
- 0x0 9y ago
  I'm curious about the same. If I've been riding my existing session cookies for a while, am I in the clear?
- aviv 9y ago
  Tinfoil in me says this is exactly the point - to bring people like you back for a second chance.
  - a_imho 9y ago
    Or get people to accept some change in toc/pp by/after signin-in, possibly due to GDPR pressure.
- oneeyedpigeon 9y ago
  Sounds like you don't value twitter that much, so it wouldn't be the end of the world if it did. Unless you reuse that password for anything, but I'm sure that's not the case. You could always delete the account if you're no longer using it, although your use of the word "actively" makes me think you might be using it for oauth or keeping it for other purposes.
uptown 9y ago
The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.
- 49bc 9y ago
  This doesn’t make a big impact in the end because of how prevalent password reuse is.
  - quickthrower2 9y ago
    This is an opportunity to run Troy's filter on the new password.
- sneak 9y ago
  That that is “right” is subjective. Twitter isn’t banking or ATC or healthcare.
  - jedimastert 9y ago
    True, but I could see a lot of livelihoods and careers being ruined by a malicious tweet.
- zeroxfe 9y ago
  > The "right" way to handle this ... maybe in a vacuum. It's possible that if you had all the facts, you just might agree with their course of action.
- billysielu 9y ago
  I think the risk from phishing as a result of this news is higher than the risk from the issue itself.
minimaxir 9y ago
Twitter's CTO had an odd tweet about this disclosure (emphasis mine): > We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do. https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488
- senoroink 9y ago
  He literally could have said just the first sentence and been applauded. Adding the second sentence adds nothing but arrogance.
- jms703 9y ago
  "I should not have said we didn’t have to share. I have felt strongly that we should. My mistake." https://twitter.com/paraga/status/992146630232043520 https://twitter.com/paraga/status/992146630232043520
  - gowld 9y ago
    Felt strongly that [Twitter] should have... "said we didn't have to share"? "shared"? Parag needs a Comms director to handle is Twitter account.
    - bradjohnson 9y ago
      Pretty obviously "shared" given the context.
madrox 9y ago
These comments are everything from eliminating passwords (good luck) to “congress should fix it with law” (lol). Having been in the identity space for a while and seen how various companies think about it, these kinds of problems will keep coming up...mostly at companies for whom identity is commodity. These companies will always give account security the minimum requisite attention. No one at Twitter gets excited about working on the login form. I know OpenID was a bust and everyone hates Facebook Connect, but as an industry we need to figure out how platforms that view account security as a necessary evil can vendor that to people who take it seriously. Trying legal avenues to get people to take it seriously or finding alternative methods is what we’ve been trying for the last 15 years and it hasn’t worked.
- cbhl 9y ago
  Security Keys are often used as a second factor, but the original vision was that they could also be a primary factor in lieu of a password. Humans are bad at passwords, but they carry around house keys every day. Why not also carry around computer keys on their keychain? For the average person (not worried about a megacorp or nation state attacking them), TouchID is also a possible "password replacement" for the primary authentication factor, although it comes with the disadvantage of not being rotatable.
- zerostar07 9y ago
  Alternatives to passwords have "kind of worked" with bitcoin and cryptocurrencies: When they became valuable and exchange breaches became costly, people started using 2FA (exchanges made them mandatory) and ledgerwallets en masse. We should be making these kinds of technologies cheaper and dumbproof so that everybody can use them. Some alternatives proposed in the past, like OpenID, were almost comically complicated for Joe User.
deleted 9y ago
[deleted]
aviv 9y ago
This smells like an attempt by Twitter to get as many users as possible to log in to Twitter so they can report XXXX% increase in monthly active users. With the added bonus of perhaps converting some who gave up on Twitter back into actual active users going forward.
tzs 9y ago
A couple of steps you can take to reduce the chances of accidentally putting sensitive information in a log. 1. Make a list of all sensitive information that the test users in your test environment will be giving to your application. As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.txt' on all your log files. 2. If you are working in some sort of object oriented language, make separate classes for sensitive data, such as a class Password to hold passwords, a class CardNum to hold credit card numbers, and so on. Make the method that whatever you use for logging uses to convert objects to strings return a placeholder string for these objects, such as "Password", "Credit Card Number", and so on.
- praneshp 9y ago
  Do you know of an elegant way to do this when working with protobufs? Ideally, mark a field 'password', and the generated class' __str__ equivalent returns ""
  - bdcs 9y ago
    Check out protobuf annotations
    - traviscj 9y ago
      We do this extensively. A field can be marked as "redacted", and then interceptors can do things like: 1. (most pertinent in this discussion) The logging framework can redact fields before emitting log entries. 2. Endpoints can redact the data unless the client explicitly requests (and is allowed to receive) unredacted data. 3. Serialization mechanisms (e.g. Gson) can be configured to redact data before serializing. (Again, probably can't always do this, but can make that the default for safety.) It's also very straightforward to hook up as a Java annotation that does the same things.
- deleted 9y ago
  [deleted]
- 9y ago
oneeyedpigeon 9y ago
> The glitch was related to Twitter’s use of a technology known as “hashing” that masks passwords as a user enters them by replacing them with numbers and letters, according to the blog. Sigh. They appear to have confused hashing with asterisks. > A bug caused the passwords to be written on an internal computer log before the hashing process was completed, the blog said. So "related" in almost no way whatsoever, then? The state of technology reporting in the mainstream press really makes me despair sometimes.
- Johnny555 9y ago
  The state of technology reporting in the mainstream press really makes me despair sometimes. The problem is that the mainstream press writes for mainstream users, and the state of science/technology understanding in the general public is the real problem.
  - oneeyedpigeon 9y ago
    I hear what you're saying, but I think — in this case — the article's just giving too much irrelevant information. I think most mainstream users I know would understand it if it were written something like: > A bug caused passwords to be written on an internal computer log, the blog said.
    - danso 9y ago
      Understand what, exactly? I don't believe most users understand that passwords aren't necessarily stored in plaintext (on a system log, or in a database).
    - stordoff 9y ago
      I'm not sure many users would understand the issue from just that - a perfectly reasonable (albeit inaccurate) reaction to that would be "Of course Twitter store my passwords - otherwise how can I log in?".
- taco_emoji 9y ago
  This is the phrasing from Twitter's actual blog post[0]: > We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. Which is slightly better, I guess. [0] https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...
dmourati 9y ago
Changed mine, just logged back in to this warning: Keeping your account secure When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone. Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password. Learn more
oneeyedpigeon 9y ago
If this happens in a month's time, will they have to pay out $96,000,000 via the GDPR? This came up at my place of work the other day: are data leaks as a result of bugs breaches of the act?
- beberlei 9y ago
  IANAL: No, there is a process of stuff before you will get fined. A human error does not suddenly lead to heavy fines, if you can prove that you put everything you can to prevent this from happening, i.e. follow all the processes GDPR defines like data processing agreements with third party processors, technical and organizational measures to protect against privacy violations, documentation of personal data stored with type of processing, type of consent, and such. what example would a data privacy agency set to fine a company that is fully compliant? I imagine you could even get court to side with you on not having to pay a fine. data leaks of course are always a breach and must be reported. that doesnt mean you get a fine though.
  - stordoff 9y ago
    Specifically, you'd look to Article 83[1]. It being an unintentional act (83(2)(b)), otherwise following best practices (83(2)(d)), taking steps to mitigate the damage (83(2)(c)), and that Twitter announced the breach (83(2)(h)) weigh heavily in favour of the fine being minimal, or there being no fine at all. Article 83(1) also notes that fines must be "proportionate and dissuasive" -- there is nothing proportionate about imposing the maximum fine for a simple error, nor dissuasive about fining a company that is otherwise compliant and following best practices. [1] https://gdpr-info.eu/art-83-gdpr/ https://gdpr-info.eu/art-83-gdpr/
- deleted 9y ago
  [deleted]
- scaryclam 9y ago
  It would be highly unlikely that any action would be taken at all. The issue was handled responsibly and was unintentional. Fining companies who disclose problems in this manner would just cause others to try and cover them up, which would go against the intent of the GDPR (protecting users).
CiPHPerCoder 9y ago
I've seen this scenario unfold before: 1. User provides username/password. 2. An exception occurs somewhere. 3. The stack trace from the exception is logged. 4. The stack trace includes the credentials. 5. The exception ends up in a ticketing system (Trac, JIRA, etc.) 6. Nobody notices for years.
- testplzignore 9y ago
  As a bonus, sometimes the stack trace will be returned to the user, and maybe it'll contain server-side secrets, too!
- beberlei 9y ago
  Or all the environment variables containing tons of password+tokens, or in javascript libraries all the headers, including cookies that could be used to overtake a session. Error/Exception tracking software is quite dangerous if it written with a "lets store everything, because it could help find the problem" mindest.
- dwyerm 9y ago
  When I was doing some consulting via RDP, I made sure to inform the client that I was about to expose things. "I am about to run strace on this web server instance. This is going to show what all the system calls are doing and how long they're taking. It is going to make the performance of this one instance very poor. It is possible that this will print private information like passwords and credit card numbers in clear text. Are you okay with this?" I'm not sure they fully understood what they were acknowledging, but I heard back later that they were impressed with my professionalism.
calebh 9y ago
I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the information required to access your password vault. I printed out two of these sheets and gave them to trusted family members in sealed envelopes. In the event that I become incapacitated, they will be able to access my accounts.
- racer-v 9y ago
  I keep all my passwords in a text file. I can't imagine remembering them all. I suppose I should keep that file encrypted and synced to multiple devices with rsync or so. Would a password manager give me any advantage over this scheme?
  - freeone3000 9y ago
    No, that's basically what they do, but in a more user-friendly format.
    - sushid 9y ago
      Well if he's not keeping that text file encrypted, I'd argue that there is a very significant difference in his methodology vs 1Password et al.
  - PuffinBlue 9y ago
    You might like this password manager: https://www.passwordstore.org/ https://www.passwordstore.org/ It uses a similar philosophy of encrypting plain text files and you can sync them how you wish. It might do some of the 'heavy lifting' for you.
  - calebh 9y ago
    Yes, a password manager is just an encrypted database for your passwords. 1Password synchronizes all of your passwords across devices and makes sure everything is secure. You only need to remember a single "master password", which is never sent outside of your local device. In the event that you lose or forget your master password, the password vault is completely unrecoverable. 1Password can also store other information besides passwords such as credit cards, software license numbers, passport numbers, etc. There is also a secure notes feature for storing arbitrary text. The other password manager that I tried before 1Password is Lastpass. I ended up choosing 1Password since I think it's better designed and overall feels slicker. The /r/lastpass subreddit is littered with complaints about broken updates and bugs...
deleted 9y ago
[deleted]
gsich 9y ago
Why even hash the password on the remote side, shouldn't some challenge-response hashing be more secure? The most likely downside is that without JS it won't work.
- LyndsySimon 9y ago
  If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the wiser. That's not to say it's a bad idea, though. I have used client-side hashing in the past to allow passwords of arbitrary length while using finite network resources.
  - gsich 9y ago
    True, but at least no sensitive information is available on the server side. People do reuse passwords.
  - John_KZ 9y ago
    That's not true if you ask the client to hash both the password and a one-time token you just send. Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted. You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.
    - yorwba 9y ago
      Your scheme requires the server to store the password in plaintext, and it's transmitted at least during registration.
      - John_KZ 9y ago
        It does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier. Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.
deleted 9y ago
[deleted]
acjohnson55 9y ago
This seems like the sort of problem that typed programming can vastly reduce. In a language where string representation is controlled by the data type itself, one could protect against emitting passwords in plaintext accidentally. You'd still be vulnerable until deserialization happens, but that's a lot less surface area to worry about.
ConcernedCoder 9y ago
Thanks Twitter for making it easy to change my password. Took me all of 10 seconds to do that and review apps with twitter privileges.
asdsa5325 9y ago
Did GitHub's post make them realize this?
anonytrary 9y ago
> Due to a bug, passwords were written to an internal log before completing the hashing process This isn't a bug, it's incompetence. Remember folks, never, ever use the same password for two different websites. Assume all websites store your password in plain text even if they hash it at some point. With logging and tracking on steroids these days, I expect "bugs" like this to be commonplace.
fpgaminer 9y ago
Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?" I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords provided very little, if any, "softening" of the damage. It's funny looking back on that fear now. Password managers have become more mainstream, and we, collectively as users, have learned something interesting. One of the assumptions of that hacking fear was that it was more likely for a user's machine to become compromised than it was for the service's the user uses to be compromised. Well, as it turns out, the opposite was true and the fear was unfounded. The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Perhaps that makes sense in retrospect. But it wasn't obvious a decade ago. Back then viruses and malware were rampant on the internet. In many ways they still are, but not like it was back then. Those were the days of pandemics like the Blaster worm. So it made sense to be more afraid of your own machine being compromised. But the tides have turned. The landscape of OS security has improved dramatically. The single points of failure offered by servers are far more valuable now than the unwashed masses of networked user computers. Just a funny retrospective that I thought I'd share.
- hyder_m29 9y ago
  > The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.
  - fpgaminer 9y ago
    My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of passwords. The two just don't compare in magnitude. Remember that HIBP's list is sitting at something like half a billion password combos right now.
Rjevski 9y ago
It would be nice if they forced a password reset for all affected users and submitted the old passwords to the Pwned Passwords list. I have trouble believing no passwords have been misused by insiders - sure, there wasn't any large-scale misuse but I am sure someone poaching a few passwords here and there for later mischief (once everything has settled down) would have gone unnoticed.
- ghazak 9y ago
  Agreed. I am assuming they will not do it for the same reason yahoo didn’t. They are simply afraid of losing too many active users. Yahoo’s case was worse though, since it was hacked.
  - Rjevski 9y ago
    If the previous breaches are of any indication, it's that users don't give a shit - many major websites have leaked passwords (https://haveibeenpwned.com/PwnedWebsites https://haveibeenpwned.com/PwnedWebsites) and they're still alive and kicking; for the ones that have gone down the drain (Yahoo!) it was more because the service itself faded into irrelevance. Based on that I'd say it would be pretty safe to disclose a breach and reset all passwords; if your service is relevant your users will stay with you, and if not then not disclosing a breach will only buy you time before the inevitable happens anyway.
    - scrollaway 9y ago
      I suspect by "Losing active users", GP meant losing people who get confused or stuck throughout the password reset phase. Twitter is used by a lot of computer novices. Twitter did disclose this, through email and on first login. Anyone they'd lose because of the breach is long gone and I also think it's probably next to nobody.
      - ghazak 9y ago
        Yes, I’m purely talking about losing people if they forced a password reset.
sundvor 9y ago
Why should I change my "passwords"? I only have one entry for Twitch in my password manager. It's 2018, no sane person would reuse their passwords across multiple sites which can and do get hacked.
- rudedogg 9y ago
  > It's 2018, no sane person would reuse their passwords across multiple sites which can and do get hacked. All of my family does this :(. I think it's really common outside of tech savvy people. I've tried pushing them to use a password manager on their phone, or writing them down so they can use multiple passwords, but they'd rather just use a single one. Years of bad advice didn't help either: - Never write your password down - Make sure you use at least one symbol! - Make sure you use one capital letter! https://xkcd.com/936/ https://xkcd.com/936/
  - sundvor 9y ago
    That's an awesome xkcd, thanks.
honoredb 9y ago
It's really hard to avoid logging passwords when there's a parse error on structured data that includes a password, for example if there's malformed JSON in the authentication HTTP request. A weird error like that is exactly when verbose logs are essential, but it's also a time when your system doesn't know what it's logging. Amazon has a machine-learning based service to try to deal with this.
beirut_bootleg 9y ago
No amount of entropy will protect against plain security goofs. "It would take a computer about 115 OCTILLION YEARS to crack your password" some analysis tells me. Guess how many engineers it takes to downgrade any password's strength to "123456".
cgb223 9y ago
So why arent they hashing passwords on the user side? Can't leak a password if the only thing you have to begin with is a hash...
- inimino 9y ago
  Asked and answered in the thread above: https://news.ycombinator.com/item?id=16990570 https://news.ycombinator.com/item?id=16990570
rocky1138 9y ago
While you're in there, enable 2-factor authentication if you haven't already.
- bm5k 9y ago
  it seems like they only offer SMS 2fa which is a bummer.
  - rocky1138 9y ago
    That isn't true. I use Google Authenticator with them.
llccbb 9y ago
Legitimate, non-cynical, non-opportunistic question. Will this boost Twitter's monthly active users?
applekicks 9y ago
Did not GitHub do the exact same thing yesterday?
supergirl 9y ago
if they can leak these, god knows what else they leak and where and for how long
mancerayder 9y ago
How exactly does one manage in a major company to set up an app in production that spits passwords, or even less sensitive customer data, to a logfile? Is that the state of infrastructure engineering? The cynic in me wonders if it's related to the trend to take developers with some systems knowledge and turn them into Ops/SA's.
aylons 9y ago
A honest question from a hardware guy: Why isn't the password hashed and salted client-side, with the salt being sent from server to client? I understand that hashing in the client side would only substitute the user password for a new one. This alone sounds like a win to me, as it at least contains the damage somewhat in case of leakage, specially if salted. EDIT:Sorry, I just found the exact same discussion in this thread.
PakG1 9y ago
I have two-factor authentication with Twitter and wherever else I can using authy. Isn't that enough for me to not change my password? It truly gets bothersome. Maybe I'll need to break down one day and finally get a password manager. :(
samfisher83 9y ago
Wouldn't you have to be an employee of the company to get the passwords since you need access to the log files?
Allower 9y ago
someone explain why you would ever log passwords.. as a software developer myself its safe to say you people are fucking morons
xupybd 9y ago
https://imgflip.com/i/29lzg9 https://imgflip.com/i/29lzg9
md224 9y ago
Might just be a weird coincidence, but at 2:14 PM today I got an e-mail from Twitter with the subject "Security alert: new or unusual Twitter login". I hadn't heard anything about the Twitter bug at that point (was it even public at 2:14?) but I changed my password as a response to that e-mail. Now I'm wondering if I need to change it again... does anyone know what time the bug was patched?
wyldfire 9y ago
Stupid question department: W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn't we create a http browser/server authentication method that has something closer to a nonce-based challenge/response mechanism? If it were standardized, the browsers could even do some clever hashing of some peer addresses or other things that we think should be static. All of the browsers could still present a "username/password" field that looks remarkably similar to existing forms but never reveals the plaintext password to the peer. As long as I could type my password into other browsers on other computers and still get the same result, it seems like it's moving things forward. It would be opt-in, traditional username/password forms would continue to live on for decades to follow. So what am I missing? Presumably something like this was considered and ruled out? EDIT: yes, of course, I forgot about the existing HTTP authentication mechanism(s) in RFC 2069. I don't know why it never caught on but the fact that the browser uses modal dialogues for these means a significantly different context/user experience.
- richardwhiuk 9y ago
  Mainly because the modal dialog can't be styled for security reasons, so the UI designers and marketing tools will want to style the dialog box like everyone else. In the end user experience vs security is a straight tradeoff. Secondly, the digest authentication only supports MD5 anyway.
- rocqua 9y ago
  These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption. Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt.
  - wyldfire 9y ago
    > This means the server still needs to know either your password or a hashed version of it. Yes, the latter, please.
fiddlerwoaroof 9y ago
I once had configured a mail server to log passwords while I was figuring out how to set it up. Then, I turned on logwatch and started using it “for real”. Sometime later, while reading through the logs that logwatch was sending to gmail, I discovered that I had been emailing myself login credentials via plain-text emails.
dschuetz 9y ago
Twitter hasn't figured out how to properly handle passwords after over a decade of its existence? No, I'm not changing my password, I'm deleting my Twitter account for good. I'm tired of big shot Internet companies getting away with such bland disregard of basic security and privacy rules.
- cryptozeus 9y ago
  Its a mistake , it happens. Software is hard. Change your password.
  - dschuetz 9y ago
    It would be fine, but people who claim to be pro in software and are being paid premium refuse to learn from mistakes, neither from their own nor from others'. They just mitigate the fallout by saying things "It's was a mistake, sorry about that, it happens, software is hard". Brain surgery is hard. Mistakes happen. But after a few mistakes you probably should stop doing brain surgery altogether. At least the patients will get a higher chance to survive your surgeries by avoiding you. In terms of security, handling passwords should be considered analogous to brain surgery. A single mistake undermines the whole thing. If you can't handle that, stop doing it, and let people do it who can handle it better.
    - richardwhiuk 9y ago
      Paying people more doesn't prevent mistakes. If you banned every developer the first time they made a mistake their wouldn't be any developers.
      - dschuetz 9y ago
        No, it doesn't. And that's not the issue. It's OK to make mistakes if you learn from them to prevent them from happening twice or trice. But apparently even if paid premium they don't. There were soooo many password db hacks and cracks in the recent years, I can't believe people still defend bad software engineering as if mistakes is a natural occurrence which cannot be prevented. You can't prevent singular mistakes, but you well damn can make it hard to exploit them! If you keep and let bad developers in software security even if they made the same mistakes (and mistakes of others) repeatedly there won't be any security left. So what's the point?
cryptozeus 9y ago
Announcement is underplaying the situation. Absolutely change the password..anyone could have seen it. Just because there ia no evidence of log reading does not mean anything.
deallocator 9y ago
At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
- KeitIG 9y ago
  Maybe you should explain them there is a reason why passwords input is hidden in terminals: to avoid them being kept in ~/.bash_history. It is exactly the same problem.
  - ComodoHacker 9y ago
    There's another argument that might work in GP's case. A fair share of successful attacks were successful not because the attackers actually broke something on their well-guarded target. But because they used credentials obtained from other poorly defended systems.
- ComodoHacker 9y ago
  I was about to suggest you should've reported that to CSO, then I realized most probably you don't have one.
- anf 9y ago
  You should quit. I know you have reasons, but continuing to work at a place like this is not ethical.
  - inteleng 9y ago
    Quitting is also slightly unethical.
    - struppi 9y ago
      Quitting is not unethical at all. You are not required to stay with any company.
zeec 9y ago
I think asymmetric encryption would solve all problems. The sever only ever stores the users public key and uses challenge-response to prevent replay attacks. This is a bad idea, but if you are required that your uses have passwords, you could use their password to seed an elliptic curve private key to create the user key on the fly.
- isostatic 9y ago
  So you go to a site, you enter your password, but then javascript creates a private key and public key based on the userid and password (which is a unique tuple). The key will always be the same regardless of the password. When you first set your password, it sends the public key to the server, which is then stored. If that key was intercepted, it's not a problem. Then the server challenges by sending a random code, which the client uses the private key to encode, sends back, the server then decodes with the public key. That guarantees that the private key is known by the client, and thus the password is known, but the private key never leaves the machine. The second time you go to the site, you get the challenge, and respond. Neither private nor public key is transferred. Do I understand that right?
  - zeec 9y ago
    > "The key will always be the same regardless of the password." The keypair is different for each userid and password. Everything else is correct.
- Tepix 9y ago
  I don't think there's a solution that "solves all problems". What if you want to log in using a dumb terminal or not execute untrusted code on your host?
mundanevoice 9y ago
Exactly the same thing happened with GitHub couple of days back. Funny both faced the same issue within days of each other.
TTPrograms 9y ago
Naive question - wouldn't a lot of these issues be much better if passwords were (on top of server side processing) salted and hashed client-side? Then in principle you couldn't do these cross-site attacks where people reuse their passwords.
- zimlu 9y ago
  Cool idea, I like it.
pishpash 9y ago
For the thousandth time, can we be done with passwords and move to physical tokens please?
TangoTrotFox 9y ago
I don't understand why servers don't just store passwords as a public/private key schema. A private key is algorithmically generated from a password with the public key stored on the server. When logging in the server sends a one-use-only 'challenge' as an encrypted blob to the person logging in. Locally they use the algorithmic private key generated from their password to decrypt the blob and send the response back. And you're logged in. Seems like a pretty simple system and absolutely nothing that has to be secured is stored server side. Is there some clever reason I'm missing that this system fails? ---- Even better you can also salt the password->key schema based on something like the username, making table based attacks infeasible.
aurelien 9y ago
That is just to force users to accept their fkg rules. Sk my dk b*h Twitter!
speedplane 9y ago
The partial answer to this is to dump detailed logs after a few days or weeks. That way, even if disaster strikes like this, it can be somewhat contained.
mbid 9y ago
Reminder that none of this would be necessary if nobody reused their passwords.
- davidcbc 9y ago
  Sure it would. People using Twitter still need to change their password even if it is the only place they use their password.
  - mbid 9y ago
    To defend against what? That some guy at twitter who saw the logs can login and change somebody's status? Anyway, I guess you're right, I simplified. It is kind of a valid point, although if I was this paranoid then I would never leave the house. I just wanted to say that if the web wouldn't have been built on a giant piece of s*, for example password authentication, none of this would have been necessary.
mtgx 9y ago
I think it's ridiculous that Twitter still allows users to reset their passwords through SMS. How long are they going to pretend that SMS is secure?
deleted 9y ago
[deleted]
blklivesmatter 9y ago
Provacy policy in my hairy bottoms
unilynx 9y ago
Can't we reduce the risk of these accidental disclosures by using public/private key encryption? Ie: - server publishes a public key on a fixed url - your JS framework (react/angular/form handling/whatever) is modified to, whenever you query the value of a input[type=password], to return a value encrypted with the private key. (as close to the reading of the field as possible, except for eg. 'repeat password' handling) - your serverside code decrypt the password as close to their 'VerifyPassword' and 'UpdatePassord' implementation as possible. and fail if they receive an unencrypted password. This would make it very hard for intermediate steps (middleware, RPC/REST/JSON decoding) to accidentally spill the password, even if they fully log the traffic, and is something frameworks should be able to help you enforce.
iamgopal 9y ago
And I thought first hashing done at browser level.

661 points by petethomas 9y ago

deleted 9y ago

[deleted]

So why are they not invalidating exposed passwords like Github did the other day? At the very least they should have a security alert at the top of your feed or something. Edit: Looks like they are alerting users.

uptown 9y ago
Because it'd destroy their MAU numbers.
lucb1e 9y ago
Github didn't invalidate passwords. They sent an email to affected users (or just everyone?) with a generic password reset link (https://news.ycombinator.com/item?id=16972050 https://news.ycombinator.com/item?id=16972050 )
- dawnerd 9y ago
  I got forced logged and and required a password reset. That was an invalidation.
  - lucb1e 9y ago
    Oh, then we must have gotten different emails (the one I got was in the linked thread). I didn't know some people got something else!
    - dawnerd 9y ago
      Same email I got. Strange if not everyone was logged out.
- stordoff 9y ago
  I got the same email, and had my password invalidated (trying to log in just gives "Incorrect username or password"). To add to the speculation in the linked thread, I _did_ recently reset my password, but it was on 28th February.
- isostatic 9y ago
  I haven't received anything from github, but I use two-factor and oauth tokens, and I don't remember the last time I logged in, let alone changed my password.

djadmin 9y ago

Are Github & Twitter using the same logging tools/service? Btw, Happy World Password Day!

senoroink 9y ago
For context: https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/ https://www.zdnet.com/article/github-says-bug-exposed-accoun...
wybiral 9y ago
It really makes you wonder how widespread this bad practice is, right? Hashing doesn't help much when you're logging everything first.
cschep 9y ago
It would make sense at least from an overlap of Ruby best practices situation. They both started on Rails at least. :)

fatratchet 9y ago

Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.

xd1936 9y ago
"[We] are implementing plans to prevent this bug from happening again" sure makes it sound like this bug is still happening. Should we wait a couple of days before changing passwords? Will it end up in this log right now, just like the old one?
- SahAssar 9y ago
  ~~Sounds more like "we fixed this bug, and will ignore the processes that led to it happening" bullshit to me.~~
  - always_good 9y ago
    And this comment sounds more like "DAE hate twitter." Their response is acceptable and textbook. Doesn't really seem like the appropriate place to wage the battle.
    - SahAssar 9y ago
      Yeah, bad kneejerk response on my part. Sorry.
- wlesieutre 9y ago
  That sounds more like "We're adding a more thorough testing and code-review process for our password systems to prevent developers from accidentally logging unhashed passwords in the future".
- 9y ago

vmarsy 9y ago

The reuters article is pretty succint. Here's the tweet about it: https://twitter.com/TwitterSupport/status/992132808192634881 https://twitter.com/TwitterSupport/status/992132808192634881 which links to that blog: https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...

propman 9y ago

We need a regulatory rulebook codified in law by congress that fines companies that make these "mistakes". Enough of a fine will force companies to take these "mistakes" seriously. In Yahoo's case, that might have forced Marissa to actually keep a cybersecurity team and not cut them when she knew the systems were in danger of being compromised. We aren't getting any jail time, but hefty fines that don't stifle growth, just punish negligence and carelessness that are codified and don't need long court hearings to pass are a must.

zerostar07 9y ago
"Technology by legislation" - that's the new trend it seems. How about replacing passwords with something technologically superior instead?
- cpburns2009 9y ago
  Superior technologies such as...?
  - Jach 9y ago
    The obvious one is public-private keys. Servers only ever get your public key.
    - cpburns2009 9y ago
      That's a solution I do like. I was expecting to hear biometrics, email login tokens, or social account logins.
- maltalex 9y ago
  Replacing passwords won’t suddenly alight large companies interests with yours.
  - zerostar07 9y ago
    ... because twitter has an interest in leaking passwords?

77pt77 9y ago

How is something like this even possible? It just sounds so incompetent.

deleted 9y ago
[deleted]
thln666 9y ago
seriously? pretty easily. somebody probably left a debug log message in place or something. guaranteed that this happens all the time and most people don't report it.
- weavie 9y ago
  Indeed. This is probably a good reminder for every developer to just go and check through their logs to see what is there. It can be quite a shock sometimes to find how much can get dumped there..
- jonjojr 9y ago
  As developer, I can tell you this happens more often than I'd like to admit. debug logs is that necessary evil you need to troubleshoot pesky bugs. Unfortunately some of these debug tools need to be turned on in a live environment to capture those logs for debugging. But also Unfortunately, we are humans and we concentrate on fixing the bug and forget to turn off logging or log unnecessary data.
- chatmasta 9y ago
  I doubt anyone left something that logged the plaintext password. No reasonable architecture necessitates holding onto a plaintext password for more than one line of code. One possibility is an HTTP server on the request path after TLS termination. But then why is an HTTP server logging the request body? My guess would be some sort of instrumentation process was blindly reading data in memory without distinguishing what the data was, but produced logs that incidentally included passwords.
  - miragle 9y ago

dmourati 9y ago

“We are very sorry this happened,” the Twitter blog said.

abootstrapper 9y ago
That stuck out to me too. They skirt admitting blame with that carefully crafted apology.

gingernaut 9y ago

They don't say what the timeframe for this issue is. Have passwords been logged for the last 6 months? Last 3 years? Was this a bug found and fixed last year, and only now are they reporting it?

softawre 9y ago
The article does say: > that they were exposed for “several months.”
- lucb1e 9y ago
  Same as Github it seems. I wonder what library was used, and which other companies use it which hasn't told their users. That'd let us know who isn't as transparent...
insensible 9y ago
We must assume the worst.

spike021 9y ago

>Due to a bug, passwords were written to an internal log before completing the hashing process. Hate to speculate, but it sounds possibly like perhaps a debug statement/log level had been enabled for testing and forgotten about?

mithr 9y ago
You wouldn't even need that -- just a request log that included the request body without sanitizing it first :)
- Jare 9y ago
  That would have never happened to me. Not ever!
abhishekjha 9y ago
Pretty much. Apparently github did something similar and now people are curious about the library/framework. Why is it so obvious that they both used the same library?
- swypych 9y ago
  my thoughts exactly, wondering what they are all using.
  - nepthar 9y ago
    Many of twitter's services use this: https://github.com/twitter/finatra https://github.com/twitter/finatra

jonjojr 9y ago

must be the same logging library/framework as github. I want to know which library it is.

lucb1e 9y ago
And which other companies use(d) it, so then we know whom to trust (i.e. those who came forward after finding it).

jwilliams 9y ago

The Tweet from the Twitter CTO on this: https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488 "We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do." The "we didn't have to" is a little jarring given the scale of this.

bomb199 9y ago
Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- colemickens 9y ago
  I suspect that many more employees at Twitter have access to the logs, than have access to a super computer and pasword hashes. I know I wouldn't trust my password with the number of people that have easy access to logs at other large(ish) tech companies. I really can't imagine why "we didn't have to" was included in that tweet, at all. What other flaps like this have occurred that exposed my creds or personal data to large numbers of employees, that they didn't have and didn't choose to tell us about?
  - cbhl 9y ago
    Even if true, best practice is to strictly restrict access to and create audit trails for reading raw logs from production. Ideally, you'd only need to read raw logs tied to a test account, or, maybe your own personal accounts. Stack traces and exceptions and the like can be anonymized and collated.
  - tptacek 9y ago

flying_sheep 9y ago

This will be my excuse of simply logging everything :-) // logger.log(request.payload);

mrguyorama 9y ago

I haven't actively logged into twitter in almost a year. Does this affect me?

0x0 9y ago
I'm curious about the same. If I've been riding my existing session cookies for a while, am I in the clear?
aviv 9y ago
Tinfoil in me says this is exactly the point - to bring people like you back for a second chance.
- a_imho 9y ago
  Or get people to accept some change in toc/pp by/after signin-in, possibly due to GDPR pressure.
oneeyedpigeon 9y ago
Sounds like you don't value twitter that much, so it wouldn't be the end of the world if it did. Unless you reuse that password for anything, but I'm sure that's not the case. You could always delete the account if you're no longer using it, although your use of the word "actively" makes me think you might be using it for oauth or keeping it for other purposes.

uptown 9y ago

The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.

49bc 9y ago
This doesn’t make a big impact in the end because of how prevalent password reuse is.
- quickthrower2 9y ago
  This is an opportunity to run Troy's filter on the new password.
sneak 9y ago
That that is “right” is subjective. Twitter isn’t banking or ATC or healthcare.
- jedimastert 9y ago
  True, but I could see a lot of livelihoods and careers being ruined by a malicious tweet.
zeroxfe 9y ago
> The "right" way to handle this ... maybe in a vacuum. It's possible that if you had all the facts, you just might agree with their course of action.
billysielu 9y ago
I think the risk from phishing as a result of this news is higher than the risk from the issue itself.

minimaxir 9y ago

Twitter's CTO had an odd tweet about this disclosure (emphasis mine): > We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do. https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488

senoroink 9y ago
He literally could have said just the first sentence and been applauded. Adding the second sentence adds nothing but arrogance.
jms703 9y ago
"I should not have said we didn’t have to share. I have felt strongly that we should. My mistake." https://twitter.com/paraga/status/992146630232043520 https://twitter.com/paraga/status/992146630232043520
- gowld 9y ago
  Felt strongly that [Twitter] should have... "said we didn't have to share"? "shared"? Parag needs a Comms director to handle is Twitter account.
  - bradjohnson 9y ago
    Pretty obviously "shared" given the context.

madrox 9y ago

These comments are everything from eliminating passwords (good luck) to “congress should fix it with law” (lol). Having been in the identity space for a while and seen how various companies think about it, these kinds of problems will keep coming up...mostly at companies for whom identity is commodity. These companies will always give account security the minimum requisite attention. No one at Twitter gets excited about working on the login form. I know OpenID was a bust and everyone hates Facebook Connect, but as an industry we need to figure out how platforms that view account security as a necessary evil can vendor that to people who take it seriously. Trying legal avenues to get people to take it seriously or finding alternative methods is what we’ve been trying for the last 15 years and it hasn’t worked.

cbhl 9y ago
Security Keys are often used as a second factor, but the original vision was that they could also be a primary factor in lieu of a password. Humans are bad at passwords, but they carry around house keys every day. Why not also carry around computer keys on their keychain? For the average person (not worried about a megacorp or nation state attacking them), TouchID is also a possible "password replacement" for the primary authentication factor, although it comes with the disadvantage of not being rotatable.
zerostar07 9y ago
Alternatives to passwords have "kind of worked" with bitcoin and cryptocurrencies: When they became valuable and exchange breaches became costly, people started using 2FA (exchanges made them mandatory) and ledgerwallets en masse. We should be making these kinds of technologies cheaper and dumbproof so that everybody can use them. Some alternatives proposed in the past, like OpenID, were almost comically complicated for Joe User.

deleted 9y ago

[deleted]

aviv 9y ago

This smells like an attempt by Twitter to get as many users as possible to log in to Twitter so they can report XXXX% increase in monthly active users. With the added bonus of perhaps converting some who gave up on Twitter back into actual active users going forward.

tzs 9y ago

A couple of steps you can take to reduce the chances of accidentally putting sensitive information in a log. 1. Make a list of all sensitive information that the test users in your test environment will be giving to your application. As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.txt' on all your log files. 2. If you are working in some sort of object oriented language, make separate classes for sensitive data, such as a class Password to hold passwords, a class CardNum to hold credit card numbers, and so on. Make the method that whatever you use for logging uses to convert objects to strings return a placeholder string for these objects, such as "Password", "Credit Card Number", and so on.

praneshp 9y ago
Do you know of an elegant way to do this when working with protobufs? Ideally, mark a field 'password', and the generated class' __str__ equivalent returns ""
- bdcs 9y ago
  Check out protobuf annotations
  - traviscj 9y ago
    We do this extensively. A field can be marked as "redacted", and then interceptors can do things like: 1. (most pertinent in this discussion) The logging framework can redact fields before emitting log entries. 2. Endpoints can redact the data unless the client explicitly requests (and is allowed to receive) unredacted data. 3. Serialization mechanisms (e.g. Gson) can be configured to redact data before serializing. (Again, probably can't always do this, but can make that the default for safety.) It's also very straightforward to hook up as a Java annotation that does the same things.
deleted 9y ago
[deleted]
9y ago

oneeyedpigeon 9y ago

> The glitch was related to Twitter’s use of a technology known as “hashing” that masks passwords as a user enters them by replacing them with numbers and letters, according to the blog. Sigh. They appear to have confused hashing with asterisks. > A bug caused the passwords to be written on an internal computer log before the hashing process was completed, the blog said. So "related" in almost no way whatsoever, then? The state of technology reporting in the mainstream press really makes me despair sometimes.

Johnny555 9y ago
The state of technology reporting in the mainstream press really makes me despair sometimes. The problem is that the mainstream press writes for mainstream users, and the state of science/technology understanding in the general public is the real problem.
- oneeyedpigeon 9y ago
  I hear what you're saying, but I think — in this case — the article's just giving too much irrelevant information. I think most mainstream users I know would understand it if it were written something like: > A bug caused passwords to be written on an internal computer log, the blog said.
  - danso 9y ago
    Understand what, exactly? I don't believe most users understand that passwords aren't necessarily stored in plaintext (on a system log, or in a database).
  - stordoff 9y ago
    I'm not sure many users would understand the issue from just that - a perfectly reasonable (albeit inaccurate) reaction to that would be "Of course Twitter store my passwords - otherwise how can I log in?".
taco_emoji 9y ago
This is the phrasing from Twitter's actual blog post[0]: > We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. Which is slightly better, I guess. [0] https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...

dmourati 9y ago

Changed mine, just logged back in to this warning: Keeping your account secure When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone. Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password. Learn more

oneeyedpigeon 9y ago

If this happens in a month's time, will they have to pay out $96,000,000 via the GDPR? This came up at my place of work the other day: are data leaks as a result of bugs breaches of the act?

beberlei 9y ago
IANAL: No, there is a process of stuff before you will get fined. A human error does not suddenly lead to heavy fines, if you can prove that you put everything you can to prevent this from happening, i.e. follow all the processes GDPR defines like data processing agreements with third party processors, technical and organizational measures to protect against privacy violations, documentation of personal data stored with type of processing, type of consent, and such. what example would a data privacy agency set to fine a company that is fully compliant? I imagine you could even get court to side with you on not having to pay a fine. data leaks of course are always a breach and must be reported. that doesnt mean you get a fine though.
- stordoff 9y ago
  Specifically, you'd look to Article 83[1]. It being an unintentional act (83(2)(b)), otherwise following best practices (83(2)(d)), taking steps to mitigate the damage (83(2)(c)), and that Twitter announced the breach (83(2)(h)) weigh heavily in favour of the fine being minimal, or there being no fine at all. Article 83(1) also notes that fines must be "proportionate and dissuasive" -- there is nothing proportionate about imposing the maximum fine for a simple error, nor dissuasive about fining a company that is otherwise compliant and following best practices. [1] https://gdpr-info.eu/art-83-gdpr/ https://gdpr-info.eu/art-83-gdpr/
deleted 9y ago
[deleted]
scaryclam 9y ago
It would be highly unlikely that any action would be taken at all. The issue was handled responsibly and was unintentional. Fining companies who disclose problems in this manner would just cause others to try and cover them up, which would go against the intent of the GDPR (protecting users).

CiPHPerCoder 9y ago

I've seen this scenario unfold before: 1. User provides username/password. 2. An exception occurs somewhere. 3. The stack trace from the exception is logged. 4. The stack trace includes the credentials. 5. The exception ends up in a ticketing system (Trac, JIRA, etc.) 6. Nobody notices for years.

testplzignore 9y ago
As a bonus, sometimes the stack trace will be returned to the user, and maybe it'll contain server-side secrets, too!
beberlei 9y ago
Or all the environment variables containing tons of password+tokens, or in javascript libraries all the headers, including cookies that could be used to overtake a session. Error/Exception tracking software is quite dangerous if it written with a "lets store everything, because it could help find the problem" mindest.
dwyerm 9y ago
When I was doing some consulting via RDP, I made sure to inform the client that I was about to expose things. "I am about to run strace on this web server instance. This is going to show what all the system calls are doing and how long they're taking. It is going to make the performance of this one instance very poor. It is possible that this will print private information like passwords and credit card numbers in clear text. Are you okay with this?" I'm not sure they fully understood what they were acknowledging, but I heard back later that they were impressed with my professionalism.

calebh 9y ago

I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the information required to access your password vault. I printed out two of these sheets and gave them to trusted family members in sealed envelopes. In the event that I become incapacitated, they will be able to access my accounts.

racer-v 9y ago
I keep all my passwords in a text file. I can't imagine remembering them all. I suppose I should keep that file encrypted and synced to multiple devices with rsync or so. Would a password manager give me any advantage over this scheme?
- freeone3000 9y ago
  No, that's basically what they do, but in a more user-friendly format.
  - sushid 9y ago
    Well if he's not keeping that text file encrypted, I'd argue that there is a very significant difference in his methodology vs 1Password et al.
- PuffinBlue 9y ago
  You might like this password manager: https://www.passwordstore.org/ https://www.passwordstore.org/ It uses a similar philosophy of encrypting plain text files and you can sync them how you wish. It might do some of the 'heavy lifting' for you.
- calebh 9y ago
  Yes, a password manager is just an encrypted database for your passwords. 1Password synchronizes all of your passwords across devices and makes sure everything is secure. You only need to remember a single "master password", which is never sent outside of your local device. In the event that you lose or forget your master password, the password vault is completely unrecoverable. 1Password can also store other information besides passwords such as credit cards, software license numbers, passport numbers, etc. There is also a secure notes feature for storing arbitrary text. The other password manager that I tried before 1Password is Lastpass. I ended up choosing 1Password since I think it's better designed and overall feels slicker. The /r/lastpass subreddit is littered with complaints about broken updates and bugs...

deleted 9y ago

[deleted]

gsich 9y ago

Why even hash the password on the remote side, shouldn't some challenge-response hashing be more secure? The most likely downside is that without JS it won't work.

LyndsySimon 9y ago
If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the wiser. That's not to say it's a bad idea, though. I have used client-side hashing in the past to allow passwords of arbitrary length while using finite network resources.
- gsich 9y ago
  True, but at least no sensitive information is available on the server side. People do reuse passwords.
- John_KZ 9y ago
  That's not true if you ask the client to hash both the password and a one-time token you just send. Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted. You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.
  - yorwba 9y ago
    Your scheme requires the server to store the password in plaintext, and it's transmitted at least during registration.
    - John_KZ 9y ago
      It does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier. Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.

deleted 9y ago

[deleted]

acjohnson55 9y ago

This seems like the sort of problem that typed programming can vastly reduce. In a language where string representation is controlled by the data type itself, one could protect against emitting passwords in plaintext accidentally. You'd still be vulnerable until deserialization happens, but that's a lot less surface area to worry about.

ConcernedCoder 9y ago

Thanks Twitter for making it easy to change my password. Took me all of 10 seconds to do that and review apps with twitter privileges.

asdsa5325 9y ago

Did GitHub's post make them realize this?

anonytrary 9y ago

> Due to a bug, passwords were written to an internal log before completing the hashing process This isn't a bug, it's incompetence. Remember folks, never, ever use the same password for two different websites. Assume all websites store your password in plain text even if they hash it at some point. With logging and tracking on steroids these days, I expect "bugs" like this to be commonplace.

fpgaminer 9y ago

Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?" I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords provided very little, if any, "softening" of the damage. It's funny looking back on that fear now. Password managers have become more mainstream, and we, collectively as users, have learned something interesting. One of the assumptions of that hacking fear was that it was more likely for a user's machine to become compromised than it was for the service's the user uses to be compromised. Well, as it turns out, the opposite was true and the fear was unfounded. The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Perhaps that makes sense in retrospect. But it wasn't obvious a decade ago. Back then viruses and malware were rampant on the internet. In many ways they still are, but not like it was back then. Those were the days of pandemics like the Blaster worm. So it made sense to be more afraid of your own machine being compromised. But the tides have turned. The landscape of OS security has improved dramatically. The single points of failure offered by servers are far more valuable now than the unwashed masses of networked user computers. Just a funny retrospective that I thought I'd share.

hyder_m29 9y ago
> The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.
- fpgaminer 9y ago
  My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of passwords. The two just don't compare in magnitude. Remember that HIBP's list is sitting at something like half a billion password combos right now.

Rjevski 9y ago

It would be nice if they forced a password reset for all affected users and submitted the old passwords to the Pwned Passwords list. I have trouble believing no passwords have been misused by insiders - sure, there wasn't any large-scale misuse but I am sure someone poaching a few passwords here and there for later mischief (once everything has settled down) would have gone unnoticed.

ghazak 9y ago
Agreed. I am assuming they will not do it for the same reason yahoo didn’t. They are simply afraid of losing too many active users. Yahoo’s case was worse though, since it was hacked.
- Rjevski 9y ago
  If the previous breaches are of any indication, it's that users don't give a shit - many major websites have leaked passwords (https://haveibeenpwned.com/PwnedWebsites https://haveibeenpwned.com/PwnedWebsites) and they're still alive and kicking; for the ones that have gone down the drain (Yahoo!) it was more because the service itself faded into irrelevance. Based on that I'd say it would be pretty safe to disclose a breach and reset all passwords; if your service is relevant your users will stay with you, and if not then not disclosing a breach will only buy you time before the inevitable happens anyway.
  - scrollaway 9y ago
    I suspect by "Losing active users", GP meant losing people who get confused or stuck throughout the password reset phase. Twitter is used by a lot of computer novices. Twitter did disclose this, through email and on first login. Anyone they'd lose because of the breach is long gone and I also think it's probably next to nobody.
    - ghazak 9y ago
      Yes, I’m purely talking about losing people if they forced a password reset.

sundvor 9y ago

Why should I change my "passwords"? I only have one entry for Twitch in my password manager. It's 2018, no sane person would reuse their passwords across multiple sites which can and do get hacked.

rudedogg 9y ago
> It's 2018, no sane person would reuse their passwords across multiple sites which can and do get hacked. All of my family does this :(. I think it's really common outside of tech savvy people. I've tried pushing them to use a password manager on their phone, or writing them down so they can use multiple passwords, but they'd rather just use a single one. Years of bad advice didn't help either: - Never write your password down - Make sure you use at least one symbol! - Make sure you use one capital letter! https://xkcd.com/936/ https://xkcd.com/936/
- sundvor 9y ago
  That's an awesome xkcd, thanks.

honoredb 9y ago

It's really hard to avoid logging passwords when there's a parse error on structured data that includes a password, for example if there's malformed JSON in the authentication HTTP request. A weird error like that is exactly when verbose logs are essential, but it's also a time when your system doesn't know what it's logging. Amazon has a machine-learning based service to try to deal with this.

beirut_bootleg 9y ago

No amount of entropy will protect against plain security goofs. "It would take a computer about 115 OCTILLION YEARS to crack your password" some analysis tells me. Guess how many engineers it takes to downgrade any password's strength to "123456".

cgb223 9y ago

So why arent they hashing passwords on the user side? Can't leak a password if the only thing you have to begin with is a hash...

inimino 9y ago
Asked and answered in the thread above: https://news.ycombinator.com/item?id=16990570 https://news.ycombinator.com/item?id=16990570

rocky1138 9y ago

While you're in there, enable 2-factor authentication if you haven't already.

bm5k 9y ago
it seems like they only offer SMS 2fa which is a bummer.
- rocky1138 9y ago
  That isn't true. I use Google Authenticator with them.

llccbb 9y ago

Legitimate, non-cynical, non-opportunistic question. Will this boost Twitter's monthly active users?

applekicks 9y ago

Did not GitHub do the exact same thing yesterday?

supergirl 9y ago

if they can leak these, god knows what else they leak and where and for how long

mancerayder 9y ago

How exactly does one manage in a major company to set up an app in production that spits passwords, or even less sensitive customer data, to a logfile? Is that the state of infrastructure engineering? The cynic in me wonders if it's related to the trend to take developers with some systems knowledge and turn them into Ops/SA's.

aylons 9y ago

A honest question from a hardware guy: Why isn't the password hashed and salted client-side, with the salt being sent from server to client? I understand that hashing in the client side would only substitute the user password for a new one. This alone sounds like a win to me, as it at least contains the damage somewhat in case of leakage, specially if salted. EDIT:Sorry, I just found the exact same discussion in this thread.

PakG1 9y ago

I have two-factor authentication with Twitter and wherever else I can using authy. Isn't that enough for me to not change my password? It truly gets bothersome. Maybe I'll need to break down one day and finally get a password manager. :(

samfisher83 9y ago

Wouldn't you have to be an employee of the company to get the passwords since you need access to the log files?

Allower 9y ago

someone explain why you would ever log passwords.. as a software developer myself its safe to say you people are fucking morons

xupybd 9y ago

https://imgflip.com/i/29lzg9 https://imgflip.com/i/29lzg9

md224 9y ago

Might just be a weird coincidence, but at 2:14 PM today I got an e-mail from Twitter with the subject "Security alert: new or unusual Twitter login". I hadn't heard anything about the Twitter bug at that point (was it even public at 2:14?) but I changed my password as a response to that e-mail. Now I'm wondering if I need to change it again... does anyone know what time the bug was patched?

wyldfire 9y ago

Stupid question department: W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn't we create a http browser/server authentication method that has something closer to a nonce-based challenge/response mechanism? If it were standardized, the browsers could even do some clever hashing of some peer addresses or other things that we think should be static. All of the browsers could still present a "username/password" field that looks remarkably similar to existing forms but never reveals the plaintext password to the peer. As long as I could type my password into other browsers on other computers and still get the same result, it seems like it's moving things forward. It would be opt-in, traditional username/password forms would continue to live on for decades to follow. So what am I missing? Presumably something like this was considered and ruled out? EDIT: yes, of course, I forgot about the existing HTTP authentication mechanism(s) in RFC 2069. I don't know why it never caught on but the fact that the browser uses modal dialogues for these means a significantly different context/user experience.

richardwhiuk 9y ago
Mainly because the modal dialog can't be styled for security reasons, so the UI designers and marketing tools will want to style the dialog box like everyone else. In the end user experience vs security is a straight tradeoff. Secondly, the digest authentication only supports MD5 anyway.
rocqua 9y ago
These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption. Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with a server-provided salt.
- wyldfire 9y ago
  > This means the server still needs to know either your password or a hashed version of it. Yes, the latter, please.

fiddlerwoaroof 9y ago

I once had configured a mail server to log passwords while I was figuring out how to set it up. Then, I turned on logwatch and started using it “for real”. Sometime later, while reading through the logs that logwatch was sending to gmail, I discovered that I had been emailing myself login credentials via plain-text emails.

dschuetz 9y ago

Twitter hasn't figured out how to properly handle passwords after over a decade of its existence? No, I'm not changing my password, I'm deleting my Twitter account for good. I'm tired of big shot Internet companies getting away with such bland disregard of basic security and privacy rules.

cryptozeus 9y ago
Its a mistake , it happens. Software is hard. Change your password.
- dschuetz 9y ago
  It would be fine, but people who claim to be pro in software and are being paid premium refuse to learn from mistakes, neither from their own nor from others'. They just mitigate the fallout by saying things "It's was a mistake, sorry about that, it happens, software is hard". Brain surgery is hard. Mistakes happen. But after a few mistakes you probably should stop doing brain surgery altogether. At least the patients will get a higher chance to survive your surgeries by avoiding you. In terms of security, handling passwords should be considered analogous to brain surgery. A single mistake undermines the whole thing. If you can't handle that, stop doing it, and let people do it who can handle it better.
  - richardwhiuk 9y ago
    Paying people more doesn't prevent mistakes. If you banned every developer the first time they made a mistake their wouldn't be any developers.
    - dschuetz 9y ago
      No, it doesn't. And that's not the issue. It's OK to make mistakes if you learn from them to prevent them from happening twice or trice. But apparently even if paid premium they don't. There were soooo many password db hacks and cracks in the recent years, I can't believe people still defend bad software engineering as if mistakes is a natural occurrence which cannot be prevented. You can't prevent singular mistakes, but you well damn can make it hard to exploit them! If you keep and let bad developers in software security even if they made the same mistakes (and mistakes of others) repeatedly there won't be any security left. So what's the point?

cryptozeus 9y ago

Announcement is underplaying the situation. Absolutely change the password..anyone could have seen it. Just because there ia no evidence of log reading does not mean anything.

deallocator 9y ago

At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point

KeitIG 9y ago
Maybe you should explain them there is a reason why passwords input is hidden in terminals: to avoid them being kept in ~/.bash_history. It is exactly the same problem.
- ComodoHacker 9y ago
  There's another argument that might work in GP's case. A fair share of successful attacks were successful not because the attackers actually broke something on their well-guarded target. But because they used credentials obtained from other poorly defended systems.
ComodoHacker 9y ago
I was about to suggest you should've reported that to CSO, then I realized most probably you don't have one.
anf 9y ago
You should quit. I know you have reasons, but continuing to work at a place like this is not ethical.
- inteleng 9y ago
  Quitting is also slightly unethical.
  - struppi 9y ago
    Quitting is not unethical at all. You are not required to stay with any company.

zeec 9y ago

I think asymmetric encryption would solve all problems. The sever only ever stores the users public key and uses challenge-response to prevent replay attacks. This is a bad idea, but if you are required that your uses have passwords, you could use their password to seed an elliptic curve private key to create the user key on the fly.

isostatic 9y ago
So you go to a site, you enter your password, but then javascript creates a private key and public key based on the userid and password (which is a unique tuple). The key will always be the same regardless of the password. When you first set your password, it sends the public key to the server, which is then stored. If that key was intercepted, it's not a problem. Then the server challenges by sending a random code, which the client uses the private key to encode, sends back, the server then decodes with the public key. That guarantees that the private key is known by the client, and thus the password is known, but the private key never leaves the machine. The second time you go to the site, you get the challenge, and respond. Neither private nor public key is transferred. Do I understand that right?
- zeec 9y ago
  > "The key will always be the same regardless of the password." The keypair is different for each userid and password. Everything else is correct.
Tepix 9y ago
I don't think there's a solution that "solves all problems". What if you want to log in using a dumb terminal or not execute untrusted code on your host?

mundanevoice 9y ago

Exactly the same thing happened with GitHub couple of days back. Funny both faced the same issue within days of each other.

TTPrograms 9y ago

Naive question - wouldn't a lot of these issues be much better if passwords were (on top of server side processing) salted and hashed client-side? Then in principle you couldn't do these cross-site attacks where people reuse their passwords.

zimlu 9y ago
Cool idea, I like it.

pishpash 9y ago

For the thousandth time, can we be done with passwords and move to physical tokens please?

TangoTrotFox 9y ago

I don't understand why servers don't just store passwords as a public/private key schema. A private key is algorithmically generated from a password with the public key stored on the server. When logging in the server sends a one-use-only 'challenge' as an encrypted blob to the person logging in. Locally they use the algorithmic private key generated from their password to decrypt the blob and send the response back. And you're logged in. Seems like a pretty simple system and absolutely nothing that has to be secured is stored server side. Is there some clever reason I'm missing that this system fails? ---- Even better you can also salt the password->key schema based on something like the username, making table based attacks infeasible.

aurelien 9y ago

That is just to force users to accept their fkg rules. Sk my dk b*h Twitter!

speedplane 9y ago

The partial answer to this is to dump detailed logs after a few days or weeks. That way, even if disaster strikes like this, it can be somewhat contained.

mbid 9y ago

Reminder that none of this would be necessary if nobody reused their passwords.

davidcbc 9y ago
Sure it would. People using Twitter still need to change their password even if it is the only place they use their password.
- mbid 9y ago
  To defend against what? That some guy at twitter who saw the logs can login and change somebody's status? Anyway, I guess you're right, I simplified. It is kind of a valid point, although if I was this paranoid then I would never leave the house. I just wanted to say that if the web wouldn't have been built on a giant piece of s*, for example password authentication, none of this would have been necessary.

mtgx 9y ago

I think it's ridiculous that Twitter still allows users to reset their passwords through SMS. How long are they going to pretend that SMS is secure?

deleted 9y ago

[deleted]

blklivesmatter 9y ago

Provacy policy in my hairy bottoms

unilynx 9y ago

Can't we reduce the risk of these accidental disclosures by using public/private key encryption? Ie: - server publishes a public key on a fixed url - your JS framework (react/angular/form handling/whatever) is modified to, whenever you query the value of a input[type=password], to return a value encrypted with the private key. (as close to the reading of the field as possible, except for eg. 'repeat password' handling) - your serverside code decrypt the password as close to their 'VerifyPassword' and 'UpdatePassord' implementation as possible. and fail if they receive an unencrypted password. This would make it very hard for intermediate steps (middleware, RPC/REST/JSON decoding) to accidentally spill the password, even if they fully log the traffic, and is something frameworks should be able to help you enforce.

iamgopal 9y ago

And I thought first hashing done at browser level.