So.... This may be a bit of a pipe dream here, but I'll probably never know unless I ask. (:
Considering Rambox is built using Electron, is it possible to store the login details for a service, instead of having to log in manually on each tab?
These days practically all web browsers have plugins available that do password management, so I'm working on the assumption that a similar system would be possible here. With that said, I don't know what is involved in said systems, so I may very well be suggesting we play baseball on a cricket field here.. :/
Is this a possibility? And if so, is it a viable one..?
Yes, it's possible. And I was thinking about that a long time ago, but at that time I decided not to take that path to be responsible to store important data of the user.
But maybe we can think about this again for version 1.0.0.
Yeah, completely get that. I'm not normally the kind of person to save any passwords, but in this particular case with everything contained in one app, I thought it would be very useful.
I'll do some research on my side as well, so I'll drop you a message if I find anything helpful.
I think that this is a crucial feature: I set up a lot of services in Rambox. There is no way I'm gonna login to every single one of them every time I launch the app. I'll be better off just keeping a lot of tabs open in Chrome.
Edit: I found that Rambox saves my sessions just fine. This only didn't work when I restarted it for the very first time. But now it's working and that's all I was looking for.
I will add a password management feature in version 1.0 to save credentials so the user doesn't have to log in twice anymore. Of course, credentials will be encrypted by a master password seed provided by the user each time he opens the app (we don't store the master password at all).
What do you think about this?
Sounds pretty reasonable to me. I didn't have any specific notions on how it should be done, it was more of a logical question than anything else... Very big thanks in advance. :)
@z0rc, I see you whacked the :-1: emoticon.. Since this idea wasn't originally on the cards, would you care to share your opinion of why you don't like it?
Basically I'd never trust this app syncing credentials. I don't have any guarantee that no matter how honest author's intentions are those credentials won't be stolen and/or abused. The sync service hasn't passed a single security audit. The author doesn't have enough domain knowledge to implement bullet-proof encryption what would withstand variety of attack vectors or just simple brute-force.
So my :-1: based on this. It would be much safe to not implement this rather than dealing on fallout that potential breach of this service could cause.
There are already dedicated solutions that provide password sync across multiple devices. Please use them.
I am not following what the benefit would be?
This sounds very security wrong in some way. I would not like for someone to be able to copy a file or similar that would allow them to have access to everything inside the application. Using a system that would allow for sync between devices is different though if it could use something like google auth with the tokens bound to my device as a two factor auth. But that is as far as I would trust it.
Do you need to login everytime you start Rambox?
I transitioned from Franz to Rambox yesterday, and I can understand where ZaLiTHkA's post is coming from.
When I booted my system this morning and opened Rambox, only one of my ten services was usable. I had to manually log into the other nine services. If this were the default behaviour, I wouldn't continue to use Rambox.
Based on felixfischer's comment above, it sounds like this session-loss issue might only happen on the very first reboot. If that's true, then the password-storing feature would not be necessary.
Edit: After another reboot, all of my services are still connected. It may be valuable to notify new users that the services will keep their sessions alive (after second reboot), but otherwise no changes are needed, in my opinion.
I think there should be checkbox for each service. When checked, it should work just like in usual web browsers. But it should not be checked by default.
Hello again.. (:
I must admit, I had never logged in to Rambox itself before; but anyways, I did this time after a fresh Linux install. After using my Google account (typical, duh.. lol. :) to authenticate "me", go through the login, respond to the 2-factor auth request, and done. :) I then added Google's "Inbox", and went through the same process..
This got me thinking, would it work to authenticate the "tab" sign in request using a frame higher than just "itself"? So, in short: I sign into Rambox and Rambox authenticates "me" to whichever service I say it can, using the account access token I choose (pick a currently signed-in account to use).
Random thought, I know.. But would something like this be worth trying?
edit
Actually, now re-reading that, it sounds like I'm describing the idea of "signing in" to the Chrome browser environment itself. O.o But still, the same sort of principle applies here.
At it's very simplest, this would effectively be sharing authentication tokens with one or more service tabs.. Is this possible in the Rambox "environment"?
Would it be possible to locally store the usernames & passwords in an encrypted file?
A user wouldn't be able to sync logins across systems, but honestly I don't think most people expect their logins to work with a new service the first time they install them. And anyway, Rambox could have some helper text explaining why you have to re-login on newly installed systems. If that solution works, it would solve both sides of the security/convenience issue.
@JoshKLPA, I wouldn't ever recommend storing usernames and passwords... Ever. Even if they're encrypted.
On the other hand, storing personal access tokens (same idea as public/private keys for SSH connections) would be awesome. The problem with this is that different services implement these sort of things in different ways, so each one would need it's own unique implementation in RamBox. I can only guess that this is the main reason something like this wasn't built in from the start.
@ZaLiTHkA Could you explain why it would be an issue if it's only ever stored locally? If someone can hack into a computer to even access those usernames and passwords, it seems like the user has a lot more problems than whether their encrypted usernames and passwords are kept there. To be clear, I'm talking about hashing them before they're encrypted.
Even still, assuming you're correct (I do believe you, I just can't figure out why seeing as a lot of services like web browsers do this kind of thing all the time), how about an integration with a service like LastPass? Then the values could be automatically populated, at least.
@ZaLiTHkA I think it is up to user to decide to store passwords locally or not. Like web browsers do. But they do it by default, and here, I think, user shoud allow this explicitly for each service.
For some services this is not a pain at all. When they are well-designed, they do not ask for password every time. But some services do. I think it lawyers' fault: such an approach does not provide more security, but transfers more responsibility back to the user. Then, user's responsibility should also be to decide if they want to store passwords locally.
Sorry about the delayed response, my house got burgled recently and I've had a crazy few days on my side dealing with police and investigators..
I must admit, the concept of not storing usernames and passwords locally is just personal preference, there's no special reason for it, but suffice to say the only time I feel it's safe to save any login details is when I have the option of revoking that access remotely later on.
Sorry if my comment came across as something based on some special "online security" case, it really is just personal preference. Hope that clarifies my views a bit.. :)
edit: Actually, this is one case that proves my point, all I had to do security-wise after having a laptop, tablet and phone stolen, was to revoke the access I had previously given those specific devices to various accounts... If they had usernames and passwords saved to them, then I'd have to go changing passwords now. So call me pedantic if you will, but it has it's benefits.
Oops... I wish you to get all of your problems solved as soon as possible!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed since there has not been any recent activity. Please open a new issue for related bugs.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I will add a password management feature in version 1.0 to save credentials so the user doesn't have to log in twice anymore. Of course, credentials will be encrypted by a master password seed provided by the user each time he opens the app (we don't store the master password at all).
What do you think about this?