this is all moot.. random is random. Randomizing and hashing a random hash with a random hash randomizer will only hash the randomized hash until the hash randomizer has randomized the hash out of its randomized hashing.
By simply seeding it with time or microtime, there is no way to go out and guess. Even without seeding, it is random enough
By simply seeding it with time or microtime, there is no way to go out and guess. Even without seeding, it is random enough
The multiple rand()s won't do anything other than take processing time. One random number from the function would be just as effective as 10. by default, mt_rand will use the mt_getrandmax() value if one isn't set, and most systems thats 2147483647. If that's not random enough, there's something wrong really. The chances of someone getting in with this is pretty slim. Of course, you can remove the problem of this by simply renaming your admin folder. Also, the seeding is done automatically, so it's not needed
Well time isn't random so it makes a bad seed. Also according to the php documentation for mt_srand http://php.net/manual/en/function.mt-srand.php it isn't needed after php-4.2.0.Qphoria wrote:mt_srand(time());
$token = mt_rand();
I like the simplification of removing the md5 function over the random number.
seeding to getprocessortickcount (I doubt php has that) would be a better idea, in some languages if you dont manually set the seed, the rng will always start at the same point, thus rand will be predictable. I remember programming in MFC, if you set the seed to 0 or 15 or whatever static number, or dont set it at all, and generate 20 random numbers. then do it again, you will see the same number sequences popup up, totally predictable. I never tested that in php yet, so not sure what would happen there.
A gold star to anyone who can say that while drunk..Qphoria wrote:random is random. Randomizing and hashing a random hash with a random hash randomizer will only hash the randomized hash until the hash randomizer has randomized the hash out of its randomized hashing.
did you actually read this thread? It tells you how to reproduce the issue and how to solve it.nikhil wrote:Hi guys,
Can you please help me how to reproduce the RFI/LFI issue in Opencart v1.4.9.1 ? Its only when I will track the issue i will try to resolve it.
Thanx..
OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter
PLEASE READ: CSRF fix for 1.4.8, 1.4.9, and 1.4.9.1, fixt in 1.4.9.2
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Sorry if its been reported but i just stumbled on this: http://security-geeks.blogspot.ch/2013/ ... -csrf.html
Is the CSRF exploit back?
Is the CSRF exploit back?
oh ok, I was unable to find it listed in the release notes since 1.5.5 > is this something that Opencart is already aware of?
if so is there a reference i could search for?
if so is there a reference i could search for?
i know about this its pretty obvious and this guy isn't clever.
its not worth protecting accounts on the front side because:
1. you would need to trick a customer of a opencart store to visit a web page with the password changing vulnerability in page linked to the store the customer is a member of. Hackers would not know which customers to target because no customer info such as email addresses are available from the front-end side of the store.
2. The victim that the hackers are targeting would have to be logged into the the opencart store that they are targeting.
So you would have to mass mail about 6 billion people in the world and hope one of these people are logged into the store you are targeting too gain access to customer account which would be absolutely pointless since there is nothing to steal.
this is why so called security researchers like Saadat Ullah are scumbags because they never reveal how hard it would be to pull off a hack like this off but also completely pointless.
mean while a people who don't know about programming see this article about a vulnerability and don't have a clue believe this guys bull shit.
its not worth protecting accounts on the front side because:
1. you would need to trick a customer of a opencart store to visit a web page with the password changing vulnerability in page linked to the store the customer is a member of. Hackers would not know which customers to target because no customer info such as email addresses are available from the front-end side of the store.
2. The victim that the hackers are targeting would have to be logged into the the opencart store that they are targeting.
So you would have to mass mail about 6 billion people in the world and hope one of these people are logged into the store you are targeting too gain access to customer account which would be absolutely pointless since there is nothing to steal.
this is why so called security researchers like Saadat Ullah are scumbags because they never reveal how hard it would be to pull off a hack like this off but also completely pointless.
mean while a people who don't know about programming see this article about a vulnerability and don't have a clue believe this guys bull shit.
OpenCart®
Project Owner & Developer.
agree that there's nothing to steal on the customer's account. You can't steal their physical goods, so there's not really a point for the hackers to go for a customer account.
thanks for the info!
Should i open a bug to officially track this and set it to Low? or just leave it?
Should i open a bug to officially track this and set it to Low? or just leave it?
A phisher could send a bulk pre-attack email designed to get the user to log into their account (such as a fake order notice). Once they know a particular email address clicked the account login link they follow up with the CSRF exploit.Daniel wrote:The person that the hackers are targeting would have to be logged into the the opencart store that you are targeting.
Likely? Not very. But "you're safe as long as long as you don't have a big store" isn't a very good selling point for OpenCart.
Edit: Even easier, use a bot to verify your email list using account registration which discloses if an email is registered in the store.
-Ryan
Who is online
Users browsing this forum: No registered users and 4 guests
