• Syntaxerror (unregistered)

    Could someone explain "The keys to the kingdom" for me?

  • JustSomeDudette (unregistered) in reply to Syntaxerror

    If you're setting an admin password for anything, generally you want to make it hard to crack. Not allowing special characters in the password doesn't help keep it secure, which is what you want for your server management.

  • GWO (unregistered) in reply to JustSomeDudette

    You have 52 upper and lower case letters, 10 digits and about 10 non-banned punctuation characters (and thats limiting yourself to printable ASCII). If you can't generate a secure password using those, then adding another 12 punctuation characters is not actually going to help. You may have to use two or more extra characters. Big f**king deal.

    On the plus side, you get an extra (hopefully entirely redundant) layer of security-in-depth from SQL injection attacks.

    What's the problem here?

  • SomeRandomGuy (unregistered) in reply to GWO

    Just because it doesn't allow special characters in setting your password doesn't mean that it properly cleans up any input for SQL attacks.

    In fact by specifically not allowing special characters in a password in this day and age suggests that the system can't handle special characters properly and I would be double concerned.

  • (nodebb) in reply to GWO

    GWO, it sounds like you are really not aware of the implications for disallowing any subset of characters in a password. The issue is not that we can't create a secure password with what is left, which we can, but you just told anyone trying to crack the system that they can ignore a very large set of possible passwords from their attempts greatly reducing the time it could take to crack the security used. Rainbow tables could be made smaller and faster to search, algorithms can spin through exponentially fewer combinations, etc.

    Along with SomeRandomGuys comments to this, if they are denying those characters for the purpose of sanitation, then their communications back to the server are already clogged up with crap.

  • (nodebb)

    I wonder when you've put in a password without those special character, if they'll show a message like

    All special characters are not allowed!

    Special characters are all characters except

    'h', 'u', 'n', 't', 'e', 'r', '2'.

  • Lots of people seem to screw this principle up. (unregistered) in reply to KattMan

    Proper SQL communications cleanly separate parameters from commands, so there is no issue with "special" characters. If the concern about this is genuine, it reveals a lot about the system that is of interest to a potential hacker.

  • Wernsey (unregistered)

    Having the user choose his own account number is really a WTF distilled to its purest form. I mean, some WTFs are WTF but this really takes it to the next level.

    My imagination is filling in the blanks as to what the back end looks like: I guess they try to insert the new user in the users table (without prepared statements, naturally) and then catch the constraint violation from which they generate the error message

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to KattMan

    And perhaps more importantly, it might mean that the backend developers are likely not storing passwords smartly -- they might be storing them in plaintext (or weak, home-grown crypto). If you salt and hash properly, the only place you need to worry about special characters is when decoding the form handler's POST parameters in the web frontend.

  • tharpa (unregistered)

    I can see how a test Saskatchewan could be valuable.

  • (nodebb) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    Exactly, which is why I stated " if they are denying those characters for the purpose of sanitation, then their communications back to the server are already clogged up with crap." I didn't assume where the clog was, or even that there was only one of them, just that it was clogged, and it is crap.

  • RichP (unregistered)

    Well, the squirrels are back in the error log again. Your father won't call tech support, he says it's personal this time.

  • Dan (unregistered) in reply to KattMan

    "GWO, it sounds like you are really not aware of the implications for disallowing any subset of characters in a password. The issue is not that we can't create a secure password with what is left, which we can, but you just told anyone trying to crack the system that they can ignore a very large set of possible passwords from their attempts greatly reducing the time it could take to crack the security used. Rainbow tables could be made smaller and faster to search, algorithms can spin through exponentially fewer combinations, etc."

    Which is why you add more characters to regain the lost entropy. Of course if they also limit you to 8 characters or something stupid like that, then yeah they are limiting the effectiveness of the security measures.

    It's possible that the 'sanitization' is more to deal with a crappy web server than SQL injection.

  • foxyshadis (unregistered)

    The largest problem with limiting characters: Having to customize your password manager's outputs depending on if the site explicitly denies certain characters, if it REQUIRES one of each, has a stupid minimum or maximum, etc. At best, you have to keep re-rolling until you get something that fits its stupid requirements, at worst, you have to set up a custom profile for it.

    I LIEK SQUIREL

  • foxyshadis (unregistered)

    As for keys to the kingdom, it's IPMI, which is remote physical console access, power on/off button, and serial interface. Kinda something you want to keep secured over the wire.

  • GWO (unregistered)

    Wow, Kattman : Patronising and* wrong. That's a winning combination.

    See also: what Dan said. If the password length is not constrained, its really easy to regain any lost entropy - you just make the password longer A 20 character password using just [a-z] has more entropy than 8 characters of arbitrary ASCII.

    Clue: Rainbow tables can use punctuation too.

  • Anonamoose (unregistered) in reply to KattMan

    "GWO, it sounds like you are really not aware of the implications for disallowing any subset of characters in a password. The issue is not that we can't create a secure password with what is left, which we can, but you just told anyone trying to crack the system that they can ignore a very large set of possible passwords from their attempts greatly reducing the time it could take to crack the security used. Rainbow tables could be made smaller and faster to search, algorithms can spin through exponentially fewer combinations, etc."

    The password in the screenshot is 10 characters long. There are about 16x10^18 combinations of 10-character passwords using a set of 83 characters (52 upper and lower case, 10 digits, 21 "special" characters). There are about 52x10^18 combinations of 11-character passwords using a set of 62 characters (without the "special" characters). So all you have to do is add one more character to the password to make it at least as strong--in fact it's more than 3 times as strong.

  • skeletor (unregistered)

    Of course "TEXAS" is special, too.

  • (nodebb) in reply to Anonamoose

    And throughout all this no-one has mentioned the "password" field in the screenshot immediately above.

  • guest (unregistered)

    I count 12 Saskatchewan places. Regina and S6V 1B7 are in Saskatchewan too (city and postal code). Also what is RY short for? My question is why can you change your address outside Saskatchewan? If I live in the province and my borrowing rights are restricted based on my address, why would anyone be able to live outside the province and have a card at all?

  • (nodebb) in reply to guest

    RY: I get "Rouyn" in Quebec, if that helps...

  • (nodebb)

    Are the features in those Seagate drives squirrel-based?

  • (nodebb)

    Good thing is that the Test SKU only needs 1 credits!

  • Vendan (unregistered) in reply to Anonamoose

    Of course, it's IPMI, and you'd deserve to be shot for leaving it enabled. The damn protocol itself requires a hash disclosure to function, and includes an "optional" (but usually enabled by default "oh, ignore authentication completely" cipher zero flaw.

  • Axel (unregistered)

    A 10-character password isn't going to be very secure, with or without special characters.

Leave a comment on “Saskatche-what's-it?”

Log In or post as a guest

Replying to comment #463915:

« Return to Article