A first hello, and a thing or two about Machines™

[Triple Zero]

we need to make this forum https by the way...

why?

i'm curious because security involves a *littlebit* more than "let's slap https onto it and call it secure".

so please tell me, what advantages would the https protocol offer on a public forum?

[Cain]

I'm curious too.

I mean, I'm only really starting to look into this, but what practical benefits would that offer this forum which are not already offered by SMF's own coding?  I remember Jeff doing that to the Totse website, but we still fucked with the forum exploits all day long...

[Triple Zero]

ok, i got one

now technically, the logon procedure for SMF is pretty solid, using sha2 hashes with session-generated salt done client-side in javascript.

BUT!

what if someone manages to spoof the server (using reverse anti anti DNS pinning or whatnot), so that somebody things that he's at pd.com but actually gets served a different page which snatches the password and sends it to the hacker, then hashes it and continues to the real pd.com like nothing ever happened.

ahaah! because if we'd only used https, this could have never happened! :-P

at least, i think it couldnt.

unless of course the user doesn't notice that PD.com is suddenly not served from a https but from http. or that the certificate is different. but at least we can rest assured that peregrineBF most probably would notice and wouldn't be fooled.

[Cain]

Hmmm....

[Requia ☣]

The one thing I can thing of (which may be moot, I'm at work at the moment and can't see the page source), is that https would prevent an eavesdropper from knowing who is who with any real ease.  (It might still be possible to peice it together based on time of packets sent and the resulting changes to the page).

[Triple Zero]

what do you mean, "knowing who is who" ?

IPs are logged, and since people don't go around and using eachother's accounts we usually have a fairly good idea of who is who?

[Bebek Sincap Ratatosk]

ok, i got one

now technically, the logon procedure for SMF is pretty solid, using sha2 hashes with session-generated salt done client-side in javascript.

BUT!

what if someone manages to spoof the server (using reverse anti anti DNS pinning or whatnot), so that somebody things that he's at pd.com but actually gets served a different page which snatches the password and sends it to the hacker, then hashes it and continues to the real pd.com like nothing ever happened.

ahaah! because if we'd only used https, this could have never happened! :-P

at least, i think it couldnt.

unless of course the user doesn't notice that PD.com is suddenly not served from a https but from http. or that the certificate is different. but at least we can rest assured that peregrineBF most probably would notice and wouldn't be fooled.

Th threat exists, but its pretty small... DNS poisoning isn't all that easy assuming that the provider is patched to a current version, but in theory it could happen. I dunno if its worth a SSL connection, but one wouldn't hurt more than someone's pocketbook.

[Requia ☣]

what do you mean, "knowing who is who" ?

IPs are logged, and since people don't go around and using eachother's accounts we usually have a fairly good idea of who is who?

I meant for an eavesdropper (IE, the FBI, CIA, freemasons or whoever you think would bother), to be able to tell who is who.  Not for the administrators to do the same.

[Triple Zero]

Rat: i was being uhh sarcastic i think, or hyperbolical, or what you wanna call it. also i think DNS Poisoning is something different than (anti anti anti) DNS Pinning, but i'm no expert on either.

Requiem: they can do so anyway, and https wouldn't solve that anyway, because it's easy enough to correlate a connection and a post, if you got resources like that.

IMO, https is only valuable if you got some medium-powered criminals that are interested in some valuable data.

[Requia ☣]

I know, I only meant it would make it harder.  (IE, not obtainable by somebody who has yet to evolve beyond script kiddie).