Stopping Screenlock Smudge Attacks On Android - <AUTHOR> http://www.whispersys.com/screenlock.html <comment><USER2> I like the new trend of replacing the unlock button with a fingerprint reader-

[http://cdn.cbsi.com.au/story_media/339308370/moto-atrix- fing...](http://cdn.cbsi.com.au/story_media/339308370/moto-atrix- fingerprint.jpg)

Not only is is faster and more secure, but it also creates many interesting opportunities:

-User accounts with different permissions (your kids could play games but not access the dialer or edit files).

-different actions for different fingers (ring finger sends a call to voicemail).

-True wallet replacement (square could have a field day).

-A trustworthy form of temporary bricking would nearly eliminate simple theft (10 wrong swipes and you have to visit a vendor with some id to have it unlocked)

<comment><USER3> A fingerprint reader is probably more secure, but actually wouldn't solve the "smudge" problem. You've most likely left latent prints all over your phone. These can be used pretty easily to create a fake finger that would probably fool the sensor.

Additionally, the history of swipe sensors in laptops is a mixed bag as far as this sort of solution goes. They are in almost all laptops, but almost no one actually uses them. Most people perceive them as too much of a hassle compared to the standard username/password setup. Maybe if phones start holding data that people value more (like digital money) they'd be willing put up with the additional work of using the sensor.

The ultimate solution would probably be something that grabs the biometric data without the user having to do anything special. This would make it easier to use and more secure. Apple actually already has a patent on this: [http://www.engadget.com/2009/03/27/recent-apple-patent- filin...](http://www.engadget.com/2009/03/27/recent-apple-patent-filing- speaks-of-stealth-biometric-security/)

<comment><USER4> > These can be used pretty easily to create a fake finger that would probably > fool the sensor.

At this point aren't all bets off? If a person is willing to do that, I would think they'd also be willing to disassemble the phone and extract the information that way. You would need a sort of whole-disk encryption too.

<comment><USER5> Main problem with any kind of biometric authentication is that it cannot be used as basis for generating encryption keys (eg. for whole disk encryption). Because in that case it's totally irrelevant if you can fool the sensor, you just have to process somehow "stolen" biometric data in same way as the sensor (+ encryption software) does.

For other authentication applications, all security lies in fact that it's not possible (for reasonable values of "possible") to fool the sensor or bypass it. But most commonly used fingerprint scanners are incredibly easy to fool (even including so called "high-security" sensors that happily accept photocopy of fingerprint as valid finger). Bypassing the sensor is often even easier, but on the other hand I've seen systems (for example BIOS level fingerprint authentication on ThinkPads) that are explicitly designed as to make that very expensive (in the ThinkPad case you would have to actually decapsulate the sensor chip from it's package).

</comment></comment></comment></comment><comment><USER6> Did you consider the idea of a combination (circular) lock?

I suppose it may be possible to decipher the stopping points, but if there's a final circle to confirm the code/cover them up, I could see that working.

edit: added "(circular)" to clarify

<comment><USER7> You could fix this by randomizing the orientation of the lock.

<comment><USER8> That would be a usability nightmare if I am picturing what you are saying correctly.

<comment><USER9> It wouldn't be that bad to have it start on a different number every time. It means that you would have to actually pay attention to the unlock process though, muscle memory wouldn't work.

</comment></comment></comment></comment><comment><USER10> On the vertical PIN one: Wouldn't it be better to use something similar to the default PIN input and randomize the position of the numbers?

It shouldn't be too hard to catch someone PIN when they enter it on a static vertical list. Then again, neither is it on the default static PIN grid.

<comment><AUTHOR> We considered this, but decided that people want to use muscle memory in order to quickly unlock their screens, rather than hunting for the correct digits in a randomized layout. This allows you to quickly go through the motions, and only adds one extra gesture.

<comment><USER7> But security is the whole point isn't it? Seems to me that having them hunt for the correct digits is the right thing to do.

<comment><USER11> Not being annoyed every time you unlock the phone is often a higher priority. Especially when you have to opt in.

</comment></comment></comment></comment><comment><USER12> This is a great example of combining information into promotional material. Well done. Good luck with Whispercore.

</comment><comment><USER13> just make sure you turn off usb debugging after installing, otherwise all of this is useless.

</comment><comment><USER14> Interestingly if your 4 digit key for iPhone has a digit used twice then it is harder to guess the correct order given the smudge marks:

        4 distinct digits = 4! = 24 permutations
        3 distinct digits (one repeated) = 4!/2*3 = 36 permutations

Note: division by 2 is because of the symmetry of swapping the order of the repeated digit, multiplication by 3 is because it is not known which of the 3 digits is repeated.

Note2: Using 2 distinct digits (both used twice or one used 3 times) is not as ideal as that results in: 4c1*2 + 4c2 = 14 permutations

</comment><comment><USER15> I wonder how secure the screen lock pattern option really is. I notice that the OS requires that the user draw at least four dots in their pattern. In theory, then, you have sum((9!/5!)+(9!/4!)+...)=9!(sum(1/n!)) options, where the integer n ranges from 0 to 5 (representing the 6 dot count options), or 985,824 total options. That's almost 20 bits strong, similar to a 6-digit base-10 pin.

BUT: That's if you use it like Swype for a 9-digit keypad, choosing a truly random 4- to 9-digit pin with no repeating digits. I'm not sure that's really possible: can you move between opposite corner dots without hitting the center dot? I speculate that in practice this input mechanism encourages a much smaller pool of options. For instance, in my anecdotal experience most users will only move to adjacent dots and won't cross their lines (presumably due to their cultural heritage of Tron and Ghostbusters). That turns this into a graph problem, and you would probably have to write a simulator to get the real numbers.

... Here's that simulation, in C++: <http://pastebin.com/xKd7UMr3>

Note that the adjacency constraint implies the no-crossing-lines constraint. Total possible paths given the constraints: 10096. That is a nontrivial reduction in bit strength, from 20 bits to less than 14, or from 7 to 5 base-10 digits. As a complimentary check, if you eliminate the adjacency constraint in the simulator you will see the expected 985,824 number.

Experimentation on my Droid X running the 2.2 OS indicates that you not only must wait 30 seconds after every 5 invalid patterns, but are locked out completely after 20 (at which point you have to login with your Google account to regain access). The OS remembers the number of invalid attempts across reboots, even if you abruptly cycle the power by pulling the battery out of your poor little Droid X.

Suppose an Android phone firmware was not quite properly implemented, and the invalid attempt count was only flushed to nonvolatile memory every, say, five attempts. I might then build a brute force pattern cracking machine, something servo-driven with a stylus to contact the screen (à la Clarke's "Rama II"). If my cracking device takes 3 seconds to try a pattern, and assuming a 40-second boot time, I would need 52 seconds to make 4 guesses, or 13s/guess. For the ideal case of 985,824 equally likely options, I would have to run that machine continuously for over 21 weeks to try every pattern. Given the adjacency constraint, however, I would need less than 37 hours -- a day and a half! -- to try all 10096 possible patterns, and would expect an average search time of about 18 hours.

Would the average user change their passwords if they accidentally left their smartphone in the office for the weekend (60 hours)? But this doesn't even need to be a single block of time. Does your significant other have access to your smartphone during weeknights (8hrs * 5 days = 40 hrs)?

Though if you have the kind of significant other who discovers your phone has a minor firmware flaw, builds a servo-driven cracking device to exploit it, and proceeds to steal your phone every night while you sleep, your life was going to be difficult anyway.

[EDIT: "No crossing lines" is a vague description. What I mean is that I don't see many users go back across a previously-visited dot to reach an unvisited dot. Since a dot on the other side of a previously-visited dot would have to be at least two dots away, the line-crossing constraint is covered by the adjacency constraint. As far as I can tell, the line-crossing constraint is actually somewhat enforced by the Android OS: you are not allowed to cross over _unvisited_ dots without the OS forcibly "visiting" the intermediate dot on your behalf, although you are allowed to cross over _visited_ dots.]

<comment><USER16> I don't understand the point of your post. You do a great job of calculating the strength of the Android pattern lock screen and then explain why that's totally irrelevant because of the 20 invalid entries hardlock. You could have just put that first, and saved yourself the tldr, but then you mention a few improbable hypotheticals for no discernable reason. Am I missing something?

<comment><USER15> The timeout behavior I describe is only for the Droid X model. For instance, I'm told that variants of the Galaxy S series (e.g. T959) have a 30s delay every 5 tries, but no limit on total tries. That would be a little easier than my 13s/try scenario above: (30+5*3)/5=9s/try, or 13 hours average crack time.

Regardless of whether your device has a limit on total attempts, you ought to be aware that the security of your lockout resides not in the complexity of your pattern, but rather in a subtle facet of your phone's volatile->nonvolatile memory transfer timing.

</comment></comment></comment><comment><USER17> I use a password screen lock that repeats some keys (sometimes with caps lock). It leaves smudges around the keys, but you would have to guess what order they are in, how many times they were pressed, and whether it was an upper/lower case key or a symbol... Seems pretty good to me.

I would still like to have my data encrypted though...

</comment><comment><USER18> Maybe its just me, but why not wipe your screen with a flannel cloth or even your t-shirt every so often. That would take care of most of the more egregiously straight-forward attacks won't it. This of course assumes that you have fairly secure number based key to begin with.

</comment><comment><USER19> Is the "draw a shape" screen unlocking optional and do people find it preferable to a number pad?? It seems kind of like a silly gimmick to me.

<comment><USER20> It's actually a really nice feature. It's quick, potentially (barring grease smear issues) more secure since you can use all nine points on the screen, and always optional.

This is one thing I've found that my Apple using friends are always a bit jealous of because it is slightly easier than punching in a pin number.

<comment><USER19> Ah, I didn't realize you could use all nine points, my thinking was that it limited your options since there were fewer points and you couldn't repeat... but clearly that was wrong :)</comment></comment></comment>


Postico – A Modern PostgreSQL Client for OS X - <AUTHOR> https://eggerapps.at/postico/?hn=1 <comment><AUTHOR> Previous discussion from about 5 months ago: [https://news.ycombinator.com/item?id=9838040](https://news.ycombinator.com/item?id=9838040)

It has reached version 1.0 since the last discussion.</comment>


In South Korea, Rivals Samsung and LG Fight Dirty Over Washing Machines - <AUTHOR> http://www.wsj.com/articles/in-south-korea-rivals-samsung-and-lg-fight-dirty-over-washing-machines-1420593182?mod=WSJ_article_EditorsPicks_2 <comment><USER2> Those washing machines look beastly.

Can't wait for one that moves the clothes from the washer to the dryer for you.

<comment><USER3> Automatic machines which do both in one place have been around for decades atleast.

Or were you being sarcastic? I can't tell

<comment><USER4> They wash OK but the drying in washer/dryers sucks.

<comment><USER5> This is because they condense the water out of the basin, whereas a traditional dryer is generating hot air from electricity or natural gas, which I don't believe can be done in a combined unit.

Innovation remains to be seen!

</comment></comment></comment></comment><comment><USER6> They hired Chris Bangle[1] to design washing machines?! They should get him to do mobile phones - he sure won't do another iPhone-like copycat.

[1] [http://en.wikipedia.org/wiki/Chris_Bangle](http://en.wikipedia.org/wiki/Chris_Bangle)

<comment><USER7> He's a car designer, I'm not sure that would translate very well to small electronics that should be closely integrated with software. For example, this is a Porsche Blackberry: [http://i.imgur.com/JdCKdMi.jpg](http://i.imgur.com/JdCKdMi.jpg) and they have actually had more experience with consumer electronics. It looks nice, better than a standard Blackberry, but it seems that it would be actually worse for real world usage.

There's really very little to be taken away from or be added to the black rectangle of the modern day phone. If you add something, it's just as likely to get in the way of using the phone, or being a superfluous gimmick.

</comment></comment><comment><USER8> $2,700 for a washing machine? Are they insane?

<comment><USER9> The article doesn't say what the tax is on the machines.

Domestic machines tend to be cheaper than commercial machines. It's pretty easy to find commercial machines i. That price range.

<comment><USER10> I think the Crystal Blue is a domestic machine. Don't forget that household appliances are a bit of a fetish item for new homeowners, along with granite countertops, recessed lighting, hardwood floors.

</comment></comment></comment><comment><USER11> Those two have been fighting forever. It's one way to keep them motivated, however their inherent structure keeps them from innovating further, hence will never be able to amount to the levels of Apple or Google, and they'll soon be surpassed by Chinese companies and will walk the ways of Sony, although they were never as good as Sony was.

<comment><USER12> > they'll soon be surpassed by Chinese companies

So you are saying that Chinese companies are more innovative than the South Korean conglomerates?

<comment><USER13> If they aren't now, they will be soon.

Look at where LG, Hyundai, and Kia were just 15 years ago. LG had to change names from GoldStar to shed the perception of the brand as the king of cheap Sony knock-offs. Hyundai and Kia were releasing unbelievably generic cars with their attempts at "styling" ending up like this: [http://en.wikipedia.org/wiki/Kia_Opirus#mediaviewer/File:Kia...](http://en.wikipedia.org/wiki/Kia_Opirus#mediaviewer/File:Kia_Amanti_2005.jpg)

Samsung wasn't much better, they had little presence in the consumer market and weren't regarded any higher than Foxconn is today in terms of electronics/engineering prowess.

I don't see the best Chinese companies being that far off from the best Korea had to offer back then. Look how quickly the Korean companies caught up and then remember how fast everything moves in China.</comment></comment></comment>


One Less Password - <AUTHOR> http://notebook.ideapublic.org/2014/one-less-password/ <comment><USER3> Not a bad idea but the chief drawbacks I see:

1\. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client!

2\. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.

Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.

I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.

[1] [https://chrisdecairos.ca/one-time-passwords- pt-2/](https://chrisdecairos.ca/one-time-passwords-pt-2/)

<comment><USER4> I feel like we're missing the elephant in the room.

The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.

This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.

But the real authentication happens when you enter your password to access your email.

Therefore, when I read:

> _I think a better way to solve this is at the browser /OS level with built- > in password generation and management._

All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?

We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.

Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).

Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).

From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.

So, is it really a better way to solve this? Not currently.

<comment><USER5> A few thoughts about the current de facto authentication 'standard':

1\. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part.

2\. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better.

3\. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less.

4\. But, sometimes I want to authenticate anonymously.

5\. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information.

6\. And, if I lose or break my phone, I don't want to lose my identity - <USER2> want an easy way to encrypt and store my identity at multiple backup locations.

</comment></comment></comment><comment><USER6> I like the idea. The downside is of course having to switch between the site and your email.

One could bridge that gap by adding two headers to the authentication emails - one containing the URL where the sign in request originated, and one with the sign in URL that must be visited.

A browser extension could then check your emails, and if an incoming mail matches the sign-in page of the current tab, log you in directly.

<comment><USER7> Bingo! Automating email-based authentication would indeed be pretty cool. In fact, extend this concept a little further, and you will realize that email itself is the ultimate platform to build programmatic exchange of information between persons and services. I wrote an essay about all the possibilities this would open: [http://blog.zorinaq.com/?e=76](http://blog.zorinaq.com/?e=76)

<comment><USER8> It's not the _ultimate_ platform. Arguably, it's not even a very good platform. What it is, however, is the best platform we currently have.

The idea of using email for password exchanges is fraught with difficulty, and not only because there's a lot of terrible email providers that don't even support starttls on their mail servers. Net-savvy people have fought a war to have HTTPS implemented across the web, can you imagine how hard it's going to be to get people to fight for implementation of security they can't even see? Ask your nearest non-technically minded friend if he knows if his email is encrypted in transit, and then ask him if his bank website is.

Someone elsewhere in the thread mentioned they'd only just started using key- based SSH login, and how it seemed to them the best thing since sliced bread. Extend that a little further with keyphrase protected keys and ssh- agent/pageant/whatever macs use, and you have a much, much better platform than "emailing a temporary password." The problem I see with implementing something like that is getting it off the ground.

<comment><USER9> Whether we like it or not email or its successor is bound to be the natural authentication platform. Something is happening here, I'd pay attention.

</comment></comment></comment></comment><comment><USER10> I implemented this style of login in the app I'm currently building. I don't think its necessarily appropriate everywhere; the reason I decided to use it is that its the type of service you very rarely log into. For things like that, a large portion of logins are (anecdotally) going to end up going through the forgot password flow anyway.

I will admit that not being responsible for storing passwords was one of the reasons I used it. I'm by no means a security expert; one less thing I can screw up seems like a major plus.

<comment><USER11> I've done the same thing in a few prototype-style apps I've built too. Not only do you not need to store passwords, but you can just ignore a whole area of UX.

Enter email to signup -> link gets emailed. Enter email to login -> link gets emailed.

I use JWT for this and it really makes it easy to get started on the part of the project that matters... and sometimes (not always) I think it's probably going to be fine to leave it this way.

</comment></comment><comment><USER12> A modern password manager (e.g. 1Password) seems like a way more natural solution that this. Not to mention that many services do not use smtpd+ssl/tls.

<comment><USER13> I disagree with this. I see services like 1Password as a bandaid for the tech savvy population. They are solving the password problem well, but only if you seek out the tool and understand the need for the tool. Approaches like the author's here solves the password problem for the majority of the population - the non-tech savvy population.

To your second point. Yes, this is true. But this is improving [1]. I'd add that forgot password functionality carries the same risk, and I'd add that the more likely chance of your password being 'discovered' is by brute force or a website hack storing passwords in plain text - rather than intercepting email.

[1] [https://sendgrid.com/blog/sendgrid-and-the-future-of- email-s...](https://sendgrid.com/blog/sendgrid-and-the-future-of-email- security/) (I work at SendGrid)

<comment><USER14> > They are solving the password problem well, but only if you seek out the > tool and understand the need for the tool

How about Apple's Keychain? iOS and Mac users get suggested auto-generated passwords that are then automatically saved and synced across devices with no extra installs or options.

</comment></comment></comment><comment><USER15> I really like this, I was thinking the other day when I used a site that I rarely use, and went through the whole 'forgot resend reenter' password thing that just that could be the 'standard' way of dealing with low impact sites and wouldn't force a password to be generated. It does imply the mail path is workable but that seems pretty common these days.

</comment><comment><USER16> It's clever but I wouldn't use it. First the user experience of going from one channel (web) to another (email) isn't very natural but the second and biggest reason is that it turns an email account into a central authority to access my other accounts from.

Some say email is already like that but it isn't with services using two factor authentication.

I don't think there is an easy and intuitive way to get rid of passwords without involving some sort of physical component that stays on yourself.

<comment><USER17> What is your workflow that this would be any more difficult? The first time you sign up for a service you almost always have to do this anyway for confirmation. If you then select the "Remember me" path, your primary computer is whitelisted and you don't have to do the round-trip.

Due to "Forgot my password" workflows email is already a central authority. If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two- factor method provides diminishing returns in security.

The funny thing about this proposal is that it is _exactly_ the way my non- technical family members use _every_ service. They don't bother with passwords they just use reset links every time. They don't have to remember anything and it's a common workflow.

<comment><USER16> > What is your workflow that this would be any more difficult? The first time > you sign up for a service you almost always have to do this anyway for > confirmation. If you then select the "Remember me" path, your primary > computer is whitelisted and you don't have to do the round-trip.

This assumes one (or n) devices that belong to you. I typically have to log into multiple services using a large amount of computers for work. In my use case this would be tremendously annoying whereas two factor I can simply log in like normal and type in the code from my phone's app.

> If you have two factor auth set up for your email account then you're > already pretty well protected and having each and every service use a > different two-factor method provides diminishing returns in security.

I disagree; it prevents someone from getting into my email due to a vulnerability and then being able to get into every other service I'm connected to. Each service I use would, ideally, have two factor (though I obviously do not think two factor is perfect but it's better right now than most alternatives in my opinion).

<comment><USER17> Interesting, it's clear that in your use case it would be more of a hassle, but in response to the second point it seems you're ok with the hassle of two factor authentication for many services.

I guess whatever the scenario 2-factor + email round trip is more of a hassle than 2-factor + password.

Thanks for your response!

</comment></comment></comment></comment><comment><USER18> I remember this idea from a while back, and I still think it's not going to work. It's too cumbersome to have to access your email every time you want to log into something. I love the creativity of the solution, but I just don't think it's workable on a large scale.

<comment><USER19> Now that we all have push email in our smartphones, it's not nearly as cumbersome. I already need to pull out my phone every time I want to access a Google app, having 2FA enabled.

<comment><USER20> But clicking the link on your phone would only log you in on your phone, no?

So your phone can't aid you here. If you're using any type of setup that doesn't use instant-push emails on your desktop, logging in will be very cumbersome.

<comment><USER21> The email also contains a short, one-time-use password that you can use instead. Look at the email on your phone, enter the password on your laptop.

I've wanted to move Persona in this direction for a while. I'm really excited to see if Webmaker is successful with this auth model.

</comment></comment></comment></comment><comment><USER22> This is still nothing more than a password...it's essentially just a password that is emailed to you. I've never understood why we can't instead authenticate ourselves to our browser or device, and get people out of the habit of authenticating to individual websites. This would eliminate phishing and greatly enhance security. Touch ID is a big step in this direction, but still can't be used for websites.

When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.

<comment><USER23> It is possible to use public key authentication with most modern browsers (not sure exactly which browsers support this). However, it's true that browsers currently don't provide any method to authenticate the user with the browser itself. (Although you could argue whether or not this is necessary since the user has presumably already authenticated with the machine running the browser.)

The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.

<comment><USER24> I've been wondering whether the concept in the article could be expanded out using client auth certificates.

So instead of clicking the login button and getting an email __every time __you need to authenticate (or using really long sessions), you use the "email to login" method __once per new device __. The resulting page takes the user through creating and uploading a client auth certificate, and stores it (along with a user provided device name to allow revocation).

In-browser cert+key generation is not perfect by any means but it certainly is possible - it's how providers of S/MIME certificates [1] are able to give you a signed certificate without you manually creating a private key+csr and uploading it.

[1] e.g. [https://www.comodo.com/home/email-security/free-email- certif...](https://www.comodo.com/home/email-security/free-email- certificate.php)

<comment><USER25> TLS client authentication [1] is doing this already.

[1]: [http://www.browserauth.net/tls-client- authentication](http://www.browserauth.net/tls-client-authentication)

</comment></comment></comment></comment><comment><USER26> This essentially mimics my login flow to every site I only use occasionally (e.g. twitter) and therefore can never remember the password for:

1\. Go to login

2\. Forget password - click reset password

3\. Go to email, find reset password email

4\. Login.

I wouldn't really mind if this became more common. I don't trust password managers (and access the internet from so many different devices that the only common thing they share between them is that I can access my webmail client or email on my phone.)

<comment><USER27> LastPass was considered secure on HN in the past, has this changed? Or is there a reason you don't like it? Not attacking, just curious about my own security.

<comment><USER26> I'm sure many password managers, including LastPass, meet the security bar for the threat models of most people.

However,

* I don't trust any software that uploads data to a centralized service (encrypted or not)

* Especially when that software is not open source / free software.

<comment><USER28> 1Password doesn't do that.

</comment></comment></comment></comment><comment><USER29> The cynic in me observes that although this post is couched in the language of an improved UX, what it also does is absolves Mozilla from keeping any (hashed) passwords stored in their databases. Only tokens with a very short shelf-life.

(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.

<comment><USER30> The authentication providers are more than just email (the article mentions phone and SMS tbd).

I'm not sure what you're saying here:

> (Hashed) Password storage is moved to a third-party database (the email > provider)

There is no hashed password? It's just a challenge response using an alternative path.

<comment><USER29> My assumption is that a "login key" is essentially a large piece of data that would be prohibitively inconvenient to use outside of an email account, text, etc. Analogous to a large session cookie without an expiration date.

In contrast, a password is designed to be used from any login point.

In this regime, unless the optional password is used, there is no hashed password stored on Mozilla's servers. Only a copy of the hash of the "login key" is stored, so the attack surface is considerably shrunk if you are attacking Webmaker users.

<comment><USER29> More technical details here from the post:

[https://chrisdecairos.ca/one-time-passwords- pt-2/](https://chrisdecairos.ca/one-time-passwords-pt-2/)

I'm not totally clear about what the different between a "login key" (short- lived, pronounceable) and whatever is contained in these semi-permanent login email links (~1 year, presumably non-pronounceable).

</comment></comment></comment></comment><comment><USER31> I like this idea for mobile apps a lot.

In mobile the sign up flow can even be more streamlined using deep linking:

1\. User enters email address.

2\. Opens email client and click the link.

3\. Link contain app specific schema myapp://login?token=cold_fish etc.

4\. App opens and verifies the token with the server.

5\. User is logged in.

User has to enter only email address as opposed to email + password (and sometime password confirmation) Then only needs to click a link in email client to sign up.

</comment><comment><USER32> Isn't email transferred in plain text? This is not very secure in my mind. Granted, nowadays a lot of service lets you reset your password through email, but that is only a one time thing. Now the whole system is dependent on someone not introspecting the packets flowing in the Internet.

<comment><USER33> That's historically true but TLS is now really common on both servers and clients. In fact most major email clients I've seen show a warning if the server only supports plain text.

Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use encryption" dialog.

<comment><USER34> I don't know if it's fair to say email over TLS is really common yet. It's getting there, but Google's email encryption in transit transparency report shows that only 57% of inbound messages to Gmail were sent over TLS. Outbound 72%. [https://www.google.com/transparencyreport/saferemail/](https://www.google.com/transparencyreport/saferemail/) (this is largely concerning server-to-server communication, rather than client-server, but server-server communication happens whenever emails are sent across domains).

To be fair those inbound reports are potentially bloated by a lot of spam that no one reads or cares about. It would be interesting if Google disclosed what percentage of messages that end up being read are sent over TLS (or non-spam messages generally). But we can also see that several top 10 sending domains do not support TLS at all (adsender.us, constantcontact.com, grouponmail.*, sailthru.com - mostly advertisers). Luckily the top receiving domains support TLS (which look like other big-name ISPs).

Compared to website TLS, email TLS as commonly implemented has two significant challenges beyond these percentages. First, since TLS is established by the STARTTLS extension protocol within an existing plaintext SMTP connection, it's easy for an attacker who can modify communication to force it to remain in plaintext (simply don't advertise the TLS capability). Second, that previous attack is hardly even necessary: most email senders are willing to establish connections to receivers who present self-signed certificates. The same scenario when browsing a website will show a security warning and recommendation not to continue. The reasoning goes: it's better to use TLS even with a self-signed cert than fall back to plaintext. There's no human involved who can make a judgment call to abort, like there is when browsing a website. So, while email TLS with self-signed certs may be helpful against passive dragnet surveillance, it's little defense an attacker who can intercept and modify the communication: the attacker can simply present his own self-signed cert instead, and the email will flow.

Solution ideas: Devise a standard by which messages can be stamped "TLS only or don't send", and another standard by which domains can declare their intention to support TLS. Senders will remember that the domain is TLS-enabled and refuse to fall back to plaintext; and will require a certificate from a reputable CA under either protocol.

</comment></comment></comment><comment><USER13> I too would "like to see [this approach] used and pushed further by other designers and developers."

I'm one of those who have been trying to do so. I created an open source approach called Handshake.js that is re-usable for developers. [1]

I presented this topic to a good crowd at JS.LA [2].

At the current time, I'm finding developers still hesitant to jump into the approach. Passwords are familiar and there are many developer tools/libraries to quickly setup the defacto username/password approach to authentication.

[1] [https://sendgrid.com/blog/lets-deprecate-password-email- auth...](https://sendgrid.com/blog/lets-deprecate-password-email- authentication/) [2] [https://vimeo.com/90883185](https://vimeo.com/90883185)

</comment><comment><USER35> Ah ! I built this a few months back:

[https://github.com/rakoo/xauth](https://github.com/rakoo/xauth)

It uses the same idea as in the post, ie the "lost password flow for login", but with XMPP. The latter gives you much higher flexibility in that it actually is thought out as a programmable protocol. You try to login, the server sends a token to any of your connected clients via a bot message, you just repeat it to the bot and you're then granted access.

I feel there is high potential here, and there even is an official XEP ([http://www.xmpp.org/extensions/xep-0070.html](http://www.xmpp.org/extensions/xep-0070.html)) for this.

</comment><comment><USER36> Playing with NetBSD the other day, and bored, I created an SSH key for the first time and was amazed that I had not been using this for forever. I think keys could replace passwords, or at least, cookie based logins.

<comment><USER37> Client-authentication has actually been supported in SSL for a long time [1]. Unfortunately, there seems to be little interest in using that form of authentication in browsers. A big part of that is probably making a compelling user interface and teaching users how it works.

[1] [https://en.wikipedia.org/wiki/Transport_Layer_Security#Clien...](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client- authenticated_TLS_handshake)

<comment><USER25> [1] summarizes why TLC client auth isn't wide spread, but he also proposes some TLS extensions to improve client auth. Such as Origin-bound certificates [2] so that the user does not have to choose which certificate to use for authenticating.

[1]: [http://www.browserauth.net/tls-client- authentication](http://www.browserauth.net/tls-client-authentication) [2]: [http://www.browserauth.net/origin-bound- certificates](http://www.browserauth.net/origin-bound-certificates)

</comment></comment></comment><comment><USER38> What's funny is that we're basically doing a very similar thing at my startup, PricePlow ([https://www.priceplow.com](https://www.priceplow.com)), and it was actually inspired by discussion earlier here at Hacker News.

It works very well for our purposes. We don't need crazy security because we store no important personal information -- just product preferences. It's insanely easy on the users.

I guess I should get back to blogging about my entrepreneurial lessons learned, as this has been one of many of them....

</comment><comment><USER39> There is a fully fledged implementation for Node.js [https://passwordless.net](https://passwordless.net) (Disclaimer: I'm leading the development)

</comment><comment><USER40> So instead of directly logging in using the ID provider like FB/Google/Microsoft, which are also the email providers, you send an email to those accounts and ask user to take one extra step of checking and clicking the link. It seems to be inefficient. A much better solution should be for the devices to support accounts natively and integrate authentication directly into the platform.

<comment><USER41> The idea seems to be that you only have to do this once, then you remain authenticated for every service that integrates with this authentication service. You don't have to remember another password or place trust in a new service not to mishandle it.

This seems like a solution that completely replaces the need for every website to manage their own user signups, which is something you still need to do even if you integrate with Google/Facebook/etc. because not everyone has an account with those and signing up for one is less trivial than having a sign-in link sent to your email.

</comment></comment><comment><USER42> How is this any materially different than the "I always forget my password and I always use the forgot password link"? I guess you don't have to pick a new password each time? But you could just rapidly type in gibberish and achieve nearly the same effect, no real password, login via email.

<comment><USER43> Well, you would have to type the same gibberish twice though.

Besides, I don't think they are claiming to be innovative. I think they just point out there is a redundant step which we can remove from the process.

</comment></comment><comment><USER44> The biggest reason for me to pass on implementing an approach like this is what I THINK is the actual most common use case for a typical user when logging into a site at which they are a regular:

They're doing so for the nth time, and on the (or a) device they usually use, and thus their browser (or other password manager) has already got their password remembered and thus it is pre-filled in.

Having to click back and forth between email every time you log in seems way clunky relative to that, which for me is something above 90% of the instances I log in to some web application.

Couple that smoothness with picking a non-reused, strong password for a web application (which password managers make actually practical) and the friction in the user login experience seems to have little if any upside.

<comment><USER45> In the email, you can click "Sign in & remember me". I guess that sets a cookie in your browser, so next time you come back, you'll still be logged in (until the cookie expires).

</comment></comment><comment><USER46> Every time I've heard of this system, I've thought that it would make it clumsier to access an account.

I go to a site and my intention is to stay on that site throughout whatever I'm doing there. If you force me off your site for something like logging in (where it's the point of 'I trust your site, give me access') then I've lost focus and you've put your experience in someone else's hands.

If I was doing this, I'd have to open a new tab, go to GMail, wait for it to load, find the tab within GMail that has the email and then click the link. Every so often, I'd probably have to put my Google password in too. That's a lot of effort, considering that your site probably isn't that significant to me.

<comment><USER47> Most people keep their email open, and many have push notifications.

<comment><USER46> My experience is to the contrary, on personal devices, people don't seem to keep their email open.

If by push notifications, you mean mobile devices, then surely that would only log them in on that device rather than on their computer?

<comment><USER48> Short expiration one time use codes can allow you to authenticate on devices different than the one that receives the email.

</comment></comment></comment></comment><comment><USER49> I actually prefer Reddit's version - email is optional, while password isn't.

</comment><comment><USER50> I really like the way TranferWise (transferwise.com) automatically signs me in when I load the page. It's a way to transfer money online so has to be secure, but uses my email authentication to verify it's me. I don't even have to click a sign-in button! I'm surprised this hasn't caught on more...

[https://transferwise.com/support/customer/portal/articles/16...](https://transferwise.com/support/customer/portal/articles/1663507-when- i-log-in-the-site-only-asks-for-my-e-mail-and-not-for-any-password-)

<comment><USER51> The link describes something very common.

The only difference I can see is that they ask you the email to figure if you are coming from yahoo or Google while the most common pattern is to show two buttons.

I don't think asking your email is a good idea, email is a something they should ask to the identity provider instead.

</comment></comment><comment><USER52> I like this idea a lot, but given the centralization of authority to a user's email account, I do think it requires beefed up security for however the user accesses their email---i.e., would be great to allow this only for users who have 2FA enabled on their webmail, although I have no idea how you'd check or enforce that.

Actually, the "lost password" flow already assumes email as a single point of failure, so I suppose my 2FA comment is moot (in other words, we should be pushing for 2FA for accounts regardless of their password approach on other accounts).

<comment><USER43> > but given the centralization of authority to a user's email account

This is already the case right now. An attacker who has access to your primary email account can gain access to any of your accounts using Forgot Password.

> the "lost password" flow already assumes email as a single point of failure,

Exactly. I think that was the inspiration for the idea. If we have a single point of failure anyway, why not just use it directly to login?

<comment><USER29> Yes. This just offloads the security burden from the Webmaker service to your email provider. It means one less password, but a compromise is still catastrophic.

If the goal is to separate the need to remember complex passwords from the application, then a password manager makes much more sense (ideally with 2FA).

In the long game of improving token-based security, this is a step sideways at best.

<comment><USER48> With this method I'm not seeing how an e-mail compromise is any more catastrophic than a site that offers a "forgot my password" flow.

That is to say, yes, a compromised primary e-mail _is_ catastrophic, but seems like an already accepted risk. Why is this worse?

<comment><USER29> Assuming an email compromise is catastrophic, as pointed out earlier in this thread, one might as well use a password manager, which allows for maximal password strength, possibly 2FA, total control over the password database, etc.

I didn't mean to imply that this was worse, only that it doesn't really change the threat.

</comment></comment></comment></comment></comment><comment><USER53> The main flaw with this idea as well as pretty much every password reset flow is that email itself is insecure. If I want to attack the login system and I have the ability to intercept the emails at some point, I essentially get access to the link/code in plaintext and now have access to the account. The difference might be that there will be a much higher volume of emails from a system like this than from one that just uses email for resetting passwords, though that's not guaranteed. I'd like to see a system that address this issue.

</comment><comment><USER54> Startup Digest event submissions use similar method: no account, every login is an email sent to you. The problem I have is that I do use a password manager and like that much a lot more than switching back and forth of email and the site. If I go to your site, I don't want to go to my email...

It really feels like they want to solve my password storage problem for me, in a very opinionated manner without any alternative for me, and while it might be a good solution, it does not feel like one (for me).

<comment><USER55> It says you can turn off passwords if you'd like.

</comment></comment><comment><USER56> Does this handle concurrent logins from multiple devices reasonably? If every login essentially resets the "password", either all other existing sessions are terminated (bad usability) or kept (possibly insecure).

The linked more technical description suggests that the latter is done (sessions on trusted devices are valid for 1 year), so you apparently cannot stop someone with a stolen device from accessing your account (while the session is active / the cookie persists).

</comment><comment><AUTHOR> Here is the Mozilla Webmaker blog post with a more user-centric discussion of the password-less system: [https://blog.webmaker.org/one-less- password](https://blog.webmaker.org/one-less-password)

I was initially concerned that email is insecure, but then I remember sites already use email for password reset. :) My bank does something similar by also remembering my personal computers by browser fingerprinting and/or IP address.

</comment><comment><USER57> We shouldn't abuse email for this. Any one of LastPass, 1Password, KeyPass etc. or SSO with Google, Facebook or Twitter can do this way better. You will probably be using extremly long and random strings, i.e. you're storing secure tokens there. You can't call those passwords any longer -- and we should forget about the notion of manually creating and then remembering passwords to sign-in.

</comment><comment><USER58> If the service is not going to contain any privacy related stuff or need not be so secure why not just keep the cookie after typing in email address.

What i do is i keep all worthy sites'password on the password manager and the rest of the site follow a pattern based password or a common simple password. For e.g. i typically use some this "keepass"or domain of visited web + keepass

</comment><comment><USER43> This makes a lot of sense. On every device you would use to login to some kind of service, you already have access to your primary email. Clicking a link is easier than typing your password. It also seems to be safer. Your account is safe as long as your primary email is not compromised, in which case the attacker would gain access to your account by Forgot Password anyway.

</comment><comment><USER59> I've wondered for a while why this pattern isn't more common.

In the past I had thought it would be great if instead of email it could push to your phone so a message would pop up saying "confirm login? Yes/no". It would be a really simple option from a ux perspective but screw going anywhere near making the crypto tech to support it.

</comment><comment><USER60> [https://fidoalliance.org/](https://fidoalliance.org/) is a much better idea and worth investing in instead.

Passwords must die. We need to get to the point where there is a modular mechanism for authentication so that individual devs never are tempted to create a users table and add a note field for password storage.

<comment><USER61> From the video on this page[0], it took 12 steps to link a fingerprint with fido. That doesn't seem like a realistic solution.

[0] [https://fidoalliance.org/adoption/videos](https://fidoalliance.org/adoption/videos)

<comment><USER62> That's specific to that implementation.

1\. Navigate to Settings, Finger Scanner, Pay with Paypal

2\. Select Install FIDO Ready Support, then Install NNL fingerprint scanner

3\. Select Link to Paypal, then Link Fingerprint

4\. Login to paypal with username and password

5\. Agree to terms

6\. Swipe finger to link fingerprint

7\. Install paypal app.

1 is obviously mandatory. 2 could be preinstalled. 3 could be combined, but is mandatory. 5 is stupid. 7 should be already installed if you use paypal.

End result: find the right settings area, select link fingerprint to paypal, login to paypal, swipe fingerprint to link, done.

Don't criticize FIDO based on some half-baked implementation. Any problems you have with the setup flow are either Paypal's fault or Samsung's.

<comment><USER61> That halfbaked implementation is the featured video on their website. As someone new to fido, I was trying to learn about it and their website was very confusing and this featured video wasn't a great example of the technology. Those are not good signs of the technology.

<comment><USER62> They're trying to point out that it's usable today with paypal and the S5. They have no control over the steps Paypal and Samsung require to set it up. And although the 12 steps or however many there are are not ideal, it's not as if they left the setup for the user to figure out; all you have to do is follow the video. You're making a huge deal out of some extra steps on a one- time setup.

Don't blame the technology or the FIDO alliance when that video is about the S5 and Paypal, and the video is hosted on Paypal's youtube account.

The new yubikey neo (as of October) supports FIDO, but I don't know about client (browser/mobile) support middleware, and it requires nfc or full sized usb.

</comment></comment></comment></comment></comment><comment><USER63> Good option for B2C services that are not that important (pretty much most of them actually :-)).

Email delivery problems is a factor that needs to be considered though.

Stolen "remember me" cookies is another factor... The password stealing malware will start harvesting those cookies instead of passwords (it's already happening in some cases).

</comment><comment><USER64> Submit phone number, and it SMS's you your password.

If I steal someone's phone, I get access to any system using this.

If I buy a sim card off someone, or buy used sim cards, I could also gain access to some potentially high value targets if they use this.

If I 'borrow' my phone of someone, I can steal things from them if the sites using this have value.

etc etc.

</comment><comment><USER65> Less -> Fewer

<comment><USER66> No. [http://www.thatdanny.com/2008/11/20/one-fewer-or-one- less-a-...](http://www.thatdanny.com/2008/11/20/one-fewer-or-one-less-a- definitive-answer/)

<comment><USER67> This article claims that the Guardian style guide was unhelpful. Possibly he should have read it:

"fewer/less: fewer means smaller in number, eg fewer coins; less means smaller in quantity, eg less money"

Simply put fewer is for things which can be counted, less is for things which can not. So you have fewer cylinders of air, but less air. If you can say "one X" and have it make sense you should use fewer, otherwise use less.

That's the rule as it's meant to work, the more interesting question is "does the rule matter any more?", to which I'd answer probably not.

You don't see supermarkets with "5 items of fewer" lanes and most people don't really see any difference between the two terms. The reality is that language continues to evolve, as it has always done, and the distinction is really now just one for pedants (guilty as charged). If you need proof of this then the just look at the figures in quoted blog post (assuming they're even vaguely right), which suggest that most Guardian journalists are ignoring their own style guide and their sub-editors (a job title which pretty much comes with pedantry in the job spec) are letting them.

<comment><USER68> > You don't see supermarkets with "5 items of fewer"

That's why I shop in Waitrose [http://scaryduck.blogspot.co.uk/2011/05/death- to-ten-items-o...](http://scaryduck.blogspot.co.uk/2011/05/death-to-ten-items- or-less.html)

<comment><USER67> Ha, why doesn't it surprise me that Waitrose have that?

</comment></comment></comment></comment></comment><comment><USER69> I'd much rather just use a password.

</comment><comment><USER70> Interesting, I would like to see how non-tech users evaluate the user experience of this.

</comment><comment><USER71> What if I want to have this authentication process on my email account itself? :) The only other option (soon to be available) is SMS. Seems a bit too limiting and maybe not completely practical.

</comment><comment><USER72> I built an open-source Rails engine for something like this: [https://nopassword.alexsmolen.com](https://nopassword.alexsmolen.com).

</comment><comment><USER73> Sounds like a good idea, but how many sites/companies will adopt it? There are tons of similar ideas, but none of them are as popular as login/password...

</comment><comment><USER74> Flask-Security supports this experimentally. I love it. It's much less of a hassle than you might imagine, having to click a link in an email.

</comment><comment><AUTHOR> How does the user log in if they've changed their email address (e.g. switched ISPs and not using a gmail address)? Authenticate using SMS?

<comment><USER31> SMS is one option, but then you end up with the same problem - what they've changed a number...

The system will probably have to give a way for the user to change email address while the user still has access to the old email address.

This is something that wasn't mentioned in the article but should definitely be solved.

<comment><USER75> >The system will probably have to give a way for the user to change email address while the user still has access to the old email address

Any reasonable web-application today has (or should have) a possibility to change eMail address.

</comment></comment></comment><comment><USER76> I think this could be a very elegant solution.

</comment><comment><USER77> LaunchKey. No Passwords. [https://launchkey.com](https://launchkey.com)

<comment><USER78> From what I understand, this is basically the same idea as OP, technically speaking.

Except the UX is sexier.

</comment></comment><comment><USER79> "Passwords might be useful for someone who works on a public computer at the library."

Key loggers anyone?

</comment><comment><USER80> I don't think storing authentication tokens in people's email is good UX and raises expiration issues.

Here's another take on how to get rid of passwords: The Password Manifesto

[http://www.tech-spelunking.com/home/2014/9/5/the-password- ma...](http://www.tech-spelunking.com/home/2014/9/5/the-password-manifesto)

<comment><USER75> I think these two methods are more similar as it looks. It should be noted, that the tokens are only temporary tokens, that should be valid only several minutes. So the eMail system is not a storage, but a transmission medium. You also could use SMS or any other scheme that guarantees that only the valid receiver will get it.

Of course your proposal is superior, but the infrastructure is not available yet. For web-apps with low security demand, I think the discussed scheme would be sufficient (since we already have security implications because of password reset schemes -- and real secure schemes are seldom. In Germany there even where attacks to two-factor authentifications via mobile of banks ... the attackers just ordered a second sim-card in the name of the legal user and intercepted the snail-mail).

<comment><USER80> Ah, so the expiration issue is smaller than I thought. Thanks for that info. Still, it represents a training issue for users and a new framework to be incorporated into a web app. Those are both barriers to wider adoption.

I agree the security of this solution may be right for certain applications.

Yes, my proposal is an infrastructure play - but I believe it is a more realistically achievable one than most password alternatives.

<comment><USER75> Yes, I also think that it could be achieved. The problem as everywhere is the adoption. When two or three big companies would stand behind it, it could be easily implemented and I really would like to see a scheme like that.

There are of course some questions, that also would need to be solved. For example: What if an other person has access to my computer -- than I still would need some kind of master-password that had to be remember-able. Also there must be methods, to transfer my keys to an other computer or to "copy" for example onto mobile devices.

The example of the SIM-card for banking just shows, that the "big security" is really a hard problem. Two-factor is one idea, but it is always a game where the attackers are hunting the defenders (or vice versa).

<comment><USER80> Re: shared device use, yes, you would continue to do password management best practices (fingerprint scans, master passwords, etc.).

I see the transferability as an export/import format issue. W3C, browser vendors and password managers need to agree on a format for keychain export/import.

Note that this technique could still be used in conjunction with multi-factor auth. Since it is just an evolution of passwords, those type of mechanisms are still relevant and compatible (though, eliminating knowledge factors should reduce need for a second factor).

</comment></comment></comment></comment></comment><comment><USER81> Oculus have been doing something similar with their order tracking for quite a while now.

</comment><comment><USER82> This is (partially) only as secure as your email provider's authentication system.

</comment><comment><USER83> What to do with projects those have both web and mobile apps?

<comment><USER43> All your mobile devices probably already have access to your primary email account.

<comment><USER84> But the mobile app doesn't. Which means you are making the user go from app to email to browser and back to app. If you are lucky, the login link can open in app. If not, you need to transfer login from browser to app.

</comment></comment></comment><comment><USER85> (edited down for size)

Problem with this system: it requires input on a single device (the computer), removes an out-of-band authentication option (password), and pushes the requirement for authentication down the stack to a system without a secure connection (e-mail, SMS).

In this new system, the password becomes an optional secondary authenticator. Your primary authenticator is now moved to some pre-authenticated service, such as your e-mail (which you have already logged into, presumably with a password) or SMS messaging (which you have already logged into, presumably with a swipe or pin on your phone). On top of that, neither of these uses a secured connection, so MITM/interception are trivial, to say nothing of phishing+CSRF.

One of the major flaws with existing out-of-band authentication access is that we assume the user only has one form of input: the computer. If the computer gets hacked [via malware] the user cannot protect themselves. But the future is here, and we carry [networked] computers in our pockets! Turns out the most secure way we can authenticate is via two separate networks and two separate computers using two secured connections. Example:

      Step 1. User requests to login to HTTPS Site A.
      Step 2a. Site A prompts User for a password.
      Step 2b. Site A sends an SMS to User with an HTTPS link to click.
      Step 3a. User enters password on site.
      Step 3b. User clicks link on SMS in mobile device.
      Step 4a. Site authenticates password.
      Step 4b. Mobile site reads cookie on User's mobile browser.
      Step 5. User is authenticated; both mobile device and computer have access to site.

Here you have two different authentication factors on two independent devices which are combined to authenticate the user. The attackers now have to steal a cookie or auth token from two separate devices at once. This is of course completely plausible, but is a much more expensive attack than any currently implemented. Best of all, the user doesn't have to remember the password if they use their browser's password manager or a cookie is stored locally.

It would be trivial to add this dual-auth method to their existing system, so hopefully they implement that instead of throwing the baby out with the bath water.

For what it's worth, of course, here's an attack that could compromise that system. Attacker shows user a phishing password prompt page that uses a browser hack to steal a cookie. Attacker sends an SMS to the user (assuming they found the user's phone number) with a link to another site which also exploits the mobile browser to steal that cookie. Now the attacker has the two cookies and can log in, assuming the site does not use an Authentication Manager that detects attackers who steal credentials (only large-dollar sites use these).</comment>


Rick Astley: How We Made Never Gonna Give You Up - <AUTHOR> https://www.theguardian.com/music/2020/mar/23/rick-astley-how-we-made-never-gonna-give-you-up <comment><USER2> I remember being a kid and seeing this music video for the first time and thinking, wait, _that 's_ the guy who sings this song? Rick Astley must have one of the most incongruous voices in the industry.</comment>


Y combinator video - <AUTHOR>

Even though we have worked together, my co-founder and I currently live in different countries and can't send one video of us speaking together as we won't see each other before the application deadline. In that case, should we make two videos put together, or one video of one co-founder, or maybe a video conference call video? <comment><USER2> Conference call if the quality is good enough.

</comment><comment><USER3> Here's an example of a good conf call video by the StackVM guys: <http://pkrumins.posterous.com/private/obrvzuHsbn>

<comment><USER4> But please 1. get a noise cancelling microphone, 2. adjust the volume so both are about the same and 3. draw up a plan on who says what in order to not interrupt each other all the time.

</comment></comment><comment><USER5> From what I've understood, a conference call video may be the best option. However, I've not been through the process, so take my advice with an asterisk.

</comment><comment><AUTHOR> Thanks for that answer though! I sent an email, waiting for a response.

</comment><comment><AUTHOR> Perfect, we will do that. Under 2 minutes is alright then?</comment>


Ask HN: Is this a viable idea - white label MOBILE social network - <AUTHOR>

Given that white label social networks like kickapps have had great success, what you think of doing a white label mobile social network as a product idea? Every telco seems to want one of their own and I am sure a lot of niche mobile sns are going to mushroom. Quick research turned up only Wadja.<p>Background: I am a hands on tech guy with a small but kick ass dev team. Doing consulting work for other valley start ups + couple of small in house projects. Looking for one idea to focus all our efforts on. BTW if you have an alternative idea and willing to pull your weight get in touch. I am open to bring in my team + seed money for right idea. <comment><USER2> This is a very crowded space. The involved players market themselves towards carriers rather than the end user so it's unlikely simple searching will turn them up.

For example airG (<http://corp.airg.com/>) has deployed white label social networks on most North American carriers. They don't come up for "white label mobile social network" :)</comment>


San Francisco has had its first self-driving car accident - <AUTHOR> http://www.pcworld.com/article/3024939/car-tech/san-francisco-has-had-its-first-autonomous-car-accident.html <comment><USER2> Except the car was under manual control, and it is unclear what the cause of the accident was.

<comment><USER3> "... an account of the incident says it started when the automation computer steered the car incorrectly."

<comment><USER4> Of course, Vogt blames it on the human:

"There was enough time," he said. "He took over manual control but unfortunately made a mistake."</comment></comment></comment>


SteamVR Tracking - <AUTHOR> https://partner.steamgames.com/vrtracking/ <comment><USER2> It's awesome that Valve is doing this! They have said from the start that they were going to open up Lighthouse (the codename for the tracking system) to hardware manufacturers and this is the first part of that follow-through.

Should be exciting to see what kinds of devices come out of this. I know I saw a few devices (like gloves) at SIGGRAPH that attempted to reverse engineer tracking with the base stations, so this should speed up their development considerably. I wouldn't be too surprised if we see at least an announcement of wireless Lighthouse-tracked gloves for VR by the end of the year.

It's not just controllers or HMDs either. I expect to see a beer coozy with tracking so people can pick up drinks on a desk while remaining in VR, and maybe a collar for pets so you don't step on your dog/cat while the headset is on. The possibilities are endless!

<comment><USER3> > I know I saw a few devices (like gloves) at SIGGRAPH that attempted to > reverse engineer tracking with the base stations

I'm attempting to do the same thing at the moment: [https://github.com/jb55/libvive](https://github.com/jb55/libvive). I got basic stuff like buttons and gyros working. Right now I'm wrapping my head around some of the trigonometry that makes the lighthouse tracking work. Hopefully I'll have an open source reference implementation soon.

<comment><USER4> great! One _big_ annoyance with all the SDKs fighting it out right now is how much extra (and often closed source) junk they pull in that replicates things you likely already have, with quite invasive integration with your rendering pipeline to boot. Access to lower level _primitives_ rather than integrated solutions is definitely a nice thing.

</comment></comment></comment><comment><USER5> If there is one thing I CANNOT wait for is these new VR systems being applied to CAD/CAM software.

The ability to move tools and remove material in 3D from items and move them around as you feel fit will revolutionize the world of CAD software.

I'm saying this as someone who is attempting to get into doing some CAD modeling but having an EXTREMELY hard time getting into it. It really is software made for engineers by engineers.

<comment><USER6> Have a look at the VR support in the Unreal Engine editor[0]. You can actually manipulate the virtual world while inhabiting it! It's not much of a stretch to apply the same principles to CAD.

[0] [https://docs.unrealengine.com/latest/INT/Engine/Editor/VR/](https://docs.unrealengine.com/latest/INT/Engine/Editor/VR/)

<comment><USER5> I didn't know this exact example but this is precisely what I am dreaming of.

It's just completely intuitive.

</comment></comment></comment><comment><USER7> There is a pretty high barrier to entry here with a required $3,000 per-person training program. I'm not sure why that is necessary, unless it's really difficult to work with.

<comment><USER6> Not to mention, it's _in-person_ training, so anyone outside the US is effectively excluded.

<comment><USER8> I am sure you can come visit and take the training, though perhaps you mean it's more expensive for non-residents of the US to attend.

It's more expensive for people living in other countries, certainly, but perhaps you could work out a deal where you become a certified trainer yourself and go back to your country to offer discounted officially-sanctioned training to folks in your region.

Look for opportunities rather than problems.

</comment></comment></comment><comment><USER9> SteamVR Tracking HDK FAQ

[https://steamcommunity.com/app/507090/discussions/0/36067124...](https://steamcommunity.com/app/507090/discussions/0/360671247404603033/)

</comment><comment><USER10> Interesting that Valve isn't looking for royalties here. Any speculation as to what the strategy behind this release is?

<comment><USER11> As an Oculus user, based on Valve work for the VR community, I will very likely move to the Vive for GEN II.

<comment><USER12> And there it is - you are the strategy.

They're pushing for an open vr ecosystem, as they realise both that it's important to the medium as a whole as it encourages experimentation through greater access, and equally importantly, they realise that that matters to you.

At this point they're setting up a playing field where oculus will be pretty much compelled to put down their dreams of platform and exclusivity, and all will benefit, particularly the guys who run the ubiquitous game marketplace. Oculus can have a glorious future as a hardware manufacturer, which is where they started, too.

</comment></comment></comment><comment><USER13> Wow, this could be exciting, I'm really glad valve followed through on their word of opening this up, and it seems they've done so in a pretty good way. Providing an open standard for tracking is fantastic.

</comment><comment><USER14> SO I guess you can only track within a range of 5 meters? Any way to daisy chain the base stations to have higher coverage? This is an awesome tech, soooo many applications!

<comment><USER15> Well, the current TDM system has a limitation of 2 lighthouses. If you read into how it works, each lighthouse sends out an IR floodlight pulse follow by a horizontal and vertical laser scan. Each lighthouse has a single IR detector to be able to sync these scanning events (or you can use a cable). As far as I've read, the system is running a 60Hz (due to the laser scanner RPM) and as far as I can tell they can't really get the current TDM based system past 2 units without decreasing scanning frequency and theoretically decreasing tracking resolution.

What I find interesting is the idea of switching to a FDM system. I don't know enough about the current hardware to know if the IR detectors are capable of FDM (I think they've discussed this in interviews though), but if they are then you could have a system that supported many more lighthouses _and_ a higher scan rate (since you don't require TDM anymore).

</comment></comment><comment><USER16> What happened to Neal Stephenson's plan to make a sword-fighting game? Did it fizzle out? Maybe he could make use of this.

<comment><USER17> This one? [https://uwm.tv/about-us/](https://uwm.tv/about-us/) [https://www.youtube.com/watch?v=uN3_m6Bn21Y](https://www.youtube.com/watch?v=uN3_m6Bn21Y) [https://www.youtube.com/watch?v=gBhvUgxfUjk](https://www.youtube.com/watch?v=gBhvUgxfUjk)

<comment><USER18> Never heard of it. Is it related?

I believe this is the kickstarter video: [https://www.youtube.com/watch?v=vuWCEpcTbww](https://www.youtube.com/watch?v=vuWCEpcTbww)

</comment></comment></comment><comment><USER19> Seems the wrong way around for a lot of applications, I want the objects to be the dumb emitters and have a central base station that has a low-latency, synchronized (!) state of their positions.

Otherwise all the effort on low-latency seems wasted on a device that has no low-latency path to getting the information out.

<comment><USER2> I disagree. That's the model the Rift uses, but that means that as you add devices, the extra computation of position lies on the PC (or mobile device, or w/e).

With this Lighthouse system, the positional computation is distributed amongst each device and they report their computed position, so it scales way better as you add devices.

<comment><USER20> I think it is definitely for scaling. Also you can add any number of devices that are independent of each other. Like for instance using two Vives in the same room, but use the same base stations.</comment></comment></comment>


Video streaming & net neutrality - <AUTHOR> http://ber.gd/post/22374588073/video-streaming-net-neutrality

<comment><USER2> This better get investigated at least as thoroughly as the Street View WiFi thing. Unlike that situation, this is actually causing quantifiable harm to consumers right now (as Comcast would otherwise actually be forced to raise their data caps to provide this service, improving consumer choice by making alternatives more viable).

<comment><USER3> >"improving consumer choice by making alternatives more viable"

And that's exactly what they're afraid of.

</comment></comment><comment><USER4> To be clear, this is a discussion of "net neutrality" in that the author alleges that Comcast is prioritizing (and not charging for) traffic for its Xbox streaming media application, which works like a Video-on-Demand service. Comcast claims that this is similar to a standard Video-on-Demand service based in a cable box and can legally be prioritized because it is the functional equivalent of traditional VOD. Comcast doesn't see anything wrong with not charging for bandwidth used for set-top-box VOD, and analogizes that to Xbox VOD, even though the two may use different underlying technologies.

The author says that it shouldn't be treated like VOD because it is delivered over an IP network rather than old-school cable and Comcast has no right to prioritize video packets for its own IP video service over those for other IP video services (e.g., Netflix).

Which is more "neutral" is an interesting question: neutrality over the mechanism by which Comcast delivers its VOD service to cable subscribers, or neutrality between IP-based video streaming services?

<comment><USER5> Hi. I'm the author of the original post; thanks for your comment.

To be clear, VOD streams to your STB are delivered over IP, just not through your cable modem, router and home network. You're right, of course, that Comcast claims these streams are no different than that VOD service.

The point where I think Comcast's argument falls apart is that streams to their Xbox app are delivered through the exact same network elements both inside and outside your home, as e.g., Netflix streams.

<comment><USER6> This is a point that is frequently missed and ends up muddying the actual net neutrality discussion. For cable providers, Internet (big I internet, not just a network that uses the same protocols) is carried on certain channels with vod and normal cable channels carried on other channels. For providers like Uverse, it's not separate frequency channels, but separate vlans with dedicated bandwidth on each (very similar model, though, big I internet traffic is separate from other services). Where the neutrality line is crossed is when all traffic on the big I Internet segment isn't treated equally. In this case, the separation of billing is giving that traffic preferential treatment over other big I Internet video streaming.

</comment></comment></comment><comment><USER7> The DSCP values have nothing to do with the bandwidth cap. DSCP is just a "flag" on the packet and most internet routers don't look at that at all. I would also be very shocked if DSCP has anything at all to do with the way Comcast is calculating your bandwidth cap. They are most likely using something like IPDR or subscriber-aware DPI.

DSCP values also are completely separate from DOCSIS priority on the cable network. With DOCSIS the provider can create service flows with different priorities and bandwidth restrictions. Most providers only use two service flows (one upstream and one downstream) but if Comcast wanted to give some subset of traffic priority on the DOCSIS network (where they are most likely to see congestion) they would put that traffic into a separate service flow with a higher priority. That is how they do their "congestion management" to top users, top users in saturated nodes get their service flow priority temporary and dynamically reduced (via PCMM) so other users traffic gets first shot at open time slots.

In addition, with DOCSIS 3 it is very possible for the MSO to add a dedicated set of RF channels that only select traffic would use, which in this case it would be the Xfinity video streams. I have no idea if that is how Comcast has implemented this but if so how is that any different to Video-On-Demand on a standard STB? With standard VOD on a STB there is a set of RF frequencies set aside for VOD use. If they put Xfinity XBOX IP traffic on a separate RF channel it would be no different than adding an additional RF channel for VOD and would have zero impact on total available internet bandwidth to the cable node.

<comment><USER2> The real problem here is that "net neutrality" is a farce as long as providers are allowed to send their most lucrative services over non-neutral channels.

</comment></comment><comment><USER8> I'm sorry to sound very negative on the author, but I don't know how you could have the knowledge to write this article, but not have the knowledge to understand the basics of costs on the Internet.

A few points that are horribly wrong FTA (reasoning explained below):

"In order to use as few network resources as possible—both to keep costs low and quality high—these providers typically attempt to get as "close" as possible to end users, often forging agreements in which they directly connect to provider networks."

The "close"-ness that they are talking about here is not geographic closeness but network closeness. And this isn't just in terms of the distance traveled geographically, but the cost to send that traffic across some other network. That is, it is more expensive for Netflix to send traffic from their provider to (for example) AT&T to Sprint to Comcast to you, than it is to have Level3 send traffic from Level3 to Comcast to you. In fact, because of the peering agreement between Level3 and Comcast, Comcast has to pay Level3 to send them traffic (or so I believe).

The cost is not how many links it has to traverse, but the cost of the peering agreement that that network has with where it is sending the traffic.

"The only appreciable differences between the Xfinity streaming service for Xbox and e.g., Netflix, are that the source of content is within the Comcast's "internal" CDN instead of on a third-party CDN, and that Comcast requires you to be using their own Internet service. (This is much more likely related to their agreements with content owners rather than any technical reason.) "

This is wrong. The reason is entirely financial. It is cheaper for Comcast to send traffic only within their network. If I traveled to China, it would cost Comcast much more to send the traffic to China and almost nothing to send the traffic to my computer which is Comcast's network.

"As you'll see, the cap-exempt content is likely even more expensive for Comcast to deliver than the third party content!"

"All of these third-party streams almost certainly originate from third party providers in the Bay Area, all via direct connections to Comcast. Even though they count against my bandwidth cap, they almost certainly traverse fewer fiber route-miles and physical router ports (Comcast's two primary costs of delivery) than the stream which originated in Seattle(!) and does not count against my cap."

Completely wrong.. Even though it is a further distance away, sending traffic from Seattle to somewhere in California is almost no cost to Comcast, so long as it stays within their network. With retrieving content from Level3 (such as Netflix movies), it has to _pay_ Level3 to send them traffic that its users want.

Again, sorry to bash on the author so much, but the author was misinformed concerning cost. Also, DSCP is kind of meaningless when traveling between networks (any network router can overwrite them and change their priority).

<comment><USER9> It has been reported that Level 3, Akamai, and Limelight are _paying_ Comcast _and_ delivering content as close to the user as possible, so I agree with the original author that external content would seem to be cheaper than Comcast's internal CDN (maybe even a profit center).

[http://arstechnica.com/tech-policy/news/2011/02/peers-or- not...](http://arstechnica.com/tech-policy/news/2011/02/peers-or-not-comcast- and-level-3-slug-it-out-at-fccs-doorstep.ars)

<http://apps.fcc.gov/ecfs/document/view?id=7021030795>

<comment><USER8> Ah, very good point. The last thing I read on the Level3/Comcast spat story lead me to believe Comcast was paying Level3 for the peering. I apologize. However, this line lead me to believe the author had a misunderstanding of the costs of traffic:

"...they almost certainly traverse fewer fiber route-miles and physical router ports (Comcast's two primary costs of delivery)."

That is, unless the author meant Comcast's primary costs within their network, which is not what I read it as. Without providing reference to the cost of the peering, the comparing the _geographic_ distance of traffic seemed irrelevant. Even in this case, the reason that it is more expensive for Comcast to send traffic is not that is coming from Seattle, but because they are losing money on having Level3 pay them.

Edit: I also need to read more on this as I'm curious why Level3 is paying Comcast since Comcast is (as far as I know) not acting as a transit network. But I suppose this is what happens when you violate valley-free routing.

Edit2: Also, just wanted to add, the fact that Comcast controls the peering links is why this is so sketchy. By raising the costs of peering links, they could make it way more expensive for the competitors to send their users traffic, forcing the competitors to raise their prices, allowing Comcast to be the only content provider to have reasonable prices. While the part about the bandwidth to them not counting towards your cap is sketchy, the practice of charging you less, a lower flat rate, or not at all for traffic that stays within the network is reasonable. Where it is sketchy is when that difference is leveraged to make the service cheaper. If the service is more expensive, it's the fact they are charging competitors more that is sketchy. So... in general, providing content and the network is all around sketchy.

<comment><USER10> Just a quick comment on cost (since OP and these comments seem to have it a bit backwards):

The real cost in a DOCSIS network like Comcast's is actually in the last mile. DOCSIS is sort of like a mobile network in a pipe. The base station in this case is called a Cable Modem Termination System (CMTS) and data is transmitted from there over RF with QAM modulation to all the cable modems on the same coaxial segment. This can be hundreds or even thousands of cable modems. For unicast IP the packet is only received by one of them but they all have to listen.

When the radio spectrum inside the coaxial cable becomes congested the segment has to be split in two parts and a new CMTS installed, very similar to how you split a mobile network cell into sectors to improve capacity. Like with a mobile network this is capital intensive.

Not saying this makes Comcast right. But important to understand where they're coming from.

<comment><USER8> Residential networks are actually part of my current research, and, although I don't know the full details of every technology, I am familiar with the basics of how DSL and DOCSIS networks work.

Yes, there is a cost (in terms of performance and congestion) over these links, but this not really relevant in the discussion when talking about the cost of where the traffic is originating. Whether the traffic originates in Comcast's data center in Seattle, from a CDN in Level3's network, or over their peering links with Tata, the cost of it traversing the last-mile is irrelevant. In any of these cases, traffic will still be crossing this link. And yes, this is a significant cost in terms of deploying the last-mile network, but as I said, it has nothing to do with the cost of getting of getting the packets to the DOCSIS network.

What we're saying is that if Comcast is carrying traffic from Seattle to a user in their network, they do not have to pay a transit provider to carry this traffic. If it is from Level 3, Level 3 would actually be paying them to carry that traffic to Comcast subscriber. If the traffic were coming from Comcast's peering link with Tata, Comcast would have to pay Tata (their transit provider) for the traffic.

Yes, the cost of the last-mile network is real and important, however, in this discussion it doesn't really relate, since you would be traversing the DOCSIS network in all cases.

<comment><USER10> Well... Isn't there a fundamental assumption in the network neutrality debate that cost per bit is zero or very low? At least that's the feeling I get from reading this discussion. People seem to think that cost comes mostly from IP transit, and implicitly that last-mile infrastructure cost is constant and sunk.

Well, that assumption is wrong for mobile, and to some extent for DOCSIS. Last-mile cost scales with traffic volume (and completely overshadows the cost of IP transit). That's why I think you'll see MNOs and MSOs fighting the hardest against network neutrality.

</comment></comment></comment></comment></comment></comment><comment><USER11> Can you change the title to match the actual article? I belive that the Hacker News guidelines suggest to keep the submission title as close as possible to the new one. (esp. in cases like "exhaustively researched")

<comment><USER12> Check it again; you're wrong.

<comment><USER13> From the guidelines: _You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it._

I think that "exhaustively researched" counts as gratuitous editorial spin.

<comment><AUTHOR> I gave the submission a different title specifically to call out it was original detective work done over the course of several days by a technologist... a technologist who is "showing his work".

The vase majority of press I read about net neutrality is done from a theoretical or policy perspective, and tends to rely on research done by 3rd parties. My aim was to distinguish that this particular post as not being yet another post of that variety.

That being said, I am fine with the editors decision to change the title of my submission.

</comment></comment></comment></comment><comment><USER14> 1\. It's possible to rewrite DSCP values at each hop.

2\. It is likely these DSCP values are not used for prioritization over other services.

The most likely scenario in my mind: Comcast's trust boundaries could encompass a large enough portion of their CDN to simply not re-write of the DSCP values. Meaning this DSCP value may represent an internal network prioritization, but not impact the traffic delivery outside of their data centers. The traffic, because it originates within the trust boundary, retains its previously assigned DSCP value, but it does not indicate what policies are implemented in the actual delivery of the packet.

This post, while very interesting, simply cannot know with certainty that comcast is prioritizing traffic without conducting an extensive test. We're talking many gigabytes of traffic and many locations. However, this does warrant testing as the DSCP values could easily be used to implement prioritization.

</comment><comment><USER15> How do the traffic exemptions in AWS fit into this net neutrality debate ?

There are quite a few ways in which traffic between different AWS components is discounted[1], or "favored" over other traffic, and this doesn't bother me a bit - it seems quite reasonable.

I lean (slightly) to the net neutrality argument, but I have a hard time seeing how the billing practices of AWS are neutral within that framework.

How does the OP feel ?

[1] For instance, bandwidth between EC2 and S3 is free.

</comment><comment><USER16> I am shocked that everyone here seem to be ignorant of this very important fact:

The Comcast XBox VOD is only available if you're already a paying customer for Comcast Cable TV.

i.e You cannot just be a Comcast Internet subscriber without TV access and get access to the VOD streams for $x/month which are cap exempt. If this was the case, then it won't be net neutral. Thus Netflix can still compete on it's price versus Comcast TV's price. This new service is just an added delivery feature of Comcast TV.

</comment><comment><USER17> If others can replicate what the author did, then it might rise to the level of "exhaustively researched".

If you are a Comcast customer, try to replicate the experiment yourself. See if you get the same results.

"Set Top Box" == Black Box.

No doubt we'll soon see one for live video (Skype).</comment>


How to comment your code better - <AUTHOR> http://particletree.com/features/successful-strategies-for-commenting-code/ "Commenting your code is like cleaning your bathroom. You never want to do it, but it really does create a more pleasant experience for you and your guests... " <comment><USER2> Definitely try to write your code in self documenting form. A function name that makes it clear what the function does is better than a comment. Chances are comments start to rot very quickly as other programmers updating code are likely not to touch comments, or to copy and paste something and take a comment out context.</comment>