Signing in to your mobile apps should be easier in my opinion than having to type a username and password. In my case it tends to be especially painful since I usually use KeePass to generate my passwords as random strings. Typing these long and random passwords on a touch device sucks. I'd like to see more alternatives when it comes to authenticating that are easier to use.
These are some ideas I'd like to see used more often.
The Sign-In Link
Slack uses a great method to authenticate mobile users. They get you to type your team name and your email address. After which you can use a "magic sign-in link" that signs you in automagically. The way it works is that they send you a link to your email, when pressed it signs you into your slack account. So no password required, instead proving that you have access to your email account is enough to log you in.
(I took the above image from https://auth0.com/blog/2015/12/04/how-to-implement-slack-like-login-on-ios-with-auth0/)
I really like this idea. I would love it if the HBO app had such a system, because it seems to have a knack for forgetting that I was logged in whenever I want to watch Game of Thrones. Especially for apps where users don't really interact with billing and paying for stuff, I can see that such a scheme would be nice to use.
Access to your email already meant access to most of your accounts. Only select few sites enable some sort of two factor authentication that don't just allow a potential hacker to reset your password via a "forgot password" function.
It also means one less password to remember. One less password that is potential reused, and then later hacked.
It does mean reliance on email infrastructure though. Which is already not so secure, depending on who your provider is. Spoofing and phishing is probably still going to be a problem for email a long time into the future. These could probably also be used against this type of scheme.
A protocol of such an authentication scheme might look as follows:
- Mobile App Requests Sign In from server, providing email address.
- Server sends an email with random token embedded in link, unique to email address.
- User presses link in the email. Link opens server webpage which in the backend sends a token to the mobile app.
- Mobile app receives fresh authentication token and uses it for future authentication.
- Server keeps track of active tokens in case they need to be revoked.
Of course, this is very similar to other authentication schemes where you rely on a third party to verify your identity. Other popular choices are to use Facebook, Google or other website logins that you have already authenticated for the device. However Facebook and Google both have privacy concerns (as large companies selling your data for adverts) as to why you may not want to allow them to determine your authentication. They will likely track the application you used.
But other transports could be interesting too. For example, you could authenticate over SMS if it's a phone device. This would require a phone number instead of an email address. It would also incur a cost on your business to, since you have to send out the SMS.
Key-Exchange over Local Network
In general I'd like to see more apps that communicate locally. That is my computer to my phone, or vice versa. An app I'd like to code when I get the time is a basic notifier to forward alerts from my PC to my phone, for example. However, I'd like it if the applications did not always rely on a backend server on the Internet. When I'm in my home and I share a local network, it seems very unnecessary and sometimes unsecure to have to route my messages between my devices via a server on the internet.
Instead I would like to see a protocol which implements a Key-Exchange over the local network instead. This way you can set up a secret key for devices to communicate via, so long as you trust your local network.
I think one way for this would be to communicate via UDP. One client broadcasts on UDP for the other to search for it. Once they find each other, they perform a key-exchange like diffie-hellman, and finally ask the user to verify the connection by showing the fingerprint. This is probably very similar to how bluetooth is done, but over an IP network instead.
Once the secret keys have been set up, your devices can then safely communicate end-to-end encrypted over the Internet.
Verification via QR-code
Continuing on devices that communicate locally, another way of exchanging a set of keys could be to use QR codes. This could done by outright sharing a secret key by showing it as a QR code for the another device to scan via camera. Or in the case of authenticating to a third party service, it could contain a token or signature which the new device could use to forward proof that the user already has access.
Obvious advantage here is that the exchange can be done offline. It does however require a camera for at least one of the devices. For a key-exchange the key may also have to fit in a QR code.
For a token based system, where two devices connect to the same api. You could allow an authenticated device help a second device authenticate the following way using a QR code.
- Authenticated device generates token. Sends token to backend server to save. Shows token in QR code.
- Unauthenticated device scans token. Uses it to authenticate with backend server.
As part of my thesis, I'm looking at using Tor for an anonymous submission system. For this I set up a small hidden service to test, and I figured I'd write down how it's done. It's pretty easy.
Assuming you have some sort of TCP server you want to serve over Tor, proceed as
tor first. This is pretty much the only package you need. In Arch-Linux:
pacman -S tor
Then all you need to do is edit the
torrc-file which is usually found at
/etc/tor/torrc. Here all you need to do is add two lines, and the default config file describes it pretty well. In my case it looked as follows.
HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 80 127.0.0.1:5000
HiddenServiceDir is the location where tor will store the private key
for the hidden service, as well as the hostname. Note that you can have several hidden services running on different addresses, just more
HiddenServiceDir lines with different directories.
HiddenServicePort will act as
a port forward from the first specified port at the onion-address to the specified
IP-address and port. In my case this forwarded traffic from my onion address at the normal http address to a local python webservice I was developing on.
Once you've added the lines to your configuration, you can then restart the tor service to start forwarding traffic.
systemctl restart tor.service
Finally you can get the hostname of your hidden service by opening the
Now use this onion address to connect to in e.g. your Tor-browser.
I'm on the boat from Gotland again after having spent a week there with my
family. Again I find myself in need of some preferably free Wifi. Although
with a new linux OS, I find myself having to find the new command
opposed to the
ifconfig command last time.
So this is one way of getting "free" Wifi on the Marlink Internet at Sea service found on the Destination Gotland ferry and I guess other ferries.
The attack is very simple, again all we need to do is spoof the mac address of an authenticated device. We can find an authenticated device quite easily using a wireless sniffer. I use Wireshark for this. Look for any packets going to an external network. I suggest filtering for TLS or HTTP, all we need is the MAC-address.
Once you have what looks like authenticated device, bring the device down, spoof
for the mac you want. These are the
ip commands used. Where
<device> is the name
of your wireless interface. In my case
ip link set <device> down ip link set <device> [MAC ADDRESS TO SPOOF] ip link set <device> up
Take this post as a good reminder to RTFM every now and then. It's a bit of
a challenge to do stuff without the almighty Google, but the
man command and some patient
reading does a good job when you are stuck offline :)
Disclaimer: Some thoughts on reason, ethics, and teaching. There is probably more refined philosophy on this somewhere, but I figured I would write down my thoughts. This post might be subject to change in the future. I might also move these types of posts to a separate feed/blog to separate it from computer science stuff.
Consider the following ethical problems. Forget about possible sidetracks and just answer yes if you think it is morally right and no if you think it is morally wrong.
First problem: You have a button, when you press the button it gives you a minor happiness, but at the same time it causes a lot of unhappiness for someone else. Is it morally right to press the button?
I think most people would answer no in this first question, You could rephrase it as question whether it is right or wrong to steal from someone. Now consider the same question, but without the bad part.
Second problem: You have a button, when you press the button it gives you a minor happiness. Is it morally right to press the button?
Obviously it does not matter morally speaking, right? If we assume full knowledge of consequences then there is no wrongdoing. From a utilitarian standpoint it would be a good thing to press that button; our utility would go up. However, what if the consequences aren't actually that well known, and this is your perception whenever you push that hypothetical button? Out of curiosity, you pressed the button one day to see what would happen. It gave you that minor boost of happiness and had no other effects to your knowledge.
Third problem: You have a button, when you press the button it gives you a minor happiness. After a few turns of having pressed the button, you learn that every time you press the button someone is killed. Is it now morally right to press the button?
No, right? You might be forgiven for having pressed the button before, but now you don't have the same excuse for doing so. Killing someone for a minor gain is hard to justify morally.
I would argue that the knowledge of the consequences very much depends on the ability to reason and our perception. Do we hold someone liable when they don't know what they're doing is wrong? In many cases, no. However, we could say that negligence is wrong, and that the person should have known that there were bad consequences to his actions. The knowledge of the bad consequences will likely make you reason that continued pressing of the button is bad.
Fourth problem: Your friend has found this same button and has started pressing it to get happiness. However, she does not know of the bad consequences. Should you inform her of them?
I think yes. If we go by the reasoning from the previous problem, then we help our friend understand that what she is doing is wrong and so she will likely stop pressing the button.
So finally, where am I trying to get with this? I find the flux between knowing and unknowing interesting. It opens up for further questions. What is your responsiblity for knowledge within your field? Obviously, for someone like a doctor knowledge might impact lives more directly and therefore a doctor has a higher responsibility than say a mailman. Another question, which was supposed to tie into the title of this blogpost, is when are we responsible for informing others? Clearly there is some limit to this, depending on your own self confidence and what not. If we went about informing everyone about every single little wrongdoing they might be doing then we would quickly lose friends. Unsolicited advise is gets old quick.
However, going by this logic where knowing the consequences seems to give a higher moral responsibility, there are some nice conclusions. Learning and teaching become good things.
Show people the consequences of their actions and perhaps they are more likely to do the right thing. In this sense teaching/learning feels like it is an instrumental way to goodness.
Found a neat little hack using "World Wide Web URLs"
A reference to a particular part of a document may, including the fragment identifier, look like http://www.myu.edu/org/admin/people#andy in which case the string "#andy" is not sent to the server, but is retained by the client and used when the whole object had been retrieved.
This gave me an idea of using the "fragment identifier", aka what's behind the #, to send secrets which can be seen by other browsers, but not the server. Secrets like for example passphrases which can be used for cryptographic purposes.
I made a small proof of concept project using this idea for a service to share secret message. Using clientside crypto, the user can submit an encrypted message to the server. The server returns with a uuid to identify the message. The client side script then creates a url containing the uuid and encryption key. Like so:
The user sends this url to his friend. When the friend opens the url, the server sends back the encrypted message. The client side script grabs the encryption key and decrypts the message. The plaintext message is never seen by the server.
Obviously, this idea implies trusting the clientside script that is sent by the server. If the server was adversarial he could easily modify the script to remove the encryption or send the encryption key to the server.