Deterministic, bit-identical and/or verifiable Linux builds - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=885777

<comment><USER2> I filed the linked bug and am the technical owner of Firefox's build system.

There were efforts made and discussions outside of the linked bug. To say "nothing" was done is just not true.

It would be more accurate to say that we just can't justify working on this right now because the timing isn't right and it's high cost for perceived low reward. The time of everyone involved to implement this would be better spent on improvements that benefit the general Firefox population. Some of those improvements include overhauling Firefox's build automation to better support things like building with Docker. That lays the groundwork for (easier) deterministic builds in the future. Even then, I'm not sure if this will happen. Brendan's post called on the larger community to make requests of Mozilla. That front has been surprisingly quiet. If you really want this, I would suggest making noise on the mozilla.org domain. Even better, contribute some patches, like the Tor Project has done: I will happily review them! #build on irc.mozilla.org.

<comment><AUTHOR> Sorry if I wrote that nothing was done. What I really meant was that no change happened, and even the discussion for the bug at a first glance doesn't let understand if there is a clear path toward deterministic builds.

What would it be "making noise on the mozilla.org domain"? Must say, though, I am kind of saddened to see that this discussion was upvoted 80 times while the bug is still at 6.

<comment><USER2> The path towards deterministic builds is definitely not clear. As many in this thread have pointed out, it's a difficult technical problem. The difficulties are multiplied by a project at Firefox's scale.

Further complicating matters is our platform breakdown. The majority of Firefox users are on Windows. Deterministic builds on Windows are very painful. And that's before you figure PGO into the mix. Tor works around this by compiling Firefox with an open source toolchain and doesn't use PGO. But that's a non-starter for us because choosing an open source toolchain over Microsoft's would result in performance degradations for our users. Believe me, if we could ship a Windows and Mac Firefox built with 100% open source to no detriment to our users, we would. There's work to get Firefox building with Clang on Windows (but only for doing ASAN and static analysis, not for shipping to users). That gets us one step closer.

All that being said, there has been exploratory talk lately of serving segments of our user base with specialized Firefox builds. e.g. a build with developer tools front and center that caters to the web development community. If that ever happens, I imagine a deterministically-built Firefox with things like Tor built in could be on the table. The way you can make that happen is to direct noise directly at the Mozilla community. Send a well-crafted email to firefox-dev ([https://mail.mozilla.org/listinfo/firefox- dev](https://mail.mozilla.org/listinfo/firefox-dev)) explaining your position. Anticipate that people will likely reply by asking you to prioritize this against existing goals, such as shipping 64-bit Firefox on Windows and shipping multi-process Firefox. We don't have nearly unlimited resources like some of the other browser vendors, so we can't just do everything. Again, I implore people to directly contribute to Mozilla any way they can. [https://www.mozilla.org/contribute/](https://www.mozilla.org/contribute/)

</comment></comment></comment><comment><USER3> I'm in casino gaming. We have to send our source and tools to regulatory test labs so they can (hopefully) independently generate the same binary as what we are delivering. Given our tools (C++ and Windows), 'binary reproducibility'[1] is impossible, but we've got a workaround. We do our release builds on a VirtualBox that's all tooled up. When it comes time to deliver to the lab, we export the entire box (with source already synced) as an .ova. Part of our build pipeline is a tool that strips things like timestamps and paths from the PE files. Some people don't go to all this trouble and instead use tools like Zynamics BinDiff to explain away the diffs.

[1][https://www.google.com/?gws_rd=ssl#q=binary+reproducibility](https://www.google.com/?gws_rd=ssl#q=binary+reproducibility)

<comment><USER4> What are the companies that provide this service (reproducing builds)? I haven't heard of this, but sounds interesting.

Depending on how much effort you're willing to put in, even if you use C++ and Windows, you can still write a program to parse the executable and zero out timestamps and other non-deterministic data. That is actually being done in a BitCoin-related program for Windows I believe.

How do you generate and verify the VirtualBox? If you send the image over to the test lab, then the obvious thing to do is for someone to attack your VirtualBox, and you have the same problem all over again, just at a different level.

<comment><USER3> For jurisdictions that don't have their own state-run labs (so not NV, NJ, PA, etc.) everybody uses one or a mix of GLI[1], BMM[2], and Eclipse[3] Note: I'm only familiar with US gaming.

We do have a tool to zero these parts of the executable files out, but in our testing we still had unexplainable differences unless we were on the same machine working from the same sync.

The VirtualBox was generated once (installed Windows, Visual Studio, .NET, some others) and we just continue to use the same base .ova.

The package has to be sent to the lab on physical media where it gets loaded onto an offline machine that we've supplied.

[1][http://www.gaminglabs.com/](http://www.gaminglabs.com/) [2][http://www.bmm.com/](http://www.bmm.com/) [3][http://www.eclipsetesting.com/](http://www.eclipsetesting.com/)

<comment><USER5> This works for your goal (being able to reproduce the binary build), but in Mozilla's case it's slightly different. Being FLOSS software, Mozilla's goal is that end-users can _completely_ reproduce the builds from source. This includes dependencies, toolchains, AND the build environment. In this scenario, accepting a pre-build binary VM would not be acceptable, since it defeats the spirit of FLOSS.

</comment></comment></comment></comment><comment><AUTHOR> On January 2014 Brendan Eich [1] called out for organization to build up a system to verify Firefox builds in order to secure the browser can't be used as an attack vector being distributed with some malicious feature added to what's in the source code.

Six months later nothing is done, that is because Firefox build are not deterministic yet. If you think this is an important issue, please vote this bug.

Edit: [1] [https://brendaneich.com/2014/01/trust-but- verify/](https://brendaneich.com/2014/01/trust-but-verify/)

<comment><USER6> I'm curious on the theoretical basis of this effort. I'm reminded of "On Trusting Trust." Simply put, not at all an easy problem to try and tackle.

No, I'm not against trying. Just going from your thing, I'm not sure what is being aimed at. Specifically, would a "deterministic" build really help much?

edit: I am perusing [https://blog.torproject.org/blog/deterministic-builds- part-o...](https://blog.torproject.org/blog/deterministic-builds-part-one- cyberwar-and-global-compromise) and [https://blog.torproject.org/blog/deterministic-builds- part-t...](https://blog.torproject.org/blog/deterministic-builds-part-two- technical-details) Good reads so far.

<comment> raving-richard Please have a look at David A. Wheeler's page on Trusting trust [1], including his 2009 PhD dissertation [2], where he clearly demonstrates that it is possible to have trusted (not in the MS sense...) computers (I think).

You may also be interested in 'Countering "Trusting Trust"' on Schneier's website [3], which discusses a 2006 paper, also by Wheeler.

[1] [http://www.dwheeler.com/trusting- trust/](http://www.dwheeler.com/trusting-trust/) [2] [http://www.dwheeler.com/trusting- trust/dissertation/html/whe...](http://www.dwheeler.com/trusting- trust/dissertation/html/wheeler-trusting-trust-ddc.html) [3] [https://www.schneier.com/blog/archives/2006/01/countering_tr...](https://www.schneier.com/blog/archives/2006/01/countering_trus.html)

<comment><USER6> My memory on that was that it let you know whether you could trust your compiler. I couldn't remember if it extended ot the rest of the tool chain. Nor did I remember if it really hinged on deterministic builds. I'll have to retry it.

<comment><USER7> Strictly speaking, it lets you know that your compiler binary matches its source. You can then read the source to decide if you trust the compiler (and others can audit it, can audit binaries generated from it, &c, &c). At which point, as raving-richard says, you can start to trust that your other utilities match their source as well. Which source also should be audited, &c, &c.

<comment><USER6> Right, my point is having deterministic builds of firefox aren't even really needed for this. If you trust your compiler, you trust your compiler. What does it matter if you have a non-deterministic build of a utility. You trust what is non-deterministically building it.

As this stands, if you deterministically build firefox, you just know that if your toolchain is corrupted, it is consistent. :)

Right?

<comment><USER8> If you trust your compiler you can verify that your build is the safely based on the source that you have. If the build is deterministic then you could verify that the binary being distributed to the masses isn't compromised by building the same file yourself and seeing that it is the same.

<comment><USER6> Right, and my question is essentially if this is "putting the cart before the horse." Do Mozilla have efforts in place to establish trust of their compilers? (I expanded on my response below. I really wish I knew the correct way to "merge" conversation trees here. Is there a good protocol for that?)

</comment></comment></comment></comment></comment></comment></comment></comment><comment> raving-richard Even if you hate Bitcoin for other reasons, this is one reason to appreciate it. Gitian, the software used by Tor for deterministic builds (of their build of Firefox especially), was originally written by Bitcoin developers. Which makes sense, you want to make sure your money is secure.

Good things come out of things you might hate.

<comment><USER9> Deterministic builds are pretty neat. I think the second equally important piece is a a Web of Trust full of people willing to reproduce the build and sign off on the hashes.

I was able to reproduce the sha512sum of the Bitcoin back when 0.9.0 came out without too much trouble, but it definitely took a couple hours to get it all working.

I feel a bit bad I didn't take the next step and attach my digital signature signifying that I could reproduce it. There are only a few people other than Gavin who go to the trouble of signing off on the hashes.

I wonder if Docker could be used to speed up the overall process and make builds more accessible. As I recall, the current scripts setup a single-core KVM which definitely slowed things down.

<comment><USER6> Docker _could_ speed up parts. But, unless I misunderstand what you mean it wouldn't really help the trust aspect. You'd just be shifting your trust to the docker pieces. (That is, then the goal shifts to "can anyone reproduce the docker container?") Right?

</comment></comment></comment><comment><USER10> Before everyone gets up in arms about Mozilla not working on this: As I wrote the last time this came up, deterministic builds are a nice thing, but they're only a small piece of the puzzle of protecting users from the state-sponsored malicious actors. Indeed, it seems to me that messing with builds would be one of the more difficult ways for the NSA to pwn Firefox users.

[https://news.ycombinator.com/item?id=7045605](https://news.ycombinator.com/item?id=7045605)

</comment><comment><USER11> Or use Gentoo, that's what I do. You can verify hashes/signatures on the Firefox source archive and audit the source code if necessary before compiling.

That was only half serious - I know that are valid use cases for people to prefer using binary distros. However I think this particular issue is a good example why IMO even binary distros need to provide a convenient option to locally build any package for security conscious users.

<comment><USER6> That sounds tangential. The point is if two people build the same thing, they _should_ be able to compare their builds to see if they are truly the same. If not, the argument is that one of them has a "tampered" environment.

In other words, if you don't know your compiled binary is the same as the distributed binary, you have no reason to think yours does not have a vulnerability added by the toolchain.

Unless I'm the one that is misunderstanding, of course. :)

<comment><USER11> Well it's a solution to the same underlying problem - that by running binaries compiled by a 3rd party you trust that they aren't adding in code to compromise your privacy (voluntarily or not). If you compile the application from source yourself you don't need that leap of faith - no need to compare identical binaries or have deterministic builds (which is not trivial as the bug report demonstrates).

<comment><USER6> I'm not sure your solution solves that. If Firefox has vulnerabilities in the source right now, you do little to protect yourself by compiling on your own. Even if you can verify that you and someone else produce the same binary, they could just both be vulnerable.

In fact, if you compile it yourself, _unless_ you can verify the compile against a "known good" one, then you can't even be sure that your local toolchain hasn't been compromised. (I mean, sure, if you were a perfect auditor of your entire toolchain, then you could have some confidence here. You have to be perfect, though.)

Consider, you do a compile of Firefox and it is different than the one for download. Why? As things stand now, _you don 't know._ And that is the problem.

<comment><USER12> > If Firefox has vulnerabilities in the source right now, you do little to > protect yourself by compiling on your own.

You do more to protect yourself than taking the same vulnerable source and compiling it with Mozilla's "reproducible build chain".

If the source itself is corrupt then having a verified build of malicious source is completely useless.

With Gentoo you can verify the source itself matches the "trusted" upstream source and then build it with your own trustworthy build chain.

And before you go "what if your build chain isn't trustworthy huh????" think about it a little further... if your own local build chain can't be trusted you're already screwed even before you download anything from mozilla.org, just as you'd be if you downloaded a "bit verified" binary from mozilla to run on your already-pwned local operating system.

<comment><USER6> No you don't. You do _nothing_ to protect yourself from vulnerabilities in the code by compiling it yourself. Literally nothing.

You _do_ protect yourself from vulnerabilities in their toolchain. And this is where the effort makes sense. If there are differences in the builds, then you can at least suspect one of you has a tampered environment. Right now, you have no way of knowing that one way or the other. You just have the joy of having done your own build.

My main question is still just one of magnitude. Consider, I have not had a wreck or other car mishap in 20 years. I could conclude that seatbelts, then, have not increased my safety really. I am _not_ trying to make that claim, as I feel it is false. So, my question here is essentially, how much safer would this really make things? (Or trustworthy, if you'd rather that term.)

</comment></comment></comment></comment></comment></comment><comment><USER13> deterministic doesnt really mean trust per se to me. it means reliable.

if you dont know what you're getting every time its hard to be any reliable.

of course, if you're reliable, its more trustable.

<comment><USER14> Repeatable, "reliable" only in the sense that you can rely on the outcome.

<comment><USER13> here's the difference:

\- make the build system reproducable, so that every build is exactly the same binary, no matter who runs it. that's "easy". But you don't know _why_ you get that exact binary

\- make the build system verifiable, or the resulting binary verifiable so that you know exactly why you get that binary. This is hard.

The first one is repeatable, reliable.

The second one is trustworthy, verifiable.</comment></comment></comment>


Things a Good Product Manager Should Think About   - <AUTHOR> http://www.jpuopolo.com/2011/09/5-things-a-good-product-manager-should-think-about/ <comment><USER2> "Keep an eye on what really matters...[a]It will help make money...[b]It will improve the user experience..."

I've had considerable difficulty with PMs in the past regarding the paradox between a&b. Lots of "wouldn't it be cool if it could do this?" questions are answered by b, but an overzealous PM might say no, justifying against a...and it's easier to build justifications around feature bloat and that seems to be where lots of dev cycles are spent in most companies.

Ref: see Microsoft vs. Apple's approaches.

</comment><comment><USER3> From a Product Management standpoint, this is good advice.

But what do you do when you're a software developer who sees these problems but have your hands tied by management?

<comment><USER4> It depends. I found myself in that situation and just started doing the job, but this requires your boss' approval, since it will take time away from coding and cost money. To do this, you have to have a current gap in product management (as opposed to PMs making bad decisions). This was my path into product management.

If you can't get your boss' approval or there is existing product management, you can try sitting down informally with them. Explain your concerns, but be tactful (this part is hard for many engineers who are completely data driven). You have to be careful not to get people defensive. Go in with an attitude of "I see this as suboptimal, teach me why I'm wrong" instead of "You're an idiot, you should be doing this thing instead". Make sure you are being objective, though. I've had engineers fight me on what "should" be done because they were only looking at technology instead of the whole business.

If neither of those work, you are probably going to get frustrated quickly. Few things did more damage to my team's morale than feeling like they were working on something useless.

</comment></comment><comment><USER5> I agree with almost everything except point 1. A Minimum Viable Product is exactly that-- the smallest possible product that will be viable in the marketplace. Some startups and developers may take this thinking overboard and put products on the market that are so stripped down as to not be viable, but I think that the concept of a true MVP sums up the entire purpose and challenge of Product Management.

A true MVP must strike the balance between feature bloat and watered down junk, driven by a vision of what users need as opposed to what they think they need. Such vision requires a lot of insight and a lot of courage. Imagine being the PM that decided the iPhone was ready to ship without support for copy and paste. Is copy and paste an important feature for a mobile phone? Obviously. Was it necessary for the product to be viable in the marketplace? Clearly, it wasn't, and that is why determining a feature set for and MVP is such a challenge.

</comment><comment><USER6> "Well thought out features that deliver value, even if they take a bit longer to come to market, will (in my opinion) deliver more ultimate value to the product and to the user experience."

The important thing to notice there in the quote is that there are two steps to "delivering more ultimate value".

The first step is more thought. Well obviously. No-one is saying slap any load of crap down and expect someone to pay for it.

The second is "that deliver value". This appears to be the one most missed by people, in my experience, and is the raison d'etre of MVP. If the market doesn't exist and if you aren't solving a genuine problem that you can both communicate and be delivered economically then it doesn't matter how much you "think".

This is why MVPs are important: an empirical guide to work out what should be done, not sitting at your desk pontificating with your wise-ass rationalisations, abstractions and reductions of human behaviour and reality.

</comment><comment><USER7> Do startups actually need product managers? A few months back, a job posting for a designer at inDinero included a sidebar that asked this question. Jessica suggested that the answer was "No".

It seems that product managers are not required when a company is relatively small, and a co-founder has the bulk of his/her time to dedicate to product development. In such a case, a team need be made up of only engineers and designers.

Even when teams are larger, new-ish web application frameworks like Rails make deployment incredibly easy/fast and all of the "strategic thinking" that a PM might ordinarily contribute is done with live product. In these situations, all of the activities listed in Joseph's blog post - focus, vision, avoiding frankensteinism, customer-centricity - could be handled by a product designer or product-minded engineer.

Are product managers a thing of the past? Seems increasingly likely.

<comment><USER8> inDinero has what, five employees?

As teams grow and the scope of what they do grows, the need for specialization also grows.

Let's assume a wonderful team of world-class engineers who all happen to have the same skills as a world-class product manager, and who all like product management work. (If you like, they can all also be world-class designers.)

In my experience, pure product management work grows pretty linearly with the number of developers. (Providing they're organized, more developers means more projects or increased velocity on existing projects. Either means more product work.)

In this situation, each developer could spend X% of his time on product management work. (Let's say X% = 10%, since in my experience one product manager can keep ten developers busy.)

Great, you might think. Since every one of these developers can do and likes to do product management work, they'll each devote 10% of their time to it, and everything will work out fine.

There's only one problem with that - great products aren't built in small isolated portions. In order to be an effective product manager, you've got to know the whole product - so everyone doing any sort of product work has to coordinate with each other. As the team grows, so does the coordination overhead.

Even assuming a perfect central repository of knowledge (an uber-wiki?), so each developer only has to do a knowledge dump once, just consuming and synthesizing all the information created by all other people takes an increasing amount of time. And then there's the need to reach consensus when people's syntheses disagree, as they invariably do.

In these situations, as the team grows and/or the product gets more complex, someone inevitably ends up spending an increasing amount of their time on product, while others stop spending any. Someone becomes the guy who makes product decisions, while others defer to that guy.

Perhaps, when the dev team is ten people or so, that product-focused person's still spending a bit of time coding, and still calls himself a developer. But as the team grows, it's inevitable - you will either hire external dedicated product managers or you will grow them yourself from the inside.

</comment></comment><comment><USER9> Grammatical errors aside, I like the ideas represented here.

However I think the post would have more impact if it was followed up with concrete examples. Take MVP for instance, are there any known failure cases that would demonstrate why it's important not to rush half-baked ideas out the door? I certainly can understand how shipping bad functionality can create a huge negative opinion of a company and it's products. However, how do you convince others, especially your boss, that it's a bad idea? Explaining what might happen usually gets you nowhere, pointing out other disasters sometimes gets their attention.

This type of analysis could be performed on each of the 5 things and in doing so would make for a far more interesting read. As previously said, I like the ideas it just seems to be missing information that would make it feel complete.

<comment><AUTHOR> Thanks for reminding me about the grammar, constant challenge :)

I have lots of examples, perhaps I will do a follow up on that. I will have to talk about most of those examples with a beer in hand, that is a prerequisite.

Joseph

</comment></comment><comment><USER10> It's super difficult to find a startup PM at the beginning, partially because it's super difficult to find another person who has the same product vision. It's much easier for the founder with strong conviction to see the product through, at least to a stage where it's been proven by the market.

</comment><comment><USER11> I think a lot of these points can apply to founders, too, and not just product managers. Especially in regard to the MVP concept, I think a great point is made here a lot of people mistake an MVP for an incomplete/half-working thing. This isn't always the case, though, it's more common to see that than it is to see fairly polished work being released. One of my all time favorite companies, Metalab, hosts a series of products that look and function like apps that have gone through rigorous iteration but in reality are on their first (sometimes beta) release.

<comment><USER12> Founders are, by definition, product managers, at least until they can hire a dedicated one.

</comment></comment><comment><USER13> I wish someone at Cisco systems would religiously enforces some of these standards. They consistently approach products at a minimally viable level and they almost always become frankensteins because of it. Just one of many reasons they've been in some financial hot water in the past few years.

</comment><comment><USER14> The Frankenstein problem is huge. Look at the clutter on Yahoo versus Google. Absolutely captures the difference in focus and culture.

Frankenproducts are a sign of a bloated middle management that isn't willing to make a stand on win-lose tradeoffs.

</comment><comment><USER15> great post joseph, nice to get some perspective from the others side on the huge MVP trend.</comment>


Letter of Resignation from the Palo Alto Planning and Transportation Commission - <AUTHOR> https://medium.com/@katevershovdowning/letter-of-resignation-from-the-palo-alto-planning-and-transportation-commission-f7b6facd94f5#.q0e65fvah <comment><USER2> One thing I don't recall ever seeing addressed in this and similar pieces about NIMBY-caused housing issues is how to deal with the current residents who, for various reasons, don't want change. In cases where they are the majority of the voting power and/or influence, what methods exist to protect those who are in a position to exact this change? Seems to be if the system is broken, you need to find another way...

Also, I'm curious what residents of Palo Alto who resist this change think about the risks and proposals (if any here are brave enough to voice their opinions). I'm genuinely curious. Is it fear of increased crime and lower property values if they let in lower income people via more affordable housing?

<comment><USER3> >Also, I'm curious what residents of Palo Alto who resist this change think about the risks and proposals (if any here are brave enough to voice their opinions). I'm genuinely curious. Is it fear of increased crime and lower property values if they let in lower income people via more affordable housing?

It boggles me that a $146k/year income could be considered _low_.</comment></comment>


The Founder's Guide to Discipline: Lessons from Front's Mathilde Collin - <AUTHOR> https://firstround.com/review/the-founders-guide-to-discipline-lessons-from-fronts-mathilde-collin <comment><USER2> Just switched our office to Front. The discipline in the article is highly visible in the product. Nowhere in the product do you get a whiff of the typical job-half-finished-ship-now attitude that pervades SV. Every feature works as intended. I can't imagine the amount of testing they do, but getting to this level of quality takes hard work and discipline.

<comment><USER3> I think I'm a bit slow here - what does Front do? Some sort of way as managing communication between a customer and a business?

<comment><USER2> A shared inbox. The thing Google doesn't want you to have

</comment></comment></comment><comment><USER4> So I was interested in trying Front, and it looks like just what I need, but JESUS, what a terrible way to greet people to their site. The title is flashing with kind of instant chat, half the page is taken up with "HI!!!!!" banners. Does this actually convert?!

<comment><USER5> You're right that is the most annoying website so far. They're taking April's fools too far.

<comment><USER6> Maybe I'm missing something...

I see the chat bubble in the bottom right. Pretty standard nowadays. Nothing uniquely bad about it here.

And that's all that's jumping at me? The rest is the normal website. What else is annoying?

<comment><USER4> [https://imgur.com/a/ima8puj](https://imgur.com/a/ima8puj)

Top and bottom seem to be some kind of contextual banner, also the bottom part keeps changing colour between primary colours. The title of the tab keeps flashing back and forth. I think the bottom part may be meant to be some kind of navigation? But it's partially obscured by the chat box, which has no obvious way to dismiss it.

It has taken significant willpower not to close it down and never come back, and I am their target customer and in a buying mood.

<comment><USER7> I don't think they've tested their website design at smaller window sizes - full screen for me looks fine, but when I reduce the windows size things start overlapping unpleasantly.

Personally, I'd rather they stopped the transitions while scrolling and keep it a bit simpler so it resizes properly!

</comment></comment></comment></comment></comment><comment><USER8> I have been following this thread all day, hoping for some additional discussion. It seems that won't happen, too bad. My $0.02:

To quote Edison: "Genius is one percent inspiration, ninety-nine percent perspiration". The article explains Mathilde's approach. I'm impressed with her rigorousness and consistency. It's a great way to build trust both internally and externally.

Building something (anything) from scratch to _really_ complete is an exercise in persistence. Being in the same boat right now, I admire her for what she's doing and how she's doing it.

</comment><comment><USER9> Is anyone else impressed by the text-to-speech audio? I could see myself using this to consume a lot of written content while on my commute. It's mostly very natural sounding. Does anyone know what tts tech is used here?

</comment><comment><USER10> Firstround shills for their founders like no other. No mention of the discipline as it relates to profitability, a healthy CAC:LTV, equity efficiency - but plenty of vanity metrics to go around, naturally amount of money raised and team size. These VC fluff pieces are increasingly insufferable PR.

<comment><USER11> It's insane to refer to this article as a fluff piece. It's a detailed, transparent, numerical, inside look at how a particular founder runs various aspects of her business.

It's one of the _least_ fluffy pieces I've seen about a startup.

<comment><USER12> Is this one of those "great businesses" that's never turned a profit and will disappear like a puff of smoke in the next economic downturn?

<comment><USER6> Read the article.

See where she says "we're default alive" in an email to her company?

That means they were profitable back in 2016. I assume now with extra capital that might not be the case, but that's the re-invest in the growth strategy, a la Amazon (which is smart).

</comment></comment></comment></comment><comment><USER13> I think a TLDR here would be:

Discipline, not vision. Habit, not motivation.

(I wonder often whether discipline is another method my brain tricks me to block out cynicism?)</comment>


Jane Jacobs' Radical Legacy (2006) - <AUTHOR> https://web.archive.org/web/20060928205849/http://www.nhi.org/online/issues/146/janejacobslegacy.html <comment><USER2> This article is also available on the author's website:

[http://www.peterdreier.com/wp- content/uploads/2014/04/Jane_J...](http://www.peterdreier.com/wp- content/uploads/2014/04/Jane_Jacobs_Legacy.pdf)

Another version of the article:

[https://www.huffpost.com/entry/jane-jacobs-radical-legacy- ci...](https://www.huffpost.com/entry/jane-jacobs-radical-legacy-cities-are- for-people-not-developers_b_9835946)</comment>


Little Jumping Bot Can Now Stick the Perfect Landing - <AUTHOR> https://hackaday.com/2020/08/02/little-jumping-bot-can-now-stick-the-perfect-landing/ <comment><AUTHOR> Here is a video about this robot. [https://www.youtube.com/watch?v=qFmeHPVtK0o&feature=emb_rel_...](https://www.youtube.com/watch?v=qFmeHPVtK0o&feature=emb_rel_end)</comment>


Flask web application development. Introduction - <AUTHOR> http://www.vertabelo.com/blog/technical-articles/web-app-development-with-flask-sqlalchemy-bootstrap-introduction

<comment><USER2> this is good information about the flash website. If you want to make website in flash this article very helpful.</comment>


Getting a Flask website up and running in Ubuntu - <AUTHOR> http://kramerapps.com/blog/post/22551999777/flask-uwsgi-nginx-ubuntu

<comment><USER2> If you don't want to mess with setting up Web servers, sign up for a Heroku account (<https://api.heroku.com/signup>), and host it on a free dyno.

First set up the Heroku "toolbelt" (<https://toolbelt.heroku.com>), and once that's done, you can run this bash script (<https://gist.github.com/2622850>) to create and deploy a "hello world" Flask app on Heroku:

      $ heroku login
      $ bash setup.sh helloworld
      $ cd helloworld
      $ git push heroku master

It should return a live Web URL for your app:

      http://strong-stream-5848.herokuapp.com deployed to Heroku

Kenneth (<http://kennethreitz.com>) has shown you can get good performance with Flask on the free dyno ([http://flask.pocoo.org/mailinglist/archive/2012/2/22/flask-o...](http://flask.pocoo.org/mailinglist/archive/2012/2/22/flask- on-heroku-%2B-gunicorn-static-files/#cff05916ae6854557b93d0226cb87151)).

See the Heroku Quickstart (<https://devcenter.heroku.com/articles/quickstart>) and Python tutorial (<https://devcenter.heroku.com/articles/python>) for details.

<comment><USER3> Or Google App Engine, which is even easier. All you do is load your application into their GUI and click 'deploy'.

There are templates abound:

<https://github.com/gumho/minimal-flask-gae-template>

<https://github.com/kamalgill/flask-appengine-template>

<https://github.com/toomore-such/template-gae-with-flask>

</comment></comment><comment><USER4>
      wget http://nginx.org/keys/nginx_signing.key

I don't understand why someone would go to the trouble of signing their packages, and then serve the key exclusively over HTTP.

<comment><USER5> "Me too!" security, where you add "security" not because you understand it and its benefits, but because other people do it.

</comment></comment><comment><USER6> Here's how to do the same thing on dotCloud:

Step 1: sign up for a dotCloud account: (<http://dotcloud.com>)

Step 2: Follow these steps: <http://flask.pocoo.org/snippets/48/>

<comment><USER7> Yesterday I spent 2 hrs to figure out why dotcloud keeps telling me that it finds no uwsgi. I managed to load another flask website with the same structure. I am now thinking numpy and pandas may be too heavy?

Anyway, a detailed log of pushes would really help a lot.

<comment><USER6> Hi there, you can definitely install numpy and panda into a dotcloud app. Simply add them to a file called requirements.txt, they should be installed automatically.

You can run 'dotcloud logs' to access detailed logs of your app's deployment and activity, that might help.

Otherwise drop us a line at firstname.lastname@example.com and we'll be happy to help you out!

<comment><USER7> Thanks!

</comment></comment></comment></comment><comment><USER8> Call me lazy but I found it much easier to host on apache and mod_wsgi. Ubuntu/debian derivatives have a nice easy to manage virtual hosting system.

Quite impressed with flask though - lovely simple framework that works the same way my brain does.

</comment><comment><USER9> Why not use nginx/uwsgi/virtualenv from ubuntu repositories? In case of uwsgi, you'd get ready-made upstart and logrotate scripts, and with virtualenv you get automatic updating with the rest of packages.

<comment><AUTHOR> I prefer using the latest stable versions and not having to depend on the Ubuntu packages to be updated.

</comment></comment><comment><USER10> is the use of /srv as the installation location a good choice? I usually install all my apps under /var/www or /var/apps.

<comment><USER11> It shouldn't make any difference, except that /var may be on a filesystem on its own (but this is becoming quite uncommon nowadays).

<comment><USER12> So might /srv.

</comment></comment></comment><comment><USER13> Great post...may I suggest expanding on this and install a database as well and a templating engine

<comment><USER2> The Jinja2 templating engine (<http://jinja.pocoo.org/docs/>) is installed by default with Flask.

<comment><USER13> I understand...but I rather stay within python syntax as much as possible and use something like Mako.

I know you might send me to pylon, but flask's simplicity and flexibilty make it more alluring to me.

</comment></comment></comment><comment><USER14> How much of this will work on a Mac?

<comment><AUTHOR> If you read the 'Portability' portion on the bottom, you can run a test server with just uWSGI. For actually deploying with Mac, that would be entirely different.</comment></comment>


How A. Q. Khan made Pakistan a nuclear power (2005) - <AUTHOR> http://www.theatlantic.com/magazine/archive/2005/11/the-wrath-of-khan/304333/?single_page=true <comment><USER2> Did not read the article yet- but cityscale destruction, shipped around through the evening traffic in unmarked Vehicles, with only 15 soldiers attached to it. Its understandable that everyone wants to be a nuclear power now. Since the obvious break down of international law during the second iraqi war with further help by the ukraine-incident, the only thing preventing you from getting snuffed out of existence as a state is a mean bite. But a country with so many problems as pakistan, basically takes the world hostage. I rather have nuclear weapons in norht korea- at least society there seems, at the low level they are, stable and immune to collapse.</comment>


Interview with FLIF Creator Jon Sneyers - <AUTHOR> http://thepracticaldev.com/ben/interview-with-flif-creator-jon-sneyers <comment><USER2> > _The nice thing about this approach is that you get the advantages of lossy > compression (much smaller files that are visually still OK) but fewer > disadvantages: in particular, the problem of generation loss does not > apply._

I've been following FLIFF (and BPG and such) for a while but was not aware of this benefit to other formats.

Is this unique to FLIFF or something that is true for lossy encoding to lossless compression formats in general?

<comment><USER3> Maybe think of it by analogy. Suppose my compression format (dibs, patent pending) is an uncompressed RGB pixel list, stored in a ZIP archive. Let's call that SuperCompress Level 0.

I can improve the compression a little by rounding the pixel intensities in the pixmap, e.g. clearing all low bits. Call that SuperCompress Level 1. This operation is idempotent: you can't throw away the same data multiple times, so there's no generational loss. More importantly, the resulting data is completely compatible with SuperCompress Level 0, because the "lossy encoding" (rounding our numbers) is decoupled from the "lossless compression" (ZIPping!). This is effectively what FLIF and TruePNG/near_lossless-WebP are doing.

NOTE though that even our archetypal lossy JPEG image _can_ be re-encoded without generational loss: if you use the same quantisation tables and the same pixel alignment, and you haven't fiddled with the pixel intensities, then subsequent encodings don't throw away anything you haven't discarded already. If however you save it with a different quality each time then you'll find yourself with jarring Cubist-style artefacts. Proponents of lossless image formats are well-versed in this technique ;-)

Generational loss emerges from destructive changes that are not really related to the image format. If the only changes you're doing are cropping images on 8x8 pixel boundaries, then JPEG compression at a fixed quality is effectively "generationally lossless". Gamma/colour corrections applied to an image are at least a little bit lossy in any format, because there are rounding errors inherent in that process. Compositing image regions is also hugely destructive, but (assuming suitable alignment and encoder options) there will be generational loss around the boundaries of the regions while the interiors remain unchanged.

Realistically, most Egregious JPEG Artefacts result from resizing and/or cropping the image, then re-saving repeatedly. That's 90% of the internet, and probably another 9.9% if we throw in "adding a sassy caption in Impact Bold". This is unfortunate because it really plays to JPEG's weaknesses. If the "lossy preprocessing step" implemented in FLIF (or the other lossless formats) is robust against that particular abuse then it could be immensely useful.</comment></comment>


"Pwned Passwords" V2 With Half a Billion Passwords - <AUTHOR> https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/ <comment><USER4> I think it would be interesting to do an art project with this data - some of these passwords are funny and/or revealing. Some examples:

      pooplasagna - 3 times
      eggsarebad - 3 times
      eggsaregood - 25 times
      myhusbandcheats - 4 times
      icheatonmywife - 1 time
      ihatemyneighbors - 2 times
      iamanalcoholic - 6 times
      1yearsober - 31 times
      imissmykids - 51 times
      imissmyparents - 6 times

<comment><USER5> 6618 people love life, 1367 want to die.

893 people like turtles, 170 love turtles, 155 love everyone (363 people hate everyone though and 428 hate us all).

4301 people love their dog, 3 fuck their dog, 3 killed their dog (only one person killed their cat)

110 people are killers, 4 kill for money, 1 is a murderer. 68 want to kill, 24 kill for fun :-/

2781 love their wife, 552 love their husband. 68 people hate their wife, 38 hate their husband. 3823 people love their son, 17 hate their son. 212 love their daughter, 3 hate their daughter. 11 siblings are having sex with one another. 3 have sex with their dad, 5 have sex with their mom.

6 people save the cheerleader, 11 people save the world. 1 person is the president. 4 people are obama, only one person is trump. The password donaldtrump is almost 5 times more popular than barrackobama.

339 people love sun, 559 love rain.

114 people are healthy, 216 are sick. 108 people are old, 3 people are too old. 15 people sleep well. 80 people run fast, 6 people run faster. 1 person is the fastest (obviously).

All this is quite facinating and fun .. and partly disquieting.

jesus - 123279 times, lordjesus - 8187, satan - 11662 times, iamgod - 8834, iamjesus - 345 times, jesussucks - 100 times

<comment><USER6> > 1 person is the president

Don't tell me he actually made that his password...

<comment><USER5> i just checked, at least not his twitter password..

</comment></comment></comment></comment><comment><USER7> do _not_ skip the section on "Cloudflare, Privacy and k-Anonymity" ... it is a great summary of an elegant privacy solution.

And check out Cloudflare's detail post too:

[https://blog.cloudflare.com/validating-leaked-passwords- with...](https://blog.cloudflare.com/validating-leaked-passwords-with-k- anonymity/)

<comment><USER8> Why does 0000 have the largest number of hashes? Does SHA-1 not distribute hash values evenly?

<comment><USER9> It's indeed weird that "00000" would be the hash prefix with the highest number of entries. I think it must be a hidden variable. Like some sources put an all-zeroed-out hash in the database for testing or in case of a registration error or for deleted users, and these show up here.

<comment><USER10> Great thought, but it doesn't seem to be the case - as the number of unique suffixes is the large number here -- in fact, none of the values in the range are simply all zeroes.

[https://api.pwnedpasswords.com/range/00000](https://api.pwnedpasswords.com/range/00000)

I wonder if the hidden variable is something to do with how the passwords are leaked. First, let's suppose that a very commonly used broken password hash is plain SHA-1 (I think that's a valid assumption-- unfortunately!). Then, let's figure that amongst the many data dumps / extracts done by hackers, some of them are only able to extract part of the database, or save part of the database, or whatever....and they are fetched / saved / uploaded in lexical order?

Can't think of anything else.

EDIT: Ooops. The other thing is, that these actually are sha-1 hashes of real plaintext passwords. So it's definitely not a test-row in that sense.

</comment></comment></comment></comment><comment><USER11> That moment when you test an old, but still highly valued and securely used, password that you think isn't super obscure but not likely to be used much and see a 4000+ count...

<comment><USER12> That moment when you test a very unique password you used to use and it's been pwned once.. GULP! Glad I stopped using that one

<comment><USER13> Same experience here, except mine was current until shortly after I checked it.

The weird part is that I only used it on internal systems at work. With an overly paranoid security department. Either they're paranoid in the wrong ways, or I have an evil twin somewhere.

At least, I _hope_ they're the evil twin...

<comment><USER12> time for some soul-searching

</comment></comment></comment></comment><comment><USER14> Am I the only one here who thinks typing your password to a stranger's website is a risk? How do you know he does not log it? how do you know he was not hacked and someone is not logging all passwords that are not on the list YET.

<comment> maze-le If you don't trust troy hunt / haveibeenpwned.com you can always download the data and analyze your password yourself. But if this is the case you should not trust any website with your password anwhere ever, and should not create accounts anywhere. Troy Hunt has shown himself a responsible security professional, and I trust him more to create a secure password query than some other security organizations.

<comment><USER15> "But if this is the case you should not trust any website with your password anwhere ever".

That is why you should use unique password for each site.

<comment><USER16> This is absurd and impossible to remember, you should instead have at least 3 levels of password strenght, one high strenght for base services that are used to retrieve other accounts like facebook and e-mail, other for important services, and another for crap.

<comment><USER17> You're not expected to remember them all, you're expected to either wrote them down or use a password manager. That way you only really need to remember one very strong password.

</comment></comment></comment></comment></comment><comment><USER18> An old password (12 char numbers and letters) I've since stopped using (but used to use everywhere) appears as pwned in this list (3 times!). I'd love to know who exposed it. Any chance I can find out?

<comment><USER19> As a policy Troy Hunt won't reveal which breach he found your data in. I considered setting up a series of 'canary' emails so that I could track who's selling what but ... well never got round to it.

<comment><USER20> You used to be able to adjust your email address to check. For example if you email was email@example.com, you could sign up for HN with firstname.lastname@example.com. Gmail ignores the part after the + sign. Therefore if you noticed emails coming to that address, you would know that HN sold their list. However, I've found that most forms reject that as a non-valid email address now.

<comment><USER21> Yes. Those forms are also ignoring relevant RFCs.

<comment><USER22> Can you be more specific?

<comment><USER23> Many sites reject valid email addresses. One character it is common for forms to reject is a "+" in the left hand side of an email address. The email RFCs allow this character, so denying it is bogus. Nevertheless, they do.

[https://tools.ietf.org/html/rfc2822#section-3.4](https://tools.ietf.org/html/rfc2822#section-3.4)

atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / " * " / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

atom = [CFWS] 1 * atext [CFWS]

dot-atom = [CFWS] dot-atom-text [CFWS]

dot-atom-text = 1 * atext * ("." 1 * atext)

...

addr-spec = local-part "@" domain

local-part = dot-atom / quoted-string / obs-local-part

</comment></comment></comment></comment></comment></comment><comment><USER24> The UX of a blacklist with a half billion entries would be so crippling that it would cause a user revolt.

Most people's password-selection strategies are similar enough to other people's (like kbenson's 4000+ hit) that they could spend _hours_ trying to come up with a password that has never been leaked before.

I tried to encourage Troy to suggest to implementors that blacklisting all passwords was a Bad Idea. Instead, he doubled down:

[https://twitter.com/TychoTithonus/status/966400790221930496](https://twitter.com/TychoTithonus/status/966400790221930496)

Please don't use the entire list for blacklisting _unless_ you actively also guide the user in how to generate a random passphrase (if a human must remember it) or a random password (if it will be stored in a password manager).

Instead:

1\. Use a high-level password-strength assessment widget like zxcvbn:

[https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

2\. Configure a blacklist with, say, 10K or 20K of the most common passwords.

3\. Hash passwords with bcrypt cost 12 (adjusted to your platform's hashrate capabilities), scrypt, or the appropriate method from the Argon2 family.

But for all that is holy, please don't use Troy's entire corpus - or even the first million - as a blacklist. To quote the old NANOG saw, I encourage all of my competitors to use it. ;)

Edit: And since Troy's API at this writing does not support only querying the top X passwords, there's no way to use the API while avoiding the UX nightmare. So if you want to use this data in a professional manner, but don't want to download the entire corpus, here are the first 20K from his list (of which I've only personally cracked 19965 so far, interestingly; gist will be updated once I get all 20K):

[https://gist.github.com/roycewilliams/281ce539915a947a23db17...](https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7)

Edit 2: Preliminary results indicate that this data may be dirty. The 273rd most common password, according to Troy, is '$HEX'. This is almost certainly an import/conversion artifact, since the '$HEX' prefix is how most cracking suites escape non-ASCII or passwords that contain colons. I expect that there will be more artifacts. Use the data with caution.

<comment><USER11> > I tried to encourage Troy to suggest to implementors that blacklisting all > passwords was a Bad Idea. Instead, he doubled down

> Please don't use the entire list for blacklisting unless you actively also > guide the user in how to generate a random passphrase (if a human must > remember it) or a random password (if it will be stored in a password > manager).

I think he did the right thing, _and_ think you are correct as well. I think we have the best of both worlds with this, in that it includes the count, so API users can determine what the correct cut-off is for them. Once you get into the thousands (or maybe less) might be a good indicator that your password is not only _relatively_ common, but also likely to be on (and maybe even fairly high on) many dictionary lists. More secure services that cater to more technically savvy users (or security conscious companies) may decide to blacklist any password on the list period, and that may be okay because those sites either trust their users to deal with it or can dictate conditions for a captive audience.

<comment><USER24> As a corpus to download for password research, this is indeed useful. But for providing a blacklist -- his stated purpose - it is not.

The crucial tell: his API _does not allow the implementor to specify a frequency threshold_ (by top X in the list, or by Y number of unique uses of the password or higher).

By both API and explicit language in the announcement, he is promulgating the idea that checking the _entire_ blacklist is useful, and "the larger the blacklist, the better." This is _exactly_ what I'm arguing against.

<comment><USER11> > his API does not allow the implementor to specify a frequency threshold

Yes it does. The output contains the number of matching passwords. It's just client side instead of server side. The reason for not doing so on the server is also obvious taking into account his explanation of cost and caching, which informed much of the API design itself.

> By both API and explicit language in the announcement, he is promulgating > the idea that checking the entire blacklist is useful

Because the entire blacklist _is_ useful. He's given all the relevant information to the client to do with as they may. It's up to them to choose how to utilize it. I'm not sure why you seem to think some narrower use case is necessarily better, using end use cases as arguments, given it's an API and needs a client implementation fore being usable anyway.

<comment><USER24> It's a fair point that raw password count is available.

But that value is an _absolute_ number, without any in-API context of the total size of the corpus. This makes expressing _relative_ rarity only possible by hard-coding the total size of the corpus into a calculation.

Put another way: the 20,000th position has a frequency value of "7889". But what does that _mean_? Where is that in the _distribution_ of password frequency? It's impossible to tell, without manually constructed context _that will change over time as the total number of passwords in his corpus expands_.

But more crucially, there is no way to tell _relative_ rank ("is this password in the top 20k?") using the API that I can see. That would make using the top X much easier. But with the K-anonymity "feature", there's no way to do that that I can see.

<comment><USER25> I don't follow - how is the relative rarity better than absolute frequency? What really matters is how common your password is - not how highly it's ranked in a compromised password list, which has no relevance to how common it may be.

You want to filter on users choosing a password that's been re-used across all compromised more than N times.

Filtering users on choosing a password that ranks N of M on a list of compromised passwords doesn't tell the user how _bad_ that password is.

In fact, once you get to the rail, the ranking is basically based on sort order and become irrelevant?

<comment><USER24> The ranking in Troy's list is based entirely on how common the words are. Here are the top 10, with their relative frequency:

      c4a8d09ca3762af61e59520943dc26494f8941b:123456 (20760336)
      f7c3bc1d808e04732adf679965ccc34ca7ae3441:123456789 (7016669)
      b1b3773a05c0ed0176787a4f1574ff0075f7521e:qwerty (3599486)
      5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8:password (3303003)
      3d4f2bf07dc1be38b20cd6e46949a1071f9d0e3d:111111 (2900049)
      7c222fb2927d828af22f592134e8932480637c0d:12345678 (2680521)
      6367c48dd193d56ea7b0baad25b19455e529f5ee:abc123 (2670319)
      e38ad214943daad1d64c102faec29de4afe9da3d:password1 (2310111)
      20eabe5d64b0e216796e834f52d61fd0b70332fc:1234567 (2298084)
      8cb2237d0679ca88db6464eac60da96345513964:12345 (2088998)

So ... what is the "right" threshold for N?

      $ for topx in 1 100 1000 5000 10000 20000 50000 100000 200000 500000 1000000; do \
        echo -n "$topx: "; head -n ${topx} pwned-passwords-2.0.txt | tail -1;
      done

      1: 7C4A8D09CA3762AF61E59520943DC26494F8941B:20760336
      100: 482FA19D5C487CB69ACDA19EEE861CC69D82CC94:272371
      1000: 5B9FE558F673D63309BEB13BFA5DA6C30A3CA1BF:64912
      5000: FE648FC459A6F6EF6CD347BEE3D494766239BBB5:19860
      10000: 2682A3DBA7A1452EE7EE9980F195C6A768055DA6:11055
      20000: 53490A3C8567342B57B6A4FF24908DF73182B357:6309
      50000: 7517CD23A308BBCD05E5AD24AA6AD054237ED470:3153
      100000: BA6D6A41B9548C523833627A8B0E5170558BE1EA:1752
      200000: E50E6893264519636E90E95B6B1A85D0A691E0B1:931
      500000: AF8DF653177BBB3FEE2DA68D314B94CB5281B4F3:381
      1000000: BDD57A4CAA691A3441C1190C6F087B58B2EE3EF6:186
      2000000: C824AF24AA8F2FD99AD6842DC0E4B49100D96161:93
      10000000: 352DB7177AB7848DF1C102234401097FE40EB87D:22

The third field indicates how common the password is in the corpus (for example, the single most common password - "123456" \- appears in the corpus 20,760,366 times).

So ... based on this data ... what is a reasonable value for that count, such that if the value is exceeded, the user should be disallowed from using the password? How much _real-world_ online or offline resistance is provided by disallowing, say, passwords used at least 186 times in the corpus (roughly a million passwords, though 5201 passwords are at the 186 mark)? (The answer should be self-evident; if it isn't, I can provide more background).

Put another way ... if the corpus was only 1M in size, those right-hand values would be much smaller. How could you determine the threshold then? What I'm trying to illustrate here is that it's not the absolute value of that commonality number that matters; it's the _relative rank_. But that relative rank can't be determined via the API; you must analyze the entire corpus directly - and then discard the vast majority of it for blacklisting purposes.

I totally get that the threshold might vary per implementation. But it varies much less once the hash is slow enough, and the authentication service is suitable rate-limited. In other words, any system that would get real benefit from a 1-million-word blacklist is one that _needs to be improved elsewhere instead_.

But Troy didn't provide any guidance about that, or even how to judge for yourself what the threshold might be. He just provided an API to blacklist a corpus of passwords that is three orders of magnitude larger than a properly designed system would ever need.

1\. [https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic- pass...](https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password- strength-estimation/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> [https://mostsecure.pw/](https://mostsecure.pw/)

No pwnage found. Still confirmed for most secure password.

<comment><USER27> ...this is a joke, right?

</comment></comment><comment><USER28> How do I submit a pull request on Github asking that "hunter2" be removed from his list?

<comment><USER29> For those who missed the hunter2 reference:

[http://bash.org/?244321](http://bash.org/?244321)

<comment><USER30> It was used just 16,092 times?

I thought the number would be much bigger.

<comment><USER31> I got 4,882 times. You're searching * * * * * * * right?

</comment></comment></comment></comment><comment><USER32> Can someone please just provide the exact shell commands to generate a compatible sha-1 of a password to grep against the database?

The article seems to ramble forever about how to perform online checks without discussing the basic offline secure option.

<comment><USER33> echo -n "password" | openssl sha1 | tr '[:lower:]' '[:upper:]'

<comment><USER34> You may also want to consider running `unset HISTFILE` before that to ensure that the line containing your password doesn't end up sitting around in your bash history.

<comment><USER35> Another way is to prefix the command with whitespace.

<comment><USER36> Only if..

        export HISTCONTROL=ignorespace

..is set (either by default or explicitly)

<comment><USER37>
      python3 -c 'import getpass, hashlib; print(hashlib.sha1(getpass.getpass().encode("utf-8")).hexdigest())'

Avoids history, doesn't echo to the terminal.

In fact, you should be able to just make a rudimentary CLI into Troy's API simply with:

      #!/bin/bash
      HASH="$(python3 -c 'import getpass, hashlib; print(hashlib.sha1(getpass.getpass().encode("utf-8")).hexdigest().upper())')"
      curl -sS "https://api.pwnedpasswords.com/range/${HASH:0:5}" | grep "${HASH:5}"

(It'll emit the line from the API response matching your pass; if it does, then that password was compromised. Bash isn't real good at error handling though, so my biggest concern would be what this might do if an HTTP/TCP error happened. I've attempted to throw -S there to catch that, but use with your head screwed on.)

</comment></comment></comment></comment></comment></comment><comment><USER38> Split brain your password storage.

Another table, another database or another storage system in general.

If an attacker SQL injections your database don't go spilling every hashed or unhashed password you've got.

I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, "username").

If someone gets into my network they need to get into my servers with the email addresses and then get into a secondary system where the passwords are stored.

I like my password systems to be a k/v store because there is no need to "query" it. I usually store the password under a key that _isnt_ the identifier. Instead using something like a database surrogate key.

Have a secondary system (microservice, private subnet) that simply returns a boolean representing if the provided non-email (key) and password (value) match.

Have that secondary system take the plain text password so it can do the hashing without letting the dependent service know what algorithm, salt or stretches you're doing. This will also allow you to easily roll over to new hashing algorithms over time without affecting the service that is doing th authenticating.

Edit: I'm not trying to be a know it all or a crabby old tinfoil hat a-hole. But it's passwords, man. When you leak them you ruin people's days/year/life. Building that system above takes a middle of the road engineer a day or two. Put the effort in. Every password leak makes _all of our jobs harder_. It's your companies responsibility to keep that safe. If you know that already, be the annoying guy that brings it up in every stand up. Make that debt known.

<comment><USER39> Sorry, but this is convoluted nonsense that can only achieve one thing: make yourself more vulnerable.

You want your security system to be as simple as possible, and to involve as little custom code as possible. Because you can and _will_ fuck it up if you try to be clever.

Hash and salt your passwords using a library designed exactly for that purpose (which means it will use a _slow_ hash). That's it, end of story.

<comment><USER38> ^ above is pretty damn simple.

I also never said "write your own hashing algorithm" I said abstract it so it's not sitting around in your ecommerce app code.

That is a simple security system. It's just not baked into your flagship ecommerce, blog or whatever else your storing the credentials to protect.

</comment></comment></comment><comment><USER40> [Pasting an old comment of mine on password managers, since I see people talking about starting to use Keepass. I hope this helps someone]

\----

If you're just starting, here's some guidance on setting up a password manager.

First of all: Don't be afraid of using one. It's not just more secure, it's super convenient. Never again will you ask yourself: Did I make an account for this website/service? What email did I use? Never again will you have to remember a password. Using a password manager is a quality of life improvement.

KeepassXC is what I recommend to people at this point. It's free and you own your data (your passwords). They live wherever you want them to live. There are plenty of online services that are supposedly more convenient but I have to say I trust them less -- YMMV (1Password is the best I'm aware of).

[https://keepassxc.org](https://keepassxc.org)

If you do use keepassxc, you get the added benefit of being able to store 2FA settings in it as well (if you store them in the same database as your passwords, be aware that you lose the security benefit of a second factor, however it is still more secure than not having 2FA enabled due to the One- time password component).

Put every account you ever made and ever make into keepass. Enable 2fa wherever you don't have it enabled. Add login URLs and notes. Generate your passwords from keepass itself; the password generator is really powerful and lets you very easily deal with site-specific shitty password limitations. I'm telling you this because, seriously, it's incredibly convenient to have this stuff as long as you're rigorous about maintaining it.

Oh, also, keepass has the full history of all your passwords. Need to look up an old password? Go into details and look at "History". You can also attach files to items (items don't have to be accounts at all, you can use keepassxc as a simple encrypted storage db).

Mobile support: Keepass2Android. Best android client, with google drive support. iOS I have no idea, suggestions welcome.

IMPORTANT: BE STUPIDLY PARANOID AND RIGOROUSLY CAREFUL ABOUT YOUR MASTER PASSWORD. That thing, together with your keepass database, unlocks all your accounts ever. Use a really long passphrase that you will never have to write down (if you do decide to write it down because you don't trust yourself, store it in a safety deposit box, don't put it in a bloody drawer). Make sure the device you unlock the database on is malware-free.

PS: Wondering what's up with Keepass vs. KeepassX vs. KeepassXC? Keepass is the original app, written in .NET but with poor multi-platform support. KeepassX is a rewrite in Qt and is a fantastic password manager, but has gone unmaintained recently. The open source community picked up the slack in the KeepassXC fork (after continuing countless attempts to upstream the patches) and has implemented lots of powerful features. I've switched to it and at this point I strongly believe it's the better client.

<comment><USER41> > you get the added benefit of being able to store 2FA settings

Don't do this. If you use a password manager with all the benefits this entails (long, random passwords, each only used for a single site), the only benefit 2FA really gives you is if your password manager is compromised somehow. If your second factor is _in_ your password manager, you're screwed.

I use Authy with a long, secure password printed on a piece of paper. Yes, it is cloud and third party and everything, _but_ it's on a completely orthogonal chain from my Keepass DB, so dual compromises are significantly more difficult.

<comment><USER40> > _Don 't do this._

On the other hand, _do_ do this, but be aware of the tradeoffs.

I hate telling people not to do something. Most people just end up not turning 2FA on at all. My approach has converted many people from "one password reused everywhere, at best with variations" to KeepassXC unique passwords everywhere + 2FA and I classify that as a big win.

The biggest benefit of TOTP 2FA isn't the "second factor" part, it's the OTP part. This removes many forms of phishing, keylogging and database leaks as a threat to your account. You do not lose these benefits when you have it all in one factor.

If you read my comment, you'll see I address this concern. If this is a real threat for you, then you can always simply use a separate Keepass database for your OTP settings.

<comment><USER41> I grant that it protects against phishing, but I would cautiously suggest that sites that are smart enough to enable 2FA are smart enough to salt/hash/bcrypt/whatever best practice their passwords, so leaks are neutered. It doesn't not protect, so to speak, but the protection is likely to be redundant.

But it emphatically does not protect against keylogging, anyone who can install a keylogger on your computer can grab your password DB and your master password. This is exactly the scenario where you need actual 2FA.

Anyway, broader point: yes, it's a tradeoff, but the kind of people who needs explaining why a password manager is a good idea, do not understand enough to make an informed decision about these tradeoffs. And so, the responsible advice is to not use it.

I do know enough to understand these tradeoffs, and my conclusion is to keep password management and 2FA strictly seperate.

<comment><USER40> > _But it emphatically does not protect against keylogging_

1\. A keylogger on your password db is useless if it does not also upload the db (at which point you're looking at a targeted attack, and you have far bigger problems than that).

2\. Keyloggers are more and more often browser-based. KeepassXC is immune to those.

3\. KeepassXC supports 2FA for the database encryption itself. If you're that paranoid, use that. There's always more you can do.

> _And so, the responsible advice is to not use it._

No.

Just as you see in the article where Troy has to make the difficult decision _not_ to include a "Do not put your password anywhere not even here" disclaimer, the same holds in my message: I weigh the pros of someone turning 2FA on as far more important than the cons that come with the less-than-ideal security 2FA adds.

Your advice keeps people from turning 2FA on. 2FA is a pain in the ass for most people.

You are one of the lucky few who understands the tradeoffs involved, as you yourself said. So use that knowledge of yours to actually get people to secure their accounts.

My goal isn't to keep Edward Snowden's accounts secure. It's to keep the bored HN user's account secure. The average HN user has medium-to-high technical literacy and low-to-medium security literacy. A lot of people on here reuse passwords, I'm sure. This is what I'm trying to fix, and I won't advise Ed to keep his TOTP seeds in the same database.

</comment></comment></comment></comment></comment><comment><USER42> I just tried a 11 character password without special chars, that I've used on over 50 sites, over the last decade. It's my password for throaway websites. Some pretty dodgy.

Not in the database.

Makes me feel pretty good about password security overall!

<comment><USER43> I have a password that's a pair of words in two languages with some number substitution that I use a lot on websites I don't care about and it's not in the dB. And I'm _sure_ I've used it on sites that have been hacked, so I dunno.

<comment><USER33> Unless the site was also storing in plaintext they'd have to actually crack the password hash too, which for some passwords is very hard to do.

</comment></comment></comment><comment><USER44> There's something odd about a website that urges you to test your security by typing in your password.

<comment><USER45> He specifically tells you that you shouldn't do that. But as the winning tool shows, perhaps people who have passwords in HIBP will changed them after finding this out?

</comment></comment><comment><USER46> I'm going to have to disagree with the premise that sites should stop users from choosing a password which happens to have been cracked offline at some point in the past -- to the tune of blacklisting half a billion potential secrets.

What exactly is the end goal, and at what cost? Well, there are 3 ways to steal a password. You can steal it from the user -- either by phishing or with malware -- in which case it matters not a bit how complex the password is. You could attempt to crack it _online_ , that is, by attempting to login as the user through the front door. In this case, a simple counter should limit the number of attempts before a second factor is required, such as clicking a link in an email, and a list of half a billion candidates isn't going to help here either. Finally, you can steal the password verifier database and attempt to crack the password offline.

So, the theory must be that passwords in a known attacker's dictionary are more likely to be used as candidates in an offline attack. This is likely true. But once the verifier database is stolen, if an attacker is able to run the password hashing function, then every password which is not raw entropy already must be assumed to be cracked. _Regardless of how hostile your password policy is._ So what exactly is this policy saving you?

On the flip side, it's reasonable to ask, what would such a policy _cost_ you? It's hard to say without actual data, but I'd love to see some data on what percentage of candidate passwords offered by a user trying to signup on their mobile device would be rejected under this policy? How many attempts on average would it take a user to find a password which was not rejected? And what's the increase in bounce rate, and therefore lost signups, that would result? How many increased password resets would be required from users choosing passwords that they inevitably don't remember? How many additional lock-outs which require customer support capital to resolve?

Password policies on average are pretty horrendous. But password policies which are arbitrary black boxes to the end user are about the worst you can find. Sitting on my mobile device, not knowing if a chosen password will be accepted, having to type it twice each time, is a wretched user experience which would need extremely lofty benefits to outweigh the cost. I fail to see any benefits to this approach which couldn't be solved with better hashing which wouldn't impact the user experience whatsoever.

I'll say one more thing on the idea of blacklists. Users just trivially work around them. Password quality (entropy, guessability) does not generally increase. Bad password policies often decrease password quality, particularly in the case of password expiry. But a frustrating opaque blacklist could be just as bad. (I'm not aware of any studies on this).

An attacker who knows a particular blacklist was in place will use munging rules to find derivatives from the master list which are not on the blacklist. How much will their crack rate (percentage of clears recovered from an offline attack of a given magnitude) be affected? But more importantly, potentially driving down the crack rate through user hostile password policies is a game which has huge dividends at first (getting a password which can't be attacked online) and very little dividends after that point.

Disclaimer: Founder of BlindHash, which is the "better hashing" I refer to above.

<comment><USER47> > I'm going to have to disagree with the premise that sites should stop users > from choosing a password which happens to have been cracked offline at some > point in the past

Well, NIST, NCSC and Microsoft all seem to be on the same page:

[https://www.ncsc.gov.uk/guidance/password-guidance- simplifyi...](https://www.ncsc.gov.uk/guidance/password-guidance-simplifying- your-approach)

[https://pages.nist.gov/800-63-3/sp800-63b.html#5111-memorize...](https://pages.nist.gov/800-63-3/sp800-63b.html#5111-memorized- secret-authenticators)

[https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf)

> What exactly is the end goal

The end goal is to prevent password spraying attacks. If the attacker can get in on the first try because the user has re-used credentials in between two services, account lockout policies don't help and neither does BlindHash (if the compromised service wasn't using it). For it to bring any significant security benefit you would need __everyone __to use it (which will obviously never happen).

<comment><USER46> NIST has unfortunately been the source of a lot of bad advice which has actively harmed password security the last decade. (e.g. [1])

Cargo culting is generally a good thing in crypto because, you know, don't roll your own. But in this case we're talking about policy. And this policy is as user hostile (if not worse) than the prior NIST advice on password expiry.

If you want to stop password spraying, protect your hashes. There's no proof that blacklisting half a billion specific secrets will make cracking any more difficult. Making it neigh impossible for users to register with your service, well I guess if you have no users you have no passwords to lose.

But the point is a blacklist this extensive is just as likely to make passwords easier to crack, not harder, and will come with a direct cost to the company implementing it. I understand well the goal, I'm entirely unconvinced this helps achieve it.

I would be interested to hear Gosney's (cracker extraordinaire) and Cormac's (Microsoft Research) take on this.

[1] - [https://www.engadget.com/amp/2017/08/08/nist-new-password- gu...](https://www.engadget.com/amp/2017/08/08/nist-new-password-guidelines/)

<comment><USER47> > If you want to stop password spraying, protect your hashes.

Again, it's not about your hashes, it's about the attacker having access to your users' credentials.

Users re-use credentials accross services and you have no control on how (in)securely they are stored there.

Blacklisting (I don't have an opinion on how big the blacklist should be) what is known to be widely used accross services sounds sensible... and there is definitely an argument to be made about blacklisting what is known to be widely available/effective for attackers.

</comment></comment></comment></comment><comment><USER48> Hmm this is a pretty great list to use for any service that has user signups -- disallow signup when using a password that is known to have been "pwned"! :)

</comment><comment><USER49> Here is a quick PowerShell script - it supports the pipeline so you can automate, e.g. if you use a command line password manager.

[https://gist.github.com/lzybkr/85b4dbd6536ea5351e8d8e492a432...](https://gist.github.com/lzybkr/85b4dbd6536ea5351e8d8e492a432030)

<comment><USER50> Thank you

</comment></comment><comment><USER51> I love that simple API! Here's a bash one-liner that checks if 'hello' is compromised:

curl -s [https://api.pwnedpasswords.com/range/$(echo](https://api.pwnedpasswords.com/range/$\(echo) -n hello | shasum | cut -b 1-5) | grep $(echo -n hello | shasum | cut -b 6-40 | tr /a-f/ /A-F/)

Edit: Improved one-liner that only requires typing the password once and avoids storing it in the bash history:

(echo -n "Password: "; read pw; curl -s [https://api.pwnedpasswords.com/range/$(echo](https://api.pwnedpasswords.com/range/$\(echo) -n $pw | shasum | cut -b 1-5) | grep $(echo -n $pw | shasum | cut -b 6-40 | tr /a-f/ /A-F/))

<comment><USER52> You can use `read -s` to avoid risking having someone behind you read your password on your screen as you type it.

(echo -n "Password: "; read -s pw; curl -s [https://api.pwnedpasswords.com/range/$(echo](https://api.pwnedpasswords.com/range/$\(echo) -n $pw | shasum | cut -b 1-5) | grep $(echo -n $pw | shasum | cut -b 6-40 | tr a-f A-F))

</comment></comment><comment><USER53> A quick Ruby script to check if a password has been compromised using the Pwned Passwords V2 API: [https://gist.github.com/schmich/aeaffac922271a11b70e9a79a5fe...](https://gist.github.com/schmich/aeaffac922271a11b70e9a79a5fee19c)

</comment><comment><USER54> Guess my password is safe, it seems it was skipped in the list:

hunter1 - 3 times

* * * * * * * - 28 times

hunter3 - 2 times

/s

</comment><comment><USER55> This is really great and I will use this API.

Wrote a simple method in PHP using 10 lines: [https://gist.github.com/JimWestergren/a4baf4716bfad6da989417...](https://gist.github.com/JimWestergren/a4baf4716bfad6da989417a10e1ccc5f)

Feel free to use.

</comment><comment><USER56> A quick python script to hit the API, for those that don't want to use the webform (rightly so):

[https://gist.github.com/ShakataGaNai/cb786a2c64abc83d4dbe0db...](https://gist.github.com/ShakataGaNai/cb786a2c64abc83d4dbe0dbf6b60a5e3)

<comment><USER11> Or, for those that don't want to use Python (in case it isn't installed, or requires a non-core module, I dunno) but have access to a Linux box:

        # echo -n "password" | sha1sum
        5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8  -

Take the first 5 characters, in this case "5baa6" and use at the end of the API endpoint in your browser. E.g.

        https://api.pwnedpasswords.com/range/5baa6

Then take the all the rest of the hash after the first 5 characters, in this case "1e4c9b93f3f0682250b6cf8331b7ee68fd8" and ctrl-f search the results page for it.

<comment><USER57> For ease:

      # echo -n "password" | sha1sum | cut -b 1-5
        5baa6

<comment><USER11> Yeah, but you would need two commands then, because you need to search for bytes 6-40 in the resulting output. I made a one-liner farther down the comments.[1]

1: [https://news.ycombinator.com/item?id=16434244](https://news.ycombinator.com/item?id=16434244)

</comment></comment></comment></comment><comment><USER58>
      f--cktrump - 1
      f--ckbush  - 945
      f--ckclinton - <USER2>
      f--ckobama - <USER3>

I guess you can draw some conclusions there... maybe \- pwned accounts were created between 2000-2016 \- Democrats do worse at secure passwords? \- In 2000-2008 people chosed worse passwords?

</comment><comment><USER38> If you spend the time building a system to search those half billion passwords when you're users are signing up, you should focus on building a login rate limiting system so it's not possible to _brute force_ someone's password.

<comment><USER59> Though I agree rate limiting should be done (and done carefully), it is not very effective in all cases. As just 1 example, a determined attacker who wants to pop _any_ account can make 3 attempts on hundreds of thousands of accounts, using a unique IPv4 address per account, thanks to Windows & IoT botnets.

<comment><USER38> WAF, IP blacklists, naive bot detection[0] and why would a decent thresholding system allow for a single IP to fail multiple accounts in a short time period.

If you hit two valid accounts [1] with bad passwords in a few ACCEPTABLE_UNIT_OF_TIME, it's captcha time.

Thresholding isn't just action per IP it's being smart about how people are going to attack your system. It requires thought and upkeep.

[0] Previous thoughts on bot detection: [https://news.ycombinator.com/item?id=16182405](https://news.ycombinator.com/item?id=16182405)

[1] Also, if your login identifier and your public "display names" (usernames) are the same thing, that is a disservice to your users' security.

</comment></comment></comment><comment><USER60> This is a tangent; but I had a 'pwned' password that I've used for years on steam that started getting hacked like 4-5x a week; I would just ignore the 2 factor attempts for several months.

I finally changed the password to a slight variation that is not in this list (nor likely any others, 9 random alphanumerics); and within a week the two factor notifications started back up!

I was really surprised; admittedly the modification was trivial, but that is pretty thorough for a steam account I've spent like $100 in.

<comment><USER61> Did you have any items in the account (TF2, DOTA2 etc.)? Some of them sell for silly prices (and it isn't always immediately obvious which), which can result in your account being targeted.

</comment></comment><comment><USER62> > However, I got a lot of feedback from V1 along the lines of "simply blocking > 320M passwords is a usability nightmare". Blocking half a billion, even more > so.

What, why?

<comment><USER63> Because normal humans will only be able to generate so many passwords on their own before they give up.

He also later makes the example of understanding the frequency matters — abc123 is mathematically equivalently bad to mno678, except one is far more likely than the other.

</comment></comment><comment><USER64> Now it is to late, but Base64 could save about a third of the bandwidth, maybe for V3.

EDIT: Not if compression is enabled as mentioned in the article, so forget about that.

</comment><comment><USER65> This dataset would be a fun project to implement on IPFS -- content-addressed, distributed database of leaked passwords using the same hash range protocol.

</comment><comment><USER66> This is so useful I've knocked up a quick gem to wrap the range service (i.e. it only transmits the first 5 chars of the SHA1 hash)

[https://github.com/dansingerman/pwned_passwords_v2](https://github.com/dansingerman/pwned_passwords_v2)

The code is left deliberately simple so eyeballing lets you know it's not doing anything hinky with the passwords.

</comment><comment><USER67> In case anyone here is interested, I just did a livestream where I wrote a simple app in Nim to query this API.

On YouTube: [https://www.youtube.com/watch?v=Di2O_lIPxb4](https://www.youtube.com/watch?v=Di2O_lIPxb4)

Source code: [https://github.com/dom96/pwned](https://github.com/dom96/pwned)

</comment><comment><USER68> I know you can't search firstname.lastname@example.com addresses on have I been pwned, but it would be pretty useful if we could.

</comment><comment><USER69> It would be great if the many password managers out there like keepass for example, use this data to filter out any password that exists in the list. I know it would be very rare, but still, why not filter them out?

<comment><USER5> What would be the point of filtering out passwords that are in the list, when using keepassX or other password managers? Isn't the point of password manager that you don't have to choose or come up with passwords yourself?

</comment></comment><comment><USER58>
      troyhunt - 9 times

Most secure name for a password possible. :D

</comment><comment> default-kramer I thought it was funny that toepoke thought "People won't know what 'pwned' means." So instead they inform the user that they have a "Pawned password."

</comment><comment><USER70> I feel like this could come in handy while looking for a date at [https://wordsofheart.com/](https://wordsofheart.com/)

</comment><comment><USER71> How trustworthy is /haveibeenpwned.com? Is there a chance the password people enter there for checking will end up in the databases?

<comment><USER72> There is almost zero chance Troy Hunt would torpedo his carreer doing something as monumentally stupid as that.

It's possible, sure. But I'd trust him with my password sooner than I'd trust [INSERT SV COMPANY HERE].

</comment></comment><comment><USER73> Wouldn't reversing each password (reading right to left) produce a new list of "Half a Billion" passwords to use?

</comment><comment><USER74> Might be fun to create a PAM module that warns you when you login if your password is in the list.

</comment><comment><USER75> What would be nice is if we could improve the process of generating per device client side certificates that can be associated with a user account. Then we could just use certificate based authentication (and add on password based authentication if we want a second authentication factor).

</comment><comment><USER76> Oh the shame! An important password of mine is pwned. Just had to change it.

</comment><comment><USER77> "Write your password in this input field to see if it has been pwned"

Me: ¬_¬

</comment><comment><USER78> Is there a large file dump of plaintext passwords out there?

</comment><comment><USER79> we have more love than hate. Good to see that in secret passowrds.

       iloveyou - 1,462,146
       iloveu - 179,992
       ihateyou - 58,656

</comment><comment><USER80> swordfish: 74,878 times

I guess the password _is_ always "swordfish".

</comment><comment><USER81> username 8340

</comment><comment><USER82> Bit off topic, but I was searching for a better way to manage passwords a few weeks ago (rather than have 1 or 2 master passwords across all websites).

I found KeePass through an old ask HN thread. It's a great little free, open source key/password storage app that works across all my devices (iOS, macOS, windows). [https://keepass.info/](https://keepass.info/)

I'd be interested to hear any suggestions for similar apps I could recommend to my parents, who expressed concerns about their online passwords. KeePass would be the ideal solution, but I don't think it would hold their hand through download, setup, and password generation enough to be 100% ideal. Any suggestions?

<comment><USER83> Long time lastpass user recently switched to BitWarden. I find it's UI to be cleaner/easier to use

<comment><USER84> My biggest frustration with lastpass is that it doesn't seem to know the difference between subdomains, so it suggests several passwords for the same domain even though I am on different subdomains.

<comment><USER85> There was an option somewhere with which you could disable that one url at a time. I never bothered with it though and recently switched to keepass, so can't verify anymore.

</comment></comment></comment></comment><comment><USER86> On the topic of passwords, have a look at my command-line passphrase generation program.

GitHub: [https://github.com/ctsrc/pgen](https://github.com/ctsrc/pgen)

It's written in Rust. Install the Rust toolchain installer from [https://rustup.rs/](https://rustup.rs/)

        curl https://sh.rustup.rs -sSf | sh

And remember to add ~/.cargo/bin to your PATH.

Then install my command-line utility

        cargo install pgen

Usage is described in detail in the README on GitHub. Additionally you can ask the program itself for a brief help summary.

        pgen --help

Eventually pgen will be available in some package manager repos so that you can use your preferred package manager to install pgen but until then it must be built from source following the steps above.

<comment><USER87> A personal question. Do people really install megabytes of dependencies to run what would be a one line shell script, were it written in shell?

<comment><USER88> A bigger issue is blindly executing "curl ... | sh -" for something you are going to use to generate passwords (though it's bad in general).

<comment><USER86> That is the official way that you install the Rust toolchain. [https://www.rust-lang.org/en-US/install.html](https://www.rust-lang.org/en- US/install.html)

Rust is still undergoing changes frequently enough that most package manager repos have a very old version of the Rust toolchain in terms of what it is capable of doing.

For example the version of rustc that you get from Ubuntu default repositories was too old to compile my pgen when I checked some weeks ago.

And exactly because the tool is for generating passwords I don't want to distribute pre-compiled binaries of my tool myself, and therefore until I get pgen itself into package manager repos I tell people to download the Rust toolchain and to build my tool from source themselves as I did above.</comment></comment></comment></comment>