I accidentally discovered that I can log into my university's account if I type in my password and add some characters. So if my username is e. g. "abc" and my password is "password", I can log in with "abc"/"password", but also with "abc"/"password121312", "abc"/"password1", "abc"/"passworde" etc. (I did only a few tries, but it worked so far).

Is this somehow unsafe? (I can not imagine why (except maybe that this means that there are other security problems with the network) , but I do not know much about security.) Should I tell my university?

  • 13
    Is it a shell account for a Unix server, and only the first 8 characters matter? Sounds like DES encryption in the passwd file.
    – user15392
    Oct 20, 2017 at 17:00
  • 4
    +1 (or, more precisely DES crypt AKA "descrypt", which uses DES encryption and also other components). Oct 20, 2017 at 17:44
  • 15
    oh, and in general this sounds bad. You should let someone know.
    – hft
    Oct 20, 2017 at 19:49
  • 6
  • 2
    I've just suggested a duplicate, but on the other hand I think this question here has better answers and a more specific title, so maybe it should be the other one that is marked as a duplicate of this one, despite being older. For the moment I have retracted my flag here, but I'm not sure I should really flag the other one. I think I'll leave the decision to the community or to the mods. Oct 21, 2017 at 0:33

2 Answers 2


It could suggest that any password hashing routine being used is either truncating the input (only using the first x characters of the password), or the comparison for correct passwords has been implemented poorly, and is only comparing the first part (this could imply either a block cipher being used to store passwords, or raw passwords being stored).

Neither situation is particularly good.

In the event of truncation, it gives a false sense of security - you might have picked a long random password, but if only they first few characters are actually being used, it isn't anywhere near as secure as you might think it is, and hence could be guessed in a brute force attack more easily. I'd hope this was the more likely explanation.

In the event of a poor comparison routine, this suggests that the developer responsible for the authentication routine was not familiar with secure development practices. By using a partial comparison (e.g SELECT * FROM users WHERE 'username' LIKE '$username%' AND 'password' LIKE '$password%'), it again increases the chances of brute force attacks working, but also suggests that other mistakes may have been made: given the above example, potentially setting a password of a' OR 1=1'-- would give an SQL injection attack. Obviously, this is a slightly contrived example, but not beyond the realms of possibility.

In the case of a block cipher being used, rather than a password hashing algorithm, the length allowed in the database may be insufficient for a long password, once encrypted. Effectively, this is truncation, but of the encrypted data, rather than of the input. The end effect is the same though: providing a long password gives a false sense of security.

  • There is another possibility if the password is stored in a retreivable way in the database, which is that this was implemented as "fat-finger protection," e.g. the comparison is enteredPassword.startsWith(realPassword), which will succeed even if someone accidently hits \ before enter. Oct 20, 2017 at 21:02
  • 1
    My old university rejected some symbols in passwords because (quoting the email verbatim here): "The dis-allowed characters are mostly to prevent cleverly-constructed passwords from causing harm to Unix-based systems. For instance, the backslash, pipe, dollar sign and various quotes can all potentially be used in that fashion if they're fed in simple-minded fashion to system() type calls that execute binaries like 'usermod' etc."
    – Nick T
    Oct 21, 2017 at 0:25
  • 2
    @NickT Why was your old university feeding passwords to system() calls?
    – JAB
    Oct 21, 2017 at 19:36

The most likely reason why this happens is that the system truncates passwords. To check this hypothesis, you could try to change your password to something longer and see what happens: does the system recognize "thisquitelongpassword" as "thisquitelong"? If so, the system definitely truncates passwords. If not, there may be serious issues with input validation, as highlighted by @Matthew.

While password truncation may be necessary to interact with legacy systems - which also truncate usernames, see this answer on Serverfault - in general it should be avoided, as it reduces the "password space", i.e. the number of unique passwords that can be generated.

Attackers can save a lot of resources (time,money) if they know that their target system uses truncated passwords, since they know they don't need to try passwords longer than the truncation length.

While your behavior doesn't seem malicious to me, some organizations are very sensitive about people finding flaws in their systems.

Therefore, you might try to tell your university about this, but don't stress too much your knowledge of possible attacks. Just saying something like "I read this can be sign of a security issue" should be fine. Also, don't state things in an absolute way like "this is completely unreasonable", as there may be reasons for that (for password truncation, not wrong input validation).

Obviously, don't perform too many tests, don't automate the tests, and don't carry out attacks.

  • 18
    How about instead, you report it anonymously and use as many hyperboles and insults as possible. Also leave an anonymous tip with the student newspaper to embarrass them. That should get their attention.
    – Chloe
    Oct 20, 2017 at 20:42
  • 13
    When my school didn't enforce the no smoking policy, and the security didn't take my complaints seriously, I took a photo of four people smoking in front of a No Smoking sign and posted it (blurring out faces obviously) on the university facebook page. That finally got their attention and they started enforcing the rules.
    – Bahrom
    Oct 20, 2017 at 20:51
  • 9
    Many older Unix variants had a password routine which would truncate at 8 chars before hashing. Any password matching the first 8 chars would let you in. This is a serious problem if your super-secure long password just happens to start with a dictionary word, like "password!N0body@CoUlD$Crack!!" would still fall instantly to a simple cracker, because just plain "password" would work too. I worked on a Unix which did that (ATT SVR4) and hit this exact issue... over 20 years ago. :-/
    – JesseM
    Oct 20, 2017 at 21:46
  • 1
    @JesseM That's why I mentioned compatibility with legacy systems. Yes, ideally they should be replaced with newer systems, but any serious organization performs cost/benefit analysis before taking that kind of decision. Is the cost of replacing N servers (and potentially rewriting some code) less than whatever economic metric you're using to quantify risks due to truncated passwords (and maybe other risks)? We don't know. The university should know, although it may get it wrong. That's why you shouldn't write things like "it's completely unreasonable". You just don't have the full picture.
    – A. Darwin
    Oct 21, 2017 at 6:26

You must log in to answer this question.