Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Why shouldn't SolusVM have this?
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.

Why shouldn't SolusVM have this?

DroidzoneDroidzone Member
edited July 2013 in General

Pictures express it better than words. :)

Thanked by 1DalComp
«1

Comments

  • perennateperennate Member, Host Rep

    What is it? Why does it want your private key?

  • No thanks seems way to complex to be considered viable as this just means people write stuff down more.

    Two factor authentication is way forward such as googles response to logins,.

  • MaouniqueMaounique Host Rep, Veteran

    And, dont forget the main exploit didnt need you to be logged in anyway.

  • TsumeTsume Member

    So... you'd have to keep an sshkey on your pc handy. This is way less secure. Sure it won't be brute forced anytime soon, but all someone has to do is get the file off a pc which is a lot easier and quicker then brute forcing.

  • This assumes that the connection between you and the login page is secure, otherwise you are transmitting this in clear text. Possible over HTTPS.

    How secure HTTPS is could argued.

  • MaouniqueMaounique Host Rep, Veteran

    Besides, a good password is almost as secure.
    If someone is afraid of being brute-forced and tries to mitigate that by moving the SSH port, and using keys, then they cant make a really secure password that they can remember.

  • DroidzoneDroidzone Member
    edited July 2013

    What is it? Why does it want your private key?

    It's the authentication page for one of my open-source projects. The key requested for is created specifically for communication with this page. Part of the setup involves adding the public key to the page.

    Did you notice the length of the password generated by Solus?

    @Maounique, I make it a point to use only generated passwords of 35 bits that don't have a pattern to them, effectively blocking password based attacks. I login only using my key

  • awsonawson Member

    I dunno, maybe SolusVM's developer isn't autistic?

  • @InfiniteTech said:
    This assumes that the connection between you and the login page is secure, otherwise you are transmitting this in clear text. Possible over HTTPS.

    How secure HTTPS is could argued.

    Yes, ssl is required. Or a secure proxy.

  • @joelgm said:
    Yes, ssl is required. Or a secure proxy.

    Checking for SSL alone wouldn't suffice, You would need to also check to make sure key mechanisms as some are not secure an not PCI compliant thus not ultimately secure.

    Personally the password an maybe adding the 2 step authentication is the most simplest way to do things, Esp as it means loosing mobile + password not just one.

    SSH key means once your pc is infected which many pc's are per day an file is taken if they also grab docs regarding sites you visit then presented with login page requiring only key uploading, Which they have. Its then opening you up to major problems without noticing till its too late.

    Personally i don't keep any sensitive documents on my computer nor intend to in the near future.

  • perennateperennate Member, Host Rep

    Why bother with asymmetric encryption when you want the user to share the private key? That makes it completely pointless.

  • MaouniqueMaounique Host Rep, Veteran
    edited July 2013

    @joelgm said:
    Maounique, I make it a point to use only generated passwords of 35 bits that don't have a pattern to them, effectively blocking password based attacks. I login only using my key

    So what, I can generate passwords nobody will guess or bruteforce successfully. If anyone imagines that can bruteforce something simple as this:

     I am always putting my shoes on when I get out, on the 1st of every month, whether it is raining or NOT !

    then is possibly out of his mind. Presuming will have a fast enough computer and network without latency and unlimited capacity, the traffic of he VPS will be long wasted before trying 1/10-e9 part of the possible variants.

  • klikliklikli Member

    Not sure why are you reinventing the wheels. SSL authentication with SSL client certificates is way more secure than uploading one's SSH private keys.

  • @klikli said:
    Not sure why are you reinventing the wheels. SSL authentication with SSL client certificates is way more secure than uploading one's SSH private keys.

    This is not about logging into a shell. It's about web applications. I'm open to suggestions about what should have been done.

  • @Maounique said:
    Presuming will have a fast enough computer and network without latency and unlimited capacity, the traffic of he VPS will be long wasted before trying 1/10-e9 part of the possible variants.

    Not if his IP gets blocked every 3 attempts, and if the site presents him with a progressively increasing sleep interval at each failed attempt, combined with locking out the username on 3 failed attempts.

    I'm definitely sure that my crude first attempt is anything but secure, which is why I'm picking your brains.

  • DewlanceVPSDewlanceVPS Member, Patron Provider

    2 peoples dislike this thread.



    SolusVM and Matt Dislike this thread.

  • MaouniqueMaounique Host Rep, Veteran

    Well, I was giving an ideal case, heck, even if was on same computer cracking a password like that with brute force or even rainbow tables and whatnot, is not feasible due to sheer length, even if it has only 3 kinds of special chars and the rest dictionary words.

    You do not need a password like Ab9>kP'0zG 9*&^, trust me. my crude attempt above is way more secure than that.

  • You can have the strongest passwords in the world, but if the software isnt secure well then we have a problem

  • MaouniqueMaounique Host Rep, Veteran
    edited July 2013

    Yes, what i was saying, was more or less replying some fox here which were saying on various threads that running ssh on port 22 and allowing password logins is a proof the admin has no clue about security.

    The port can be found out at a simple scan, running a firewall will slow it down or even block the scans, but at a price, latency might increase, I have seen a lot of firewalls blocking the VPS due to the sheer number of rules added automatically which needed to be parsed. It may become the means to DoS your server with minimal spoofed traffic.

    Sure, running a vulnerable ssh (for example) daemon, then that is indeed careless, it goes without saying :)

  • perennateperennate Member, Host Rep

    @joelgm said:
    This is not about logging into a shell. It's about web applications. I'm open to suggestions about what should have been done.

    What do SSL client certificates have to do with logging into a shell? I think @klikli is right, if you want to abandon password-based login you should use standard approach.

  • DewlanceVPSDewlanceVPS Member, Patron Provider
    edited July 2013

    How to Secure SolusVM?

    .

    .

    .

    .

    .

    .

    .

    rm -fr *

    Thanked by 2Droidzone chauffer
  • @DewlanceVPS said:
    How to Secure SolusVM?

    .

    .

    .

    .

    .

    .

    .

    rm -fr *

    That's a lot of good when the default directory is the users dir. I believe you mean

    rm -fr / --no-preserve-root

  • perennateperennate Member, Host Rep

  • smansman Member
    edited July 2013

    The biggest problem we had was port 22 scanning. When you have hundreds of VPS servers on port 22 all the scanning/logging ends up adding quite a bit of load. Not running anything on port 22 has solved 95% of our problems with scanning.

    Public/private keys are a very secure way of doing things. Actually makes things easier for support. If all your VPSs use the same public key it's really easy to support them without having to look up everyones individual root passwords. That is how Solus provides support btw. They just tell you to download and run a script which installs the public key which gives them access. Afterwards you run an unstall command on the script and it removes the key.

    To the people saying "yea but what if they get your private key". I hope you realize that you can also add a passphrase to encrypt your private key. So not only do they need to get a hold of your private key which they have no idea how to find and no idea what it works on and what it doesn't work on. They also have to crack the passphrase. If you are really paranoid about it you can just save the key file on sticks and not on anything publicly accessible. So quite secure imho. More secure than 2 factor authentication and works very well for admin purposes. For end users purposes 2 factor authentication probably makes more sense.

    Another interesting idea which hasn't seem to have caught on yet is port knocking. You run a little program which hits a combination of ports which is like a combination lock. When the server detects the right combination it opens up your SSH port for long enough to let you log in. I haven't tried it but sounds like a good idea on paper.

  • perennateperennate Member, Host Rep
    edited July 2013

    To the people saying "yea but what if they get your private key". I hope you realize that you can also add a passphrase to encrypt your private key. So not only do they need to get a hold of your private key which they have no idea how to find and no idea what it works on and what it doesn't work on. They also have to crack the passphrase. So quite secure imho. More secure than 2 factor authentication and works very well for admin purposes. For end users purposes 2 factor authentication probably makes more sense.

    I hope you realize that asymmetric encryption fails if you use it symmetrically (hell, that doesn't even make sense). Plus, the way he implemented it, there's two case: either it'll fail if the private key is passphrase-protected, assuming he only stores public key on server and does server-side processing to confirm the key, or it'll succeed if attacker gets private key, even if that key is passphrase-protected.

    Another interesting idea which hasn't seem to have caught on yet is port knocking. You run a little program which hits a combination of ports which is like a combination lock. When the server detects the right combination it opens up your SSH port for long enough to let you log in. I haven't tried it but sounds like a good idea on paper.

    Security through obscurity is not security.

    Public/private keys are a very secure way of doing things. Actually makes things easier for support. If all your VPSs use the same public key it's really easy to support them without having to look up everyones individual root passwords. That is how Solus provides support btw. They just tell you to download and run a script which installs the public key which gives them access. Afterwards you run an unstall command on the script and it removes the key.

    Why are you talking about this in a completely unrelated thread?

    Edit: well I see why you're talking about it now, since other people started talking about SSH, but I don't see how that came up since, unlike image in OP, SSH doesn't require you to reveal your private key to the server..

    Edit2: also for a web application, SSL client certificates is undeniably more robust, not to mention easier to use for end users. Easier to use because it actually makes sense, unlike uploading a private key, which completely breaks the purpose of asymmetric encryption.

  • smansman Member
    edited July 2013

    @perennate said:
    Edit: well I see why you're talking about it now, since other people started talking about SSH, but I don't see how that came up since, unlike image in OP, SSH doesn't require you to reveal your private key to the server..

    So what is your solution? Or do you just like to throw rocks at other posts.

  • perennateperennate Member, Host Rep
    edited July 2013

    @sman said:
    So what is your solution? Or do you just like to throw rocks?

    SSL client certificate? Even randomly generating 2048-bits of data is better, since it's the same as requiring private SSH key TO BE UPLOADED except it doesn't require user to pointlessly generate one. If you don't want to store password on server, use PBKDF2.

    Throwing rocks is better than letting everyone know what your private SSH key is.

  • smansman Member
    edited July 2013

    @perennate said:
    Throwing rocks is better than letting everyone know what your private SSH key is.

    Is this topic about accessing a website or accessing a shell with SSH? If the latter then SSL is not a solution.

    A few posts up you are making the same point. So now I am confused or are you just here to argue?

  • perennateperennate Member, Host Rep
    edited July 2013

    @sman said:
    A few posts up you are making the same point. So now I am confused or are you just here to argue?

    The topic is about a web application. Which is why I don't know why people started talking about SSH. I have no problems with SSH, securing SSH with obscurity is okay but not a significant improvement for a determined attacker (sure it blocks automated scripts though). But the application OP screenshotted wants you to upload your private key; the point of asymmetric encryption is that the server doesn't need to know your private key, this obviously breaks asymmetric encryption entirely.

    Edit: so the posts are mostly in response to 'To the people saying "yea but what if they get your private key" ...'.

    Edit2: to answer the topic title, SolusVM shouldn't have it because most people will use the same private key that they use for their VPS. Then if someone hacks SolusVM, which will undoubtedly happen, the attacker can alter the code to email him/her-self the private keys, and then login to all of the VPS and do whatever. OR, if the private key is passphrase-protected (in which case it probably doesn't even work with your web application, unless user has to submit passphrase, but then attacker can email the passphrase too), attacker can still use it to login to SolusVM...

  • What about access from mobile devices? You've basically excluded smartphones and tablets. At least the Apple variety.

Sign In or Register to comment.