All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Host Login - All In One Place To Access Your Server Information
Hello LET,
Host Login is a project that I have been working on for last week.
I hate having to search through my emails every time I have to login in to my server's vps panel. And specially when I am working on client's websites, I hate searching through emails to find the right login info.
So while I had some free time, I came up with my own tiny CRUD app to store them in one place. I showed it to some of my co-workers and they loved the idea, and wanted to use it as well. I thought about the number of people in LET that have multiple servers (and the lowend server addiction like I do) and thought you guys might get some use out of it as well, so i spent the last week converting my personal project to something that the public can use, and securing it.
I know some of you are going to argue that this cannot be safe and you don't want to store your passwords in some random server somewhere, and thats a perfectly valid argument, I wouldn't want to store my passwords anywhere either.
So to fix this issue, the application encrypts all passwords using the industry standard AES-256 encryption before submitting the data to our servers. The password will be encrypted using a passphrase that you will be able to set while creating your account, and you will need to use the passphrase to encode/decode your password every time. This means your passwords will never be sent to the server without being encrypted, and only you will be able to decrypt those using your passphrase. So technically, even if someone gets access to the database, they will not be able to access your passwords. You can verify that no data goes to the server unencrypted by examining the post data using something like firebug.
The passphrase will not be sent or saved on the servers either. A sha3 512 hash of the passphrase thats created on the client side (your browser) will be send and stored on the server (to make sure you use the same passphrase everywhere so that everything can be decrypted using one passphrase), and when the user is trying to encrypt something, the passphrase's hash will be checked against the one in server on the client side. sha3's are irreversible, so this means anyone who doesnt know your passphrase (including me who has access to server) wont be able to view any of the confidential information. Again, you can verify this by checking the post data submitted to servers.
Host Login supports adding a lot of server data like login information, links, specs and a lot more. You can hover over any data and it will automatically be selected so you can copy it easily.
The instant search box will let you filter your servers by anything, for example if you want to only see servers that are in Texas, just type in texas and it will automatically filter out all servers that do not have texas somewhere in them instantly.
I am working on implementing one click logins to whmcs and cpanel , and if technically possible other panels.
Here are screenshots (all servers can be expanded or collapsed):
It is free and is always going to be free. Feel free to suggest new features or report any bugs here or to [email protected]
I would love your feedback on this. Thank you for checking.
Url: https://hostlog.in/
Edit: sorry had to delete that poll the first time because lowendtalk.com doesnt let me edit the page when there is a poll
Comments
I think that it is a great idea and nicely executed @ksubedi but the problem remains trust.
Like you stated in your main post "The password will be encrypted using a passphrase that you will be able to set while creating your account"
this passphrase obviously will be sent to your server aswel, this means that you could lookup the passphrase from a user and decrypt his data with it.
I'm not trying to imply that you would actually do this but how could I ever validate that?
Thats actually a really good point, glad you brought it up and I already thought about that as well.
I forgot to mention on the post (will update it), but the passphrase wont be sent or saved on the servers. A md5 hash of the passphrase that will be created on the client side will be stored on the server (to make sure you use the same passphrase everywhere so that everything can be decrypted using one passphrase), and when the user is trying to encrypt something, the passphrase's md5 will be checked against the one in server on the client side.
MD5's are irreversible, so this means anyone who doesnt know your passphrase (including me) wont be able to view any of the confidential information.
Edit: uses sha512 instead of md5 now
Very good point. Anyway nice app, ksubedi you should work through this issues first..
MD5's are not quite irreversible anymore. And I still don't understand, how are the passwords stored in the database?
MD5 is far from secure, to even suggest so is insane. You should be using something like Bcrypt, or SHA256 at MINIMUM.
The only way to reverse md5 that i am aware of to reverse md5 is to brute force it, but if you use a good passphrase that could take years. And the passwords are encrypted on the browser using AES-256 using your passphrase and then sent to the server, so raw passwords are never sent.
Yeah you are right, md5's are not the safest, but they are not used to encrypt passwords here. They just serve as a token to check if the user is using the same passphrase everywhere so that one passphrase can decrypt everything at once (and user doesnt have to enter seperate passphrase for every single password onevery single server).
Plus they are not exactly reversible, since input material can be an infinite length, where the output is always 128 bits long. Thats why they act more like tokens. If user's use a safe passphrase, its going to be almost impossible to reverse it. But again, its not like the md5s will be publicly available, they will be on the server and wont be available to anyone.
Thanks for the feedback guys
Just to check again though, how are the panel passwords stored in your database? I understand there is an md5 hash, but if you want to show my passwords to me they must be reversible?
So are they in plain text or something else inside the database? It look like a nice app, but I just want to check this.
So when you add a server on the dashboard, and try to add a password to the server, it will ask you for your passphrase, which will then encrypt the password with your passphrase using AES-256 right on your browser before even sending it to the server. The encrypted data will be stored on server, and when you want to decrypt it, the it will ask you for passphrase which will then decrypt the data on the browser.
I've been thinking of making this myself and this looks pretty awesome.
One thing though, please open source it!
Closed source != secure
If we can run this on our own systems, that would be awesome.
I was actually thinking about making this open source at first, the reason i didnt was because of security. If its open source, everyone gets access to code which means more 0-day exploits. Also i was thinking about monitizing it somehow (still havent thought how
) at some point. But ill definitely see how it goes 
This. The only way I'd consider using something like this. Full marks for concept and presentation though @ksubedi.
At this point I have no plans for that (although i did think about it), but you never know, things chage . Right now, whoever feels secure will use it and I tried my best to make as secure as possible, if not it just becomes another project in my resume and portfolio
Some mobile version screenshots:
Security through obscurity is a poor form of security, as noted by NIST, "System security should not depend on the secrecy of the implementation or its components."
Your explanation of why MD5 is OK for the passphrase makes no sense either. MD5 has been broken since 1996 and it is not recommended for use. Regardless if the passwords are AES-256 encrypted, if the hash can be reversed then the passwords can be decrypted. A passphrase should be salted and hashed with a cipher like bcrypt, or with SHA-256 if bcrypt is not possible.
If the hashing is changed from MD5, I'd be much happier to sign up!
I agree, but there are other reasons behind not making it open source. I am still thinking about it so cant say anything yet.
MD5 generates a one way hash, not encryption. Which means there is no way of converting a md5 string back to the original content unless you convert random strings to md5 and comparing them (brute force) with the hash, and that's not a easy task unless the user uses something simple or common like 'hello' for passphrase. So its totally up to the users.
And about using salts, there is no point in doing that. The whole process with passphrase happens on client side (browser), which means even if i were to use a salt, it would be as easy as viewing the source on the client side for the hacker to get the salt.> @iKeyZ said:
If this gets popular, @ksubedi 's server becomes a target and if someone breaks into his server, the code that runs in the browser can be trivially changed to post the cleartext password to the site (or somewhere else). I think this idea works well on a personally run server as others have suggested.
+1 to open source it since it handles peoples passwords...
Salting can help against rainbow table attacks. I'm also aware of MD5 being a hashing algorithm and not encryption, and despite your claims that MD5 hashes can't be reversed there are a number of known attacks against it. Due to it being broken and various attacks being possible, brute forcing it IS an easy task for simple and complex passphrases alike.
Great Idea, but big No No for me.
Update: Just maybe I can use the service to track VPS but not storing the password (and username). So basically just some general vps data but in one place.
Changing the code wouldn't even be necessary. The MD5 hash of the passphrase is stored on the server. It would be trivial to run an attack on the MD5 hash to obtain the passphrase, which can then be used to decrypt the passwords themselves.
The security of the passwords themselves relies entirely on a broken hashing algorithm. Regardless of if the passwords are AES encrypted, or encrypted with some super unbreakable encryption. The MD5 hashed passphrase can be obtained by the average person easily.
I do agree with you on the fact that md5 is definitely less secure and takes less time to hash than for example sha256 which makes brute forces easier.
For this reason, i am working on implementing sha256 isntead of md5 and while im at it ill also add salt. I will push the new update to the production server if everything looks good locally. As of right now, 23 people have signed up and those will be marked legacy for the next update (those will still use md5). I will create something that will let them switch when i push the next update.
@adly indeed, if it's kept as unsalted MD5. But you wrote:
...which does nothing to deal with the broader attack I'm most concerned about...how does changing to bcrypt help in the face of his server getting pwned? Think "path of least resistance" and the crypt code becomes irrelevant.
Fair comment. I'm not sure where the code doing the hashing is done, but I'm assuming it's in Javascript file somewhere. You could, conceivably, check for file changes using a hash of the files. However, even if he did open source the code, how would you know the code he is running is the same? Like you noted, on a personal server things can be better secured.
The use of salt and something like bcrypt is purely to ensure the hash can't be reversed back to the passphrase, which could then be used to decrypt the passwords.
It would be nice if you could export the data to CSV or similar. I would use this as a way to keep track of my servers and their costs.
I agree with you, not using because it is hosted would be like saying you wont get a vps from some provider because they will have your password (whmcs stores vm and cpanel passwords in plain text).
Thats actually a nice idea, I will look into it.
Just to give everyone an update, I have pushed a new update to the production server and implemented these:
Uses 512 bit sha3 instead of md5 for hashing passphrases
Uses salts
Added passphrase confirmation.
This push will be in affect immediately for new accounts. As for old accounts, those are marked as legacy and will still use md5 because it is technically not possible to convert those. If you are already a user and want to change your account to use sha3, please pm me with you email and i will reset your account so you can create a non-legacy account.
It's 5 am and im super tired, need to go to bed, so ill answer other questions later. Enjoy your day everyone!
Edit:
thought i'd ping you
I was suggesting you open source the code so people can run it on their own servers.
I sense your intentions are noble but would strongly suggest against capturing/storing peoples' VPS passwords unless you are prepared to either spend significant time and money on properly protecting them - or open source the code so peeps can self-host.
EDIT: typo
I have spent significant time and money (40+ hour of work which I could be getting paid for and other resources) and I am not storing vps passwords, they are fully encrypted and no one except the users can access them, not even me. And I am never against the idea of open sourcing things but not all things work that way. I created this as a service, not as an distributable application. And there are other reasons I cannot open source it at the moment.
@ksubedi then run it as a commercial service with budget spent on security controls (including testing)...this is what I meant by "spend significant time and money on properly protecting them".
it's goog things,but how can i know you do what to store our passwords secure?