Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
Okay.. The broken glass on the floor under the window in in the web- and dnsserverroom hosting his site wasn't an ordinary accident, I should have cleaned it up.
Jokes aside, the method simply loses its effectibility when exposed to the public.
Furthermore when exposed, software authors have 0-days to plan and advise any mitigation against its exploitation.
However you could say it makes 'the internet' safer.
Sorry, but (personally) effectibility outweighs the others.
The password is encrypted with salt. I don't know how you can say its not.
The password was also used special characters and a length of 32.
I guess you must have a really good computer that can crack the password so fast and also a lot of proxies to bruteforce on my site. Which will block an ip that tries too many times.
1. I did not mention anything related to password cracking, especially I haven't said the password isn't encrypted with a salt. (What makes you think I said this?!)
2. I was talking about a dictionary attack; a long list of cookie names which are set during the attack, such that if a successful login depends on the presence of a cookie, then this attack might exploit that. What I have been saying for days now is that 'LoginCookie' is a plausible name for a cookie that is set when logged in, and therefore surely must be on the list.
You are still trying to ignore how you got the cookie. So I don't see a reason to give you any gems.
Yes I am. Keeping that method secret is worth more than any amount of money to me. But let's face it:
A: I exploited your login obviously by setting that cookie.
B: I found numerous security issues;
Some serious (exploitable) issues you are facing;
- Cookies are client-side and should not be used for authentication nor authorization.
- Passwords are not encrypted (preferably with a salt to prevent cracking by rainbow tables) and go insecurely over the wire.
^ Note that I didn't say that the passwords aren't salted, I said you havent got HTTPS.
Now from
220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.
or written as a proposition; "Exploit my login or find any security issues -> you will receive 220 gems"
and the truth of A and B, I deduce that I will receive 220 gems.
Anyone (hummerz5?) to back me up here or am I the only rational thinker?
Dictionary attacks usually are the last (and most time-consuming) resort, which is why I stumbled upon another method (One that does not present a threat) first.
The point is that I exploited his login and found at least one security issue, hence I satisfy his condition (Its logically inconsistent if I did not..):
220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.
Last but not least I provided details on how to fix these issues.
Finding a cookie is rather easy when either already created and not expired (The cookie is then stored and visible) or visible in client-side code (Javascript most often).
Capasha wonders how I retrieved the cookiename because neither of both situations was satisfied; The cookie would only be created if logged in successfully and was not visible in client-, but only in server-side (PHP) code.
Capasha, keep your gems if you do not think that 'LoginCookie' is a plausible name present in a dictionary used to set lots of cookies.
In comparison, it's like using 'Password123' while sure that no one would guess that; dumb.
Just a reminder for Capasha that I qualify for
220 gems code to Everybody Edits. To the one that can exploit my login, or find any security issues.
Although I have been waiting eagerly (Do not mistake me for a moneygrubber though), I have not yet received 220 gems (PM me for my ingame name).
Cheers.
I would like to emphasize
For the sake of an answer; I could have bruteforced the name, creating and testing plausible cookie names until by trial and error I stumbled upon 'LoginCookie'.
and the fact that 'LoginCookie' is a plausible name.
Therefore a dictionary attack (creating legio of cookie names, including 'LoginCookie') will work and - when narrowed down - yield the cookie name.
Do not bother about it anymore.
First of all, to secretly send account credentials between client and server, it is necessary to enforce the use of HTTPS in the URL (simply redirect traffic from HTTP to HTTPS).
HTTP traffic will then be encapsulated inside an SSL layer.
For this SSL connection, a handshake is required in which keys are exchanged for asymmetric encryption (to avoid the key distribution problem).
You simpy need to get a private key as well as a certificate signed by a trusted CA with your public key.
https://letsencrypt.org/ offers all these requirements for free (be cautious when selecting a trusted CA, especially when you trust no1).
Secondly, how I discovered the name of the cookie is irrelevant (I purposely keep you in the dark about it); It is a good practice to assume that client- and server-side code is transparent to anyone.
For the sake of an answer; I could have bruteforced the name, creating and testing plausible cookie names until by trial and error I stumbled upon 'LoginCookie'.
Finally, PHP sessions are popular for login systems but as AlphaJon mentioned, they are just cookies, and just like cookies can be hijacked, now suddenly the session can be hijacked too.
Note that counteracting session hijacking by binding each session to an IP only works on network scale; hosts within a network can still hijack eachothers sessions, but I guess that's a job for the network administrator.
Good luck, don't hesitate to ask more.
Asset: Login Authentication and authorization.
Threat: Any method to impersonate an existing user (the usual bruteforcing- and dictionary attack, infamous SQLi) or circumvent authentication.
Attack vector: HTTP interaction obviously.
Vulnerability:
Some conditionals of what may happen and how to better avoid it;
+ Server-side sanitization.
- If sanitization fails, SQL code can be injected.
= Use of prepared statements (PDO) is recommended.
- If PHP code becomes transparent (access to .git folder, Apache down-time), so will the MySQL account credentials.
- If the MySQl account credentials are transparent, then at best only via localhost can be connected to the database and no harm is inflicted,
worse the MySQL database is compromised and at worst, the MySQL password is re-used for FTP/SSH.
= Store account credentials outside of the Apache webroot directory (Preferably in an XML file inside /etc/ with only sufficient file permissions).
Some serious (exploitable) issues you are facing;
- Cookies are client-side and should not be used for authentication nor authorization.
- Passwords are not encrypted (preferably with a salt to prevent cracking by rainbow tables) and go insecurely over the wire.
Exploit:
- Use any addon to create a new cookie called 'LoginCookie', which is checked for during authentication and authorization.
Proof of concept: imgur.com/6KhNu3M
- Put NIC in promisc. mode to capture network packets and subsequently account credentials in POST superglobal variable (Wireshark).
Proposed fix:
- Just do not use cookies (and any other client-side mechanism) for authentication and authorization.
- SSL layer (HTTPS) and cert from CA to not leak passwords over the network.
- Use password_hash()/1 and password_verify()/2 PHP functions to not leak passwords when the database is hacked.
Pages: 1
[ Started around 1732494714.3993 - Generated in 2.401 seconds, 19 queries executed - Memory usage: 1.37 MiB (Peak: 1.51 MiB) ]