Notebook: Opening notebook on Chrome (Mac) asks for unknown password
Running notebook-4.2.3 installed via pip from master on Python 3.5.2 (Anaconda) on macOS 10.12.
I typically use Safari as my default browser, so notebook sessions open automatically with Safari. However, if I try to open a notebook using Chrome, I am confronted with a password input. Having never (knowingly) set a password, I have no idea how to log in and access my notebook session. This is a notebook being run locally on a MacBook Air.
Safari never requests a password input.
fonnesbeck
All 14 comments
This is a security measure which we implemented recently. The terminal where you started it should provide a URL containing a token which you can copy and paste into chrome.
We should add a way to get this token inside the interface, in case you're not interacting with it through a terminal.
takluyver
on 2 Dec 2016
Where can one read up on this new security measure? It isn't mentioned in the securing the notebook server. Release notes only say "Enable token authentication by default" without further information.
I observe an obvious downside of the token auth: the open tabs stop working across server restarts, and one cannot bookmark frequently used notebooks. I realize these problems will resolve automatically in jupyterlab, but I wonder what to do in the meantime.
akhmerov
on 11 Dec 2016
Searching through the rest of the docs, I only see an extremely brief mention over here without an explanation of security implications beyond
Setting to an empty string disables authentication altogether, which is NOT RECOMMENDED.
akhmerov
on 11 Dec 2016
After upgrading to version 4.3.0 there is a bug in the code or the docs. The docs tell us that the default value for the token is an empty string and this seems not the case with version 4.3.0.
viaregio
on 12 Dec 2016
Well, thank you very much guys for breaking the Dataproc deployment.
vmarkovtsev
on 12 Dec 2016
Sorry about this disruption. Allow me to explain a bit why we've made this change.
Issue #1830 pointed out that an attacker running a malicious DNS server can get round the same-origin requirements which browsers normally impose. It seems likely that this would apply to Jupyter running in its default configuration on localhost. If so, the practical upshot of this would be that a malicious website could use your browser to communicate with Jupyter and run code on your system.
This reminded us of a less severe problem that we've been aware of for a while: on a system with multiple users logged in, any user can access any other user's notebook server which is not protected by a password.
Neither of these should be a problem if you're running in Jupyterhub, or if you have configured the notebook with a password. But many people (myself included) use the notebook in its default configuration: listening on localhost with no password, trusting that either we're the only one logged in to the machine, or we can trust anyone else who may log in.
So the token mechanism is intended to restrict access to the server while inconveniencing the standard user as little as possible. When you start the server, it generates two tokens: one reusable, one one-time. The reusable one is shown in the terminal (or log) to use when connecting another browser. The one-time token is used to open the notebook in the primary browser - opening a URL involves passing it as a command line argument, which on some platforms is visible to other users, so we don't pass the reusable token. When the browser provides either token in the URL, the server gives it a cookie to authenticate future requests.
Attackers using the DNS trick, and other users sharing the system with you, should not know either an auth cookie nor a usable auth token, so the server will deny their requests.
We know a change like this is going to cause some pain, but we think it's necessary to fix a rather nasty security problem. We'll do our best to help you figure out how to make it work with your use cases.
@viaregio The token is randomly generated each time you start the server, so there isn't really a fixed default. Unfortunately the autogenerated config docs don't know about that.
takluyver
on 12 Dec 2016
@takluyver Seems as if this would be helpful to clarify in the docs. Perhaps either in the security section or configuration overview - not autogenerated text. Going to label as a doc issue.
willingc
on 12 Dec 2016
Agreed, thanks Carol. We were being cagey about the reasoning until we'd made a release because we didn't want to draw attention to how it might be exploited.
takluyver
on 12 Dec 2016
Thank you for tackling this.
rgbkrk
on 13 Dec 2016
1972 improved the docs. I'm going to close this one now, but we can continue to use the comments to discuss it.
takluyver
on 13 Dec 2016
Thanks @takluyver 馃崹
willingc
on 13 Dec 2016
Thanks mostly to Min on the docs work. I'll pass the ice cream on to him: :ice_cream:
takluyver
on 13 Dec 2016
Total garbage. Poory done. Good way to push data science to AWS
Streich676
on 29 Apr 2017
@Streich676 Did you have a question about the issue or constructive feedback? Thanks.
willingc
on 29 Apr 2017
Related issues
mikepqr
路
3Comments
pylang
路
3Comments
mmngreco
路
3Comments
harshinielath
路
3Comments
SmnHgr
路
3Comments
Most helpful comment
Sorry about this disruption. Allow me to explain a bit why we've made this change.
Issue #1830 pointed out that an attacker running a malicious DNS server can get round the same-origin requirements which browsers normally impose. It seems likely that this would apply to Jupyter running in its default configuration on localhost. If so, the practical upshot of this would be that a malicious website could use your browser to communicate with Jupyter and run code on your system.
This reminded us of a less severe problem that we've been aware of for a while: on a system with multiple users logged in, any user can access any other user's notebook server which is not protected by a password.
Neither of these should be a problem if you're running in Jupyterhub, or if you have configured the notebook with a password. But many people (myself included) use the notebook in its default configuration: listening on localhost with no password, trusting that either we're the only one logged in to the machine, or we can trust anyone else who may log in.
So the token mechanism is intended to restrict access to the server while inconveniencing the standard user as little as possible. When you start the server, it generates two tokens: one reusable, one one-time. The reusable one is shown in the terminal (or log) to use when connecting another browser. The one-time token is used to open the notebook in the primary browser - opening a URL involves passing it as a command line argument, which on some platforms is visible to other users, so we don't pass the reusable token. When the browser provides either token in the URL, the server gives it a cookie to authenticate future requests.
Attackers using the DNS trick, and other users sharing the system with you, should not know either an auth cookie nor a usable auth token, so the server will deny their requests.
We know a change like this is going to cause some pain, but we think it's necessary to fix a rather nasty security problem. We'll do our best to help you figure out how to make it work with your use cases.
@viaregio The token is randomly generated each time you start the server, so there isn't really a fixed default. Unfortunately the autogenerated config docs don't know about that.