I’m very concerned about the security of user account credentials. I am sure this has been considered and there were discussions a while ago about how to lessen the impact of credentials being stolen, by having different security levels and access controls for different data within a user’s account (Feature Request: Persona Trees by @oillio)
But what is to stop an APP stealing credentials entered to use it?
Maybe this is catered for, but @viv’s authentication example (Google hangout video) suggests that it is up to APPs to obtain and supply credentials and perform the login, which would mean that the APP has access to the username, password and PIN.
If this is so, what stops an APP from stealing those credentials?
If not, how does authentication really work cos I must have misunderstood that code sample!
Nothing stops an app from stealing your creds. As you know it can be written to do only that (and display a funny logo after that, before it exits).
Nowadays auth is done client-side (in the browser/app) so the app doesn’t get your credentials, but if the app is malicious of course it won’t do what we expect. I think the answer is “don’t install untrustworthy apps”.
Well, MaidSafe could have a certification program similar to Apple’s or Google’s.
Or, in case of open source apps released by known and reputable authors, those would presumably be safe to use if downloaded and built from source.
Currently, that’s very true. Cos if we think about it, even if an app does not have access to your PIN, Keyword, Pass, it at the very least has access to info about you let it be pictures, music, your docs, whatever you use via the app. Now if the app at this point chooses to mis-use that data, we still have the same problem.
“or” a user could install a clock app(not even a SAFE network app) and it ends up wiping your SAFE network data via the VFS(hopefully with versions, you can recover some action like this, but yh in this case is still an issue).
This would be a nice way to handle this issue and has definetly been mentioned by @dirvine in the forum here too I think. Reviewers could be MaidSafe or any open-source community with a strong reputation. This does have it’s limitations that the source code for the apps submitted to review needs to be disclosed to the reviewers. Now some people might be ok with this while others might not want to do that.
MaidSafe could charge for auditing/checking (Seal of Approval, etc.).
Unaudited closed source apps would have to rely on the reputation of their authors.
Open source apps could be community audited and when the authors’ names are known, that would be an additional assurance based on their prior track record.
None of these approaches would be perfect (look at the poor track record of Android’s app store).
I intend to mitigate risks by having multiple accounts, not using random apps and not storing non-pre-encrypted private & confidential data on the SAFE network.
Yea, I think that if we get a great automated review system in place as we are doing then this will help. If devs use that system and have small commits viewed by the whole community (sorry proprietary code) then passes stringent automated Qa with security tests built in. Then code review and acceptance etc. we stand a chance of an open fair and honest system that NEVER bans apps on anything except technical merit. So no politics, no business protection etc. Same as the network, all actions welcomed.
Of course App Stores etc. should exist and may not want to show some apps because of some political religious, social or otherwise personal taste. This should be up to them and the best store wins. So we in the core teams are focussed on technical merit and security without caring of what the app is and stores etc. can host or not such apps.
I know I’m not contributing much by saying this and there’s prolly a reason why it doesn’t already exist or in talks but could there be a plugin (like maidsafe approved) that is secure and allows extensibility by delivering user data in an anonymous secure way? Not giving apps full access? Why can’t a user give an app info as if the app is just another node like the secure messaging? As you can tell I’m full of man and mainly questions
I want to bring one thing up, and that is: the world of executable encryption and PE modules. These thrive on the ability to test all possible anti-virus, and if its passing AV tests, a user of a malware knows more than reasonably that they will pass undetected.
I’ve yet to come up with an idea to test an app without exposing to the creator of a malware that they ‘successfully bypassed 99% of sensing of malware software’
Essentially, I’m theorizing of a way to test an apps credibility without validating to the maker that they succeeded in creating a sneaky malware.
I perceive that there will be app stores that have malware and will be exposed quite quickly/immediate; somewhat like torrent tracker sites have comments and votes whether a file exposes malware or not.
Ouch. This is massive centralisation risk - equivalent to using the same credentials across numerous websites. Imagine the temptation of greed for the author of a very popular app that’s not generating much income, or for gangsters to blackmail / threaten a reputable author to issue an update that steals credentials to millions of user accounts. And of course there’s the problem government backdoors inserted into SAFE apps by the authors, forced by NSL (National Security Letter).
Ideas for Mitigation?
App Certification - through app stores or formal processes (as mentioned above)
Author Reputation
Granular security - different credentials for different areas of a user’s account and storage space
I think this is a serious issue. Anywhere that criminals can make large gains (e.g. access multiple accounts containing large amounts of private data) become attractive targets and vice versa. Reducing the “payback” of an attack (e.g. through granular security) is desirable as it reduces the incentive and increases the cost/benefit ratio of the attack.
App Access Control for SAFE API: SAFE provide an access mechanism, which is an integral part of an official SAFEclient (e.g. LifeStuff), which is the only app into which a user types their credentials. Apps are started by this client (in which case they can’t keylog), or must locate it if started externally (in which case our keylogger defeating scheme - there is on isn’t there - protects credentials). Before accessing the protected API, an app requests a key from the SAFEclient according the the permissions they require. In the simplest scheme, a key gives full access to the particular app, and expires when the user logs out/shuts down SAFEclient, or closes the app, or after some timeout. Each app’s key is specific to the app, and the SAFEclient login session, so no point in saving or sharing etc. Keys could be designed to offer only the permissions the user agreed to when they downloaded the app - e.g. access only to a single app specific folder on SAFE. This provides an extra layer of security, vouched for by each particular app store (since it is the app store that displays the permissions needed by the app, stored in the user space with the app or and app specific hash). This requires API calls to handle key validation, though I imagine there are caching or similar schemes that would help reduce the overhead per API call.
Feature Request: I’d like to propose this or a similar access control mechanism to the SAFE project - but don’t know where best to do this (@Viv - would I create this as an issue at Issues · maidsafe-archive/MaidSafe-API · GitHub or …?)
I’m not really the guy to specify this (as my crypto/access control knowledge is really only as a user), but hopefully the above makes sense to someone who is!
I think what you’re proposing Mark is in concept pretty similar to OAuth to delegate and control access to private content via access tokens that can be revoked by the user and also not revealing creds to the app directly.
While a system like oAuth helps “limit” the problem. It still does not resolve it completely due to the same limitations as I mentioned in my previous post where if a user gives access to an app for his/her pictures, even if they later revoke it, what the apps already got is compromised right there. So you’d want to trust the app to not mis-use what you’re giving it access to.
oAuth certainly helps but isn’t the only thing we’d require. We’d need a few approaches working together for this.
I’d say maidsafe.org currently is the ideal place for feature-suggestions(defo not github). Maybe if we can group posts under a tag like “feature requests” then when we get to a new sprint for the API, we can review the tag from the forum and pick the most wanted/applicable features and add them to JIRA for the next sprint. Once implemented we can remove the tag off the thread or rename it to an “accepted feature” / … accordingly.
I’m really a fanboy of SQRL when it comes to login, but it has a masterpassword. So 2FA, should also be part of the login scheme. Even if the app would steal your credentials it would also need your 2FA.
A problem that could surface, is that your 2FA qrcode, is scanned/screenshot by an app. Let’s say that this app can emulate a mobile phone environment. That could possibly mean, that the app could also log in, because it got your credentials.
Maybe 2FA is vunerable because you can scan the 2FA QRcode with multiple phones and still be able to login with each different phone. Maybe instead of just scanning the qrcode, you should also enter your specified phonenumbers, so that only those numbers open the 2FA safe.
Preferably you would want a Maidsafe 2FA app instead of Google stuff
This might have been mentioned somewhere before in the thread in some other form but I was just thinking couldn’t we create some kind of login credentials airlock?
Consider this you have an app of some kind that wants your login info, say so it can access your photos or your facebook, or whatever. You have an app that acts like an airlock. You log in at one end and enter your credentials. The app wanting information logs in at the other end. Then if it’s asking for photo access you pass it a photo access token granting it access to your photos, not your whole account. If it’s asking for facebook you grant it a facebook access token, not your facebook credentials. So that if it screws you all it has to work with is the token which can be revoked at any time and moreover it only has access to that one area of your account. The outside app at no time knows your actual credentials. The airlock is NOT networked beyond it’s ability to hand out tokens to apps. I’m trying to think of ways to further decentralize this idea and make it more secure. It just sort of came to me while reading the thread here.
Isn’t there a way to allow an app to use a user’s pictures (as an example of data) without having actual access to the pictures. Sort of like… give the app a reference to the picture or something. Say the app wants to have access to a picture you store for your avatar. So it’d be in like madsafe/pictures/internet/avatar/$avatar And you’d have a list of pics to match those variables and what not that you could change for various apps. But all the app would know was the name of the variable. The app at no time would ever actually access your avatar pic, it would only know the name of the variable and what not and then your system in turn would know what that variable would mean and go get the pic from your records. Kind of like how the self authenitication system for maidsafe works. at no point is your password transmitted on the network. Hey wait… wait… a thought is really percolating here. That’s it! Every file you want to share with an app could create it’s own self authentication based on the file in question. You create a reference id, or token based on the file and give that to the app. The app has no access to the file whatsoever. All the app has access to is an encrypted token and without you logged in interacting with the app it’s useless. Alll the app really can do is say “Your avatar goes here. Your wall paper goes there. The piece of music that is associated with token a goes here and the piece of music that is associated with token b goes there.” All the app would have is a list of locations to fill within itself and what token went into what slot. You would know what files went with what tokens and therefore be able to run the app but the app isn’t aware of any of the data going through it. Remember on maidsafe you don’t actually have to send files to the app in order to use them. much like how your desktop accesses a file on your hard drive to use as a background wallpaper and if that picture goes missing it’ll just show a blank background so to would the app. App data would be made up of references, not actual data. An app wouldn’t need access to your data, it would just need to tel lYOU what data to access and enter into that spot.
Does the app need to know your credentials? No. Does that app even need to know your facebook credentials to log into facebook? No. All the app needs to do is provide an interface for you to type them in. But the only one that needs to know yuor crednetials are you and facebook. Therefore the app would reference a facebook login and it would essentially say “facebook credentials go in this slot and get shipped to facebook and I never see them ever.” The app does NOT need to store your credentials ever. The app does NOT need to monitor your credentials ever. What the app needs to do is transmit your credentials. In fact what I’m wondering is why there wouldn’t be a seperate app to connect you directly with each social network so that various app builders wouldn’t have to worry about it. I mean when you log into facebook, or twitter, or diaspora or friendica they each have their own api right? So why not have something similar. Or have an app that worked like Delicius or add-to-any where you could share with any of these various networks without giving them your credentials. I mean when you give the addtoany app or the delicious app permission to post on twitter or facebook you aren’t giving them your credentials, you’re giving them limited access to your account. And I’m still not getting why an app would need limited access in the first place. If I’m wanting to share a file I’m essentially asking permission to upload to a network or database am I not? Either I’m entitled to share to that network or I’m not. if yes there I should have upload rights. If no I should have to ask permission. Why am I going through an app to do this? if I want to share a picture with my friend essentially what I’m doing is uploading the file to their database. Either I have permission or I do not. Why is the app even involved? Why does the APP need permission for an action I am carrying out? And if it’s an automated task (like uploading or downloading a bunch of files) then the obviuos question is do I, the user, have access rights? If yes permit app to do it’s thing. If no prevent app from doing it’s thing. Access rights should be established before the app even starts running. Like say I wanted to share a pic with someone and they didn’t want me to. I’d like “upload” and get “you do not have permision to share with this person. Access denied. Queue canceled.” It’s not a question of whether the app has permission but rather does the user have permission. Because remember all the app is doing is issing commands really fast that the user would be if they could.
- protects credentials). Before accessing the protected API, an app requests a key from the SAFEclient according the the permissions they require. In the simplest scheme, a key gives full access to the particular app, and expires when the user logs out/shuts down SAFEclient, or closes the app, or after some timeout. Each app’s key is specific to the app, and the SAFEclient login session, so no point in saving or sharing etc. Keys could be designed to offer only the permissions the user agreed to when they downloaded the app - e.g. access only to a single app specific folder on SAFE. This provides an extra layer of security, vouched for by each particular app store (since it is the app store that displays the permissions needed by the app, stored in the user space with the app or and app specific hash). This requires API calls to handle key validation, though I imagine there are caching or similar schemes that would help reduce the overhead per API call.