Hash and Post the login and password on login

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Maybe I am overlooking something, but how do you imagine that? I always thought that the idea of password hashing is the following: you store password hash in the database, user sends his password in text to server and server calculates the hash from this password and checks whether it´s the same as in the database. That should protect user accounts when somebody can read from database, because he can only see hashes which are useless to him (unless he uses some brute-force to get the original text from them).
      If you do this, you remove this protection. For me much better option would be to use HTTPS, but that would cost some money.
      For now I think you should just double think before you login :rolleyes:
      BTW: I haven´t examined it deeper, but in login form method is set to POST.

      EDIT: Sorry for a little chaotic explanation, it was in the morning :rolleyes: Here is what I meant:
      This suggestion doesn´t improve acc security in any way. The attacker still knows what data he should send in order to login, so he is still able to login to you acc, the only "improvement" is that now he doesn´t know your real password which you might be using on other sites as well.

    • 1/ the login is launched by post on the main login page, but after that the login page is redirected to the universe login2 page, and the information are forwarded by Query String.

      2/ if you can retrieve the hash code... what can you do with that ?
      > you can't login, because the code will hash again your ... hash value
      > you can't delete planets, because the password is required
      I don't understand your point of view about that

      A lot of websites are a simple way to login with 10 times more security than Ogame :
      > you open the login page > a token is created.
      > you send your informations > POST & hash > redirection if OK

      If you try to redirect without the form (because you have found the hash value) > you have not a valide token.
      If you try to login with the hash value > you are not recognized.


      PS : in the database, the passwords are not stored in hash value... If yes, you couldn't receive it back on password mail request...

    • 1) As I said I haven´t examined it deeply.
      2) Thats true - but if you want to secure login, you would have to secure this too ,right? (Altough these options are much less used, but I think you can´t build a security system on some maybe things)
      POST & hash >
      Ok now I think I know what you mean, you mean to hash it when redirecting between individual pages of login process, right?
      Well, I think GF doesn´t send text passwords between these pages just for fun ^^ It might be possible to do this, but I am not sure whether it could make any difference.
      Tell me how do you think someone can capture this text password when redirecting, only by capturing your packets or by examining server access logs(As far as I know GET is logged).
      In the first case the attacker can capture your password and token right on the login page. In the second case the attacker is very likely to have access to server and he can do much more damage then deleting a few planets on one account.

      As for PS: You must have gone crazy. Storing plain text passwords in database? :crazy: If you request NEW!! password the new one is generated, hashed and stored in the database. At least that is the common practice.

    • No, at this moment there are several possibilities :
      > access to your history (yes... if the stored password of firefox are a little bit securised > access to your computer account required... it's not the case of your history. "Only" an access of your history file is required, and its written in plain text in it... Due to the URI method)
      > access to the history of your internet trafic (sniffer, or box logs)

      For your remarks :
      > No, they didn't transfer logins for the fun, just because their system works like that. And its a really poor pratice, sorry. Every people a little bit involved on the security practices will say that, I'm not a genious.
      > Yes, if you make a password retrieval, you receive by email your existing password. So, the password in the DB is maybe crypted... But not hashed, for sure.

    • If attacker has direct access to your computer, you can say goodbye to lot more than just your ogame password, you can´t just do anything about this as a website owner.
      access to the history of your internet trafic (sniffer, or box logs)
      As I said, HTTPS would do the job.
      No, they didn't transfer logins for the fun, just because their system works like that. And its a really poor pratice, sorry. Every people a little bit involved on the security practices will say that, I'm not a genious.
      I agree.
      > Yes, if you make a password retrieval, you receive by email your existing password. So, the password in the DB is maybe crypted... But not hashed, for sure.
      Yes but if somebody has an access to your database, he might even have an access to your source codes, so he can decrypt these passwords again. Just to make it clear, because I might have some knowledge gaps on these different names. Passwords are for sure (or they at least should be) stored in database in such form that the original plain text value can´t be obtained from values stored in database, but you can still check whether or not the password entered by user is the same as the correct password.

    • Omar Hawk wrote:

      iguypouf wrote:

      > Yes, if you make a password retrieval, you receive by email your existing password. So, the password in the DB is maybe crypted... But not hashed, for sure.


      That's wrong. You'll get a new one.
      If it is changed, it is a good news. Because on last time I maid it... I received my password by email.

      hynner wrote:

      If attacker has direct access to your computer, you can say goodbye to lot more than just your ogame password, you can´t just do anything about this as a website owner.
      access to the history of your internet trafic (sniffer, or box logs)
      As I said, HTTPS would do the job.
      No, they didn't transfer logins for the fun, just because their system works like that. And its a really poor pratice, sorry. Every people a little bit involved on the security practices will say that, I'm not a genious.
      I agree.
      > Yes, if you make a password retrieval, you receive by email your existing password. So, the password in the DB is maybe crypted... But not hashed, for sure.
      Yes but if somebody has an access to your database, he might even have an access to your source codes, so he can decrypt these passwords again. Just to make it clear, because I might have some knowledge gaps on these different names. Passwords are for sure (or they at least should be) stored in database in such form that the original plain text value can´t be obtained from values stored in database, but you can still check whether or not the password entered by user is the same as the correct password.
      Yes, I know the difference between the hash and cryptage, I explained that above in the topic ;)
      I know that last time I requested my password, I receive it in plain text, so, AT THIS MOMENT, the password were not hashed in the database.

      If its changed, its OK.

      However, this is not an argument against the possibility to avoid to carry passwords through URL.


      EDIT : I checked my emails; my last "forget password" was on January... 2010.



      De : noreply

      Objet : Mot de passe OGame.fr

      Bonjour Clean Sweet,

      Le joueur avec l'adresse mail [...] s'est fait envoyer le
      mot de passe de votre compte OGame.fr.

      Votre mot de passe est : chaakpolvet

      A bientôt

      L'équipe Ogame.fr.

      No panic, its an unused PW. But 2 years ago MAXIMUM, the passwords were stored in the database, in plain text or in a reversible cryptage, but not hashed.