New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Providers - VPS Control Panel Nearly Completed
Hello,
I'd like to present BlueCP (name in progress) to the community. I would like to have 10 - 20 providers who are interested in having a new control panel back me in the release of this project. I've asked in the past for backers to my projects with mixed support. BlueCP as it stands is roughly 70% completed with all of the client area and most of the general administrative functions completed.
Video:
If you are a provider here is what you will need to contribute to receive a copy:
$100 upfront plus $25 per month (or more).
My contact information if you are interested: [email protected] or PM me for my Skype.
Not a provider? Still want to contribute? => http://redonate.net/campaign/bluecp
Comments
Good panel, we are developing XCP whmcs module.
Awesome work. Has this been on the anvil for long? I like what you did about the user's root password.
However, why does the user's control panel password have to be stored as such? Why not store a more secure hashed string?
@joelgm - Few months. As for the user's password, the final version will have a crypt encoded password with a unique salt for each user. For code editing purposes and for easy user manipulation it's set to md5 for now.
Edit: For those of you interested in security it will be using:
CRYPT_SHA256 with a global salt and a user specific salt at 50000 rounds.
@BlueVM: nice, finally somebody with a sane password practice!
@BlueVM
can I suggest you use scrypt or bcrypt instead of rolling your own password scheme? running SHA256 might sound like a good idea, but the larger rainbow tables on the web already have hashes as keys stored (specifically to beat this scheme). I recently audited a site with a similar scheme and we extracted ~60% of passwords.
@bluevm No issue contributing, but what about billing panel integration?
@nikcub - Interesting... unfortunately bcrypt is just as vulnerable and as far as I'm aware scrypt doesn't have a php module... At any rate its lightyears better than md5 no?
@FRCorey - Yes for WHMCS, not sure about hostbill.
@bluevm
see: http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
and: https://github.com/DomBlack/php-scrypt
proper bcrypt uses blowfish with a modified key schedule, not sha256. there is a big difference, even though it might not appear so
non of the web rainbow tables will return hits for bcrypt or scrypt, they will for sha256
phpass is a portable hashing scheme for php, you can take the classes out and include it in your project. it stores the hash within the password:
http://www.openwall.com/phpass/
I only see pretty GUIs lol, is this also PHP with exec() but then with joepie91 checking up on your ass implementing ugly fixes?
And if you decide to release it to the community they still have to pay and it won't be open source?
Life's not fair? You're just a greedy bastard lol - wtf do you need $2,000 for, you decided to develop this, so you invest you own time in it
Seen your projects, this is probably going be just as horrible as solus, just joepie security auditing
@erhwegesrgsr said: Seen your projects, this is probably going be just as horrible as solus, just joepie security auditing
cough PDO cough
@Rallias
Haha, I am pretty sure he will have the MySQL done nice and clean but I just hate PHP crap throwing around exec() even with fixes against exploitation.
Wish to know if you have the plan to sell licenses in the future and what the potential price is?
@nikcub - Sounds interesting I'll definitely take a look.
@erhwegesrgsr - Well for one SolusVM doesn't use PDO for its MySQL which is why the most recent vulnerability occurred. Secondly BlueCP does NOT use exec() statements unlike SolusVM. Third it does not allow any user input to go directly to the server, everything must be sanitized first, stored in the database in the correct format and then used on the actual system.
@sundaymouse - The licensing will be $100 one-time plus $25 per month.
I must agree you are asking for too much, since this is almost completed you shouldn't charge more than the monthly fee / one time fee for this panel. I'm a developer just like you and I can say that a functional panel like this one can be done within a week, This does not include ajax, html, css. (to be specific). So asking for $2000 is a bit harsh.
It is absolutely sure that there is a room on the market for VPS Control Panel after recent issues.So I think it is the best time for developers to offer their own control panels at competitive pricing.
@Makkesk8 - I guarantee SolusVM takes in more than $2k a WEEK with their panel. I'm not asking $2k from any one provider and I made my pricing very straight forward:
$100 upfront plus $25 per month (regardless of the number of servers your company has)
SolusVM charges $10 per Slave monthly (we pay nearly $100 each month for their panel) Most companies have at least 5 servers if not more, so my price is definitely cheaper over the long haul for providers.
Awesome project! I wish I had the time/funds to help out. Looking forward to seeing what's next
Edit: please ignore everyone complaining about the cost. Seems like extremely fair pricing!
bcrypt quietly cuts off inputs after a certain length, effectively weakening the strength of your hash on longer inputs without even telling you. Very bad idea.
scrypt is relatively new, and should be considered 'unproven cryptography' unless more peer-review takes place.
I'd like to know what said 'similar scheme' was, because there's a world of difference between a single SHA256 hash, and using crypt() + SHA256.
Additionally, he isn't "rolling his own password scheme" - he is using the quite commonly known UNIX crypt scheme, as it is implemented in PHP (and quite a few other things).
@joepie91: what about openwall's phpass?
@alex: It's primarily a bcrypt implementation, and doesn't really offer anything besides that. Can't really see a reason to use it now that PHP implements all these things natively...
The one thing that would be interesting would be a proper peer-reviewed PHP implementation of PBKDF2... but no such luck
Wow. Great work here. If this does have all the security features over SolusVM, and all its features, it needs to be publicly available.
@joepie
that is an implementation detail, not a design detail. in some implementations it is 56bytes, in others it is 72bytes - which is why you encode as hex or hash it (32bytes for SHA256 output)
There isn't, really. Crypt has nothing to do with it, its just PHP's confusing implementation. If you call crypt() with the algo set to SHA256, all you are doing is running hash() - there is no "crypting" involved.
echo crypt($password, '$5$rounds=5000$salt');and
$output =$password . $salt; for($x=0;$x<5000;$x++) $output = hash('sha256', $output);are the exact same thing. they are also both within the realm of being broken with rainbow tables and modern ASIC hardware (which is the original point I was making - that if starting over today given the opportunity don't use SHA256 but rather use bcrypt or scrypt as a way to future-proof). this is why blowfish was extended in crypt in php 5.3.7 - a bcrypt analog (without the key scheduling) but with a work factor and broader salt
the easy solution is to change crypt from using $5$ to $2y$ and specifying a work factor, but since that requires php 5.3.7 most who are distributing software choose to integrate either the phpass library or bcrypt module.
'crypt' can be describing anything, it used to mean DES, then it meant MD5, then it meant SHA and now it can mean blowfish. it isn't a 'scheme' so much as it is just a UNIX library call that wraps an implementation.
php got itself into this situation because it exposed all the standard libc libraries, thus had crypt, but when it came time to integrate more serious crypt it was all thrown under that function and also implemented as a myriad of other libraries. there has never been a good layout/structure and a lot of people thus misinterpret 'crypt' as always being encryption when in most cases it is hashing.
There is not a single respectable security researcher to be found on the web, see for eg. answers on stack exchange, blog posts, research papers, etc. who would argue SHA256 over Bcrypt or Scrypt.
@alex
your choices are to either require users to have php 5.3.7 and use blowfish in crypt, or integrate phpass or bcrypt. I do the later in cases of both inhouse software and distributed software. wordpress and other OSS that have recently become more aware of this issue also do the later.
its worth reading up on the issue though and understanding it, because you can sell it to your customers. see the stack exchange on 'passwords':
http://security.stackexchange.com/?tags=passwords
there are some great answers in there.
the original paper for bcrypt is also very accessible, if you understand the difference between hash and crypt. it is written by niels provos of the OpenBSD project, who is one of the most respected cryptographers (written in the 90s, ppl only started to realize how far-sighted he was in more recent years):
http://en.wikipedia.org/wiki/Bcrypt
paper: http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
presentation to USENIX in '99: http://www.openbsd.org/papers/bcrypt-slides.pdf (PDF, a few hundred KB)
@bluevm
outside of the password storage method, how are you writing your code - are you using a web framework, are you using anything specific to filter variables, anything else you can talk about? if you like, I can email you some feedback or suggestions on libraries / classes / functions etc. to use and some info on more modern attack methods that almost all of the existing software is still vulnerable to.
after some research I started using phpass and it's implemented already, just as a non-pro wanted a second opinion. many thanks!
@nikcub, @alex, @BlueVM, @joepie91:
This is a PHP implementation of PHP 5.5's password functions: https://github.com/ircmaxell/password_compat
It's easy, well-implemented and saves you a lot of headaches. Also, it's quite secure. I believe more secure than the SHAxxx variants.
@nikcub - I'm using cPHP as the framework with PDO for database management coupled with clean executes. As an example getting a full database dump is impossible using my methods.
Also, exec isn't necessarily bad unless used (and escaped!) properly.
@nikcub
An 'implementation detail'? It cuts off a significant part of your entropy when you use passphrases! That is unacceptable. And every single bcrypt implementation does this.
Maybe you should have read what I wrote better. I explicitly compared crypt() + SHA256 with a single SHA256 hash. Yes, there is a world of difference between those two.
You do realize that bcrypt is vulnerable to this exact same attack, as is scrypt when higher-memory ASICs start becoming more commonplace, no doubt accelerated by the growth of Litecoin? Litecoin developers are actually already warning about this, and explicitly saying that their "GPU- and ASIC-hostileness" isn't going to last forever.
Correction: I meant C crypt, not UNIX crypt. I never said it's an algorithm, it's primarily an encoding scheme. It doesn't 'mean' any particular algorithm, which is why I specified "crypt() + SHA256".
I'd like to see you back up that claim.
And honestly? I haven't seen a single respectable security researcher provide valid justification for cutting off the input after X bytes either. The only 'real' response I've gotten to it from anyone at all, was that "that doesn't matter because noone has passwords that long", which is an absolutely ridiculous assumption to make.