| Time |
Nick |
Message |
| 00:03 |
|
paramat joined #minetest-dev |
| 00:11 |
|
shadowzone joined #minetest-dev |
| 00:21 |
|
MinerDad joined #minetest-dev |
| 00:22 |
|
Wayward_One joined #minetest-dev |
| 00:23 |
paramat |
hmmmm thanks for the merges. i suggest not bothering with MC's fractal biome system considering the amount of more important work you have. looking at a MC biome map, the edges are nicaly crinkled but i find it a little boring, like a jigsaw puzzle of near-equal sized pieces |
| 00:53 |
paramat |
(unless of course it's for your v8) |
| 00:55 |
|
Selah joined #minetest-dev |
| 01:00 |
|
Selah joined #minetest-dev |
| 01:28 |
|
crazyR joined #minetest-dev |
| 01:42 |
|
Megaf joined #minetest-dev |
| 01:51 |
|
paramat left #minetest-dev |
| 01:58 |
|
shmancelot joined #minetest-dev |
| 02:11 |
hmmmm |
well i was going to implement it anyway as part of the minecraft mapgen |
| 02:11 |
hmmmm |
since we'll have multiple biome systems this should be trivial to do |
| 02:11 |
hmmmm |
to do in a clean manner |
| 02:11 |
|
Zeno` joined #minetest-dev |
| 02:12 |
|
MinerDad joined #minetest-dev |
| 02:28 |
|
paramat joined #minetest-dev |
| 02:28 |
paramat |
thats cool |
| 02:34 |
paramat |
hmmmmm https://forum.minetest.net/viewtopic.php?f=11&t=10888 i wrote a simple mapgen last night, primarily to demonstrate to you how floatlands and lava underworlds can be simply generated in a 3D noise mapgen by manipulating the density gradient only |
| 02:52 |
|
MinerDad joined #minetest-dev |
| 02:54 |
paramat |
next i'll be using a periodic function for grad above ground to create multiple levels |
| 03:10 |
|
MinerDad joined #minetest-dev |
| 03:12 |
|
deltib left #minetest-dev |
| 03:14 |
Zeno` |
https://github.com/minetest/minetest/blob/master/src/mapgen_v7.cpp#L43 |
| 03:14 |
Zeno` |
^^ hmmmm, I don't understand why that's an array |
| 03:15 |
Zeno` |
flagdesc_mapgen_v7[0] is the only thing that (seems to be) ever used |
| 03:19 |
Zeno` |
err... nvm |
| 04:02 |
|
MinerDad joined #minetest-dev |
| 04:11 |
|
deltib joined #minetest-dev |
| 04:37 |
|
paramat left #minetest-dev |
| 04:38 |
|
hmmmm joined #minetest-dev |
| 05:31 |
|
sol_invictus joined #minetest-dev |
| 05:40 |
|
alexxs joined #minetest-dev |
| 06:12 |
hmmmm |
:/ |
| 06:12 |
hmmmm |
i'm gonna need to do real work tomorrow |
| 06:18 |
hmmmm |
anybody familiar enough with irrlicht know if I could use its texture saving/loading capabilities to write arbitrary images to png without having to add a libpng dependency? |
| 06:19 |
|
paramat joined #minetest-dev |
| 06:28 |
kahrl |
hmmmm, sure |
| 06:28 |
kahrl |
see Client::makeScreenshot for an example |
| 06:29 |
hmmmm |
ahh great! |
| 06:30 |
hmmmm |
probably not a good idea on second though since what i'd like to do would require both client and server to be built |
| 06:38 |
|
Hunterz joined #minetest-dev |
| 07:02 |
|
cib0 joined #minetest-dev |
| 07:15 |
paramat |
interesting that the LVM will light-up light sources but does not spread the light of them, not even an ABM using nodeupdate(pos) does, i have to 'remove' it and 'place' it again |
| 07:15 |
hmmmm |
it does spread light sources |
| 07:16 |
hmmmm |
if you're saying that doesn't spread light sources, then the mapgen doesn't, and mapgen lighting is completely broken |
| 07:25 |
|
ImQ009 joined #minetest-dev |
| 07:29 |
paramat |
yes it's weird the code looks okay. sunlight is spread but my underworld lux ore (light = 14) is not. it's been this way since LVM was added |
| 07:35 |
hmmmm |
how does that happen |
| 07:35 |
paramat |
https://cdn.mediacru.sh/4/46BrBS4P1XNy.png also lava light is somewhat spread but not smoothly |
| 07:35 |
hmmmm |
lava is a light source that isn't sunlight and it seems to spread it just fine |
| 07:36 |
hmmmm |
perhaps i should stop liquid flow and see again |
| 07:37 |
paramat |
ah lava liquid update would perhaps be updating the lava light |
| 07:39 |
paramat |
actually that lava light spread i perhaps okay, the sudden light falloff in the image may be due to light level saturation |
| 07:39 |
paramat |
*is |
| 07:40 |
hmmmm |
can confirm |
| 08:00 |
paramat |
the mapgen where this happens ends with: vm:set_data(data) vm:set_lighting({day=0, night=0}) vm:calc_lighting() vm:write_to_map(data) vm:update_liquids() |
| 08:00 |
hmmmm |
thisi s really odd |
| 08:00 |
hmmmm |
i have a different problem at the moment... the light is tinted blue rather than yellow |
| 08:01 |
hmmmm |
that only happens if the light source == LIGHT_SUN if i recall correctly |
| 08:06 |
|
MinerDad joined #minetest-dev |
| 08:09 |
paramat |
^ RealBadAngel might have insight on tinting |
| 08:10 |
hmmmm |
ahh i found an instance of a light source acting like your screenshot |
| 08:11 |
hmmmm |
how much you wanna bet if i change content_ignore to propogate sunlight, it'll work properly |
| 08:14 |
RealBadAngel |
hmmmm, the only code that could make it blue is imho finalColorBlend |
| 08:14 |
hmmmm |
no shit... |
| 08:14 |
RealBadAngel |
in mapblock_mesh and in shaders |
| 08:15 |
paramat |
heh i wouldn't bet against you |
| 08:18 |
paramat |
my affected light sources are mostly well away from ignore nodes |
| 08:35 |
|
paramat left #minetest-dev |
| 08:36 |
|
jluc joined #minetest-dev |
| 08:38 |
hmmmm |
my tests confirm that content ignore not propogating sunlight does not affect this |
| 08:38 |
hmmmm |
funny enough, if content ignore propogated sunlight, minetest would crash |
| 08:38 |
hmmmm |
with calcLightingOld it won't crash, because the block will never finish emerging |
| 08:39 |
hmmmm |
with my optimized calcLighting, the block emerges fine but then crashes because of a stack overflow in Map::spreadLight |
| 08:39 |
hmmmm |
haha |
| 08:39 |
hmmmm |
... :/ |
| 08:43 |
hmmmm |
calcLightingOld has this problem to some extent as well |
| 08:57 |
|
kilbith joined #minetest-dev |
| 09:13 |
|
Krock joined #minetest-dev |
| 10:05 |
|
ImQ009 joined #minetest-dev |
| 10:16 |
|
chchjesus joined #minetest-dev |
| 10:32 |
|
nore joined #minetest-dev |
| 10:36 |
|
chchjesus joined #minetest-dev |
| 10:40 |
|
Taoki[mobile] joined #minetest-dev |
| 10:47 |
|
Taoki[mobile]_1 joined #minetest-dev |
| 11:14 |
|
alexxs joined #minetest-dev |
| 11:21 |
|
Zeno` joined #minetest-dev |
| 11:27 |
Zeno` |
#2037 ... I'm sure there is another issue already like this but I can't find it |
| 11:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/2037 -- World mod configuring is broken |
| 11:33 |
|
alexxss joined #minetest-dev |
| 11:49 |
|
loggingbot_ joined #minetest-dev |
| 11:49 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 11:50 |
sfan5 |
is back. |
| 11:50 |
celeron55 |
wiki and dev |
| 11:50 |
sfan5 |
i always forget about those |
| 11:50 |
celeron55 |
looks like everything is back up now |
| 11:51 |
celeron55 |
seems like an intended reboot of the server |
| 11:51 |
sfan5 |
yup |
| 12:11 |
Zeno` |
why is struct used instead of class in so many places? |
| 12:18 |
Zeno` |
Surely there is a reason. |
| 12:18 |
Zeno` |
celeron55? |
| 12:26 |
Zeno` |
Probably should turn most of them into class if there is no reason |
| 12:26 |
|
alexxs joined #minetest-dev |
| 12:51 |
|
jin_xi joined #minetest-dev |
| 12:52 |
celeron55 |
i never use class in my new code because it's useless |
| 12:53 |
celeron55 |
it could be removed from the language for all i care |
| 13:01 |
Zeno` |
? |
| 13:01 |
Zeno` |
Not sure I understand the reasoning :) |
| 13:06 |
Zeno` |
class is bad because... ? |
| 13:06 |
|
Taoki joined #minetest-dev |
| 13:09 |
celeron55 |
because it's completely redundant |
| 13:09 |
celeron55 |
struct does the same things with saner defaults (it's public by default) |
| 13:10 |
celeron55 |
and when you use only one, you don't get some compilers complaining when you accidentally don't remember which one you used |
| 13:10 |
celeron55 |
and you never have to think which one to use, because you use only one |
| 13:10 |
celeron55 |
everything goes smoother |
| 13:15 |
|
Taoki joined #minetest-dev |
| 13:21 |
Zeno` |
Have you told the C++ committee? |
| 13:22 |
jin_xi |
lol they gonna add structclass or so |
| 13:27 |
celeron55 |
Zeno`: i don't think they would listen to me |
| 13:27 |
celeron55 |
and they have to preserve compatibility anyway |
| 13:39 |
|
chchjesus joined #minetest-dev |
| 13:46 |
|
selat joined #minetest-dev |
| 14:08 |
|
sol_invictus joined #minetest-dev |
| 14:12 |
|
UnknownSentinel joined #minetest-dev |
| 14:22 |
|
chchjesus joined #minetest-dev |
| 14:22 |
|
ImQ009_ joined #minetest-dev |
| 14:34 |
|
est31 joined #minetest-dev |
| 14:36 |
|
sapier joined #minetest-dev |
| 14:36 |
est31 |
Hello, any plans to improve in the login situation? The hashes are still unsalted and password reuse still enables malicious server owners to take over accounts on other servers. |
| 14:37 |
est31 |
and replay vulnerability |
| 14:37 |
sapier |
in order to improve login situation whole server communication or at least the login process needs to be rewritten not sure if there's anyone willing to do that work ;-) |
| 14:38 |
sapier |
it's been discussed multiple times but any single improovement suggested was worthless without encrypted client server communication for that initial phase |
| 14:39 |
est31 |
and then either encrypt anything or nothing, c55 didn't want two connections. I remember a discussion I had some time ago on this channel. |
| 14:39 |
est31 |
but wouldn't call it worthless |
| 14:40 |
sapier |
well I agree to this encrypting everything is way better then only part of it |
| 14:40 |
est31 |
main argument was latency |
| 14:40 |
sapier |
encrypting login/passwd change is just minimum you have to do to get passwords at least somehow secure |
| 14:41 |
sapier |
true yet there are quite fast encryption algorithms |
| 14:41 |
|
ImQ009 joined #minetest-dev |
| 14:41 |
sapier |
and main issue is we'd have issues with package loss |
| 14:41 |
est31 |
no that can be met |
| 14:41 |
est31 |
there is ZRTP |
| 14:42 |
sapier |
never heared about it |
| 14:42 |
est31 |
its made for that purpose: encryption over UDP |
| 14:42 |
est31 |
in fact its TLS over UDP |
| 14:42 |
sfan5 |
isb |
| 14:43 |
sapier |
but according to wikipedia zrtp is only key exchange |
| 14:43 |
est31 |
it doesn't break with package loss, but adds sequence numbers to UDP. The expensive thing on TCP however is package loss. |
| 14:43 |
sfan5 |
why not DTLS then? |
| 14:43 |
sapier |
not encryption |
| 14:43 |
est31 |
sorry DTLS |
| 14:43 |
sapier |
for our packet sizes some cbc encryption would be required but cbc only works if there's no packet loss |
| 14:48 |
sapier |
dtls seems to be interesting |
| 14:48 |
sfan5 |
wasn't cbc insecure? |
| 14:48 |
|
Eivel joined #minetest-dev |
| 14:48 |
sapier |
not if you use it correct |
| 14:49 |
sapier |
but you may not loose any packet for cbc |
| 14:49 |
sapier |
so it's not gonna work for us |
| 14:50 |
est31 |
why is cbc neccessary? |
| 14:50 |
sapier |
usually because it's fast for encrypting streams |
| 14:51 |
sapier |
and to avoid known plaintext attacks ;-) |
| 14:51 |
sapier |
our packets are quite small and contain a quite predictable starting pattern |
| 14:51 |
est31 |
ok because of that. |
| 14:51 |
sapier |
so risk is high someone can use that information to reverse engeneer the key |
| 14:52 |
sfan5 |
who said the whole packet is going to be encrypted? |
| 14:52 |
sapier |
maybe we need to append some random dummy data at the end of the packet |
| 14:53 |
sapier |
well encrypting only part of it will make it even more vulnerable ;-) |
| 14:53 |
sapier |
unless |
| 14:53 |
sapier |
no we can't even encrypt our data as it's usually only a few bytes |
| 14:54 |
sapier |
unless I'm missing something ;-) in this case tell me |
| 14:54 |
est31 |
the fewer bytes we send, the larger the overhead gets |
| 14:56 |
sapier |
hmm dtls doesn't tolerate dpacket loss too |
| 14:57 |
est31 |
yes it does tolerate |
| 14:57 |
|
ImQ009_ joined #minetest-dev |
| 14:57 |
sapier |
it's just doing it's own retransmission handling for what I read. |
| 14:57 |
est31 |
where did you read that? |
| 14:58 |
sapier |
https://tools.ietf.org/html/rfc4347#section-4.2.4 |
| 14:58 |
est31 |
only the initial handshake doesn't like loss |
| 14:59 |
est31 |
s/handshake/buildup/ |
| 15:00 |
sapier |
ok section 2. clarifies this |
| 15:00 |
Zeno` |
sapier, any progress on the font and formspec bugs/issues? |
| 15:00 |
sapier |
which ones? the real bugs or the feature changes that are intended part of the fix? |
| 15:01 |
Zeno` |
Both I guess |
| 15:02 |
sapier |
first part yes there's a bugfix I made vanessaE test, for what I remember it did fix a lot of issues. second one, well the only thing to do there is finetuning the default size. But there's no way to "fix" it for everyones (ab)usage of bugs |
| 15:04 |
|
Krock joined #minetest-dev |
| 15:05 |
Zeno` |
So https://github.com/minetest/minetest/commit/f7f7fec497f83da0d9f6ea2e83796720484033ff can be addressed somehow? |
| 15:05 |
sapier |
what? |
| 15:06 |
sapier |
you just disable the whole font scaling by second part of this? that's quite nonsense ;-P |
| 15:06 |
Zeno` |
I had to #ifdef out the whole function (essentially) |
| 15:06 |
Zeno` |
yeah and without doing that nobody could play the game |
| 15:07 |
sapier |
what you disable is the part of this patch wich makes fonts scale same as formspec itself scales |
| 15:07 |
sapier |
that's basicaly the core part of the font scaling change |
| 15:07 |
Zeno` |
well what I disabled is broken :p |
| 15:07 |
sapier |
no it's not broken it does exactly what it's intended to do |
| 15:08 |
|
hmmmm joined #minetest-dev |
| 15:08 |
sapier |
it's scaling the font |
| 15:08 |
Zeno` |
yes, it is. And not scaling the formspec |
| 15:08 |
sapier |
becaus formspec did already scale! |
| 15:08 |
Zeno` |
and it made 99% of formspecs unusable |
| 15:09 |
sapier |
by now only formspec did scale but fonts didn't |
| 15:09 |
Zeno` |
seriously, look at the bug reports. |
| 15:09 |
sapier |
the patch fixes that bug |
| 15:09 |
sapier |
and yes I know this changes the behaviour |
| 15:09 |
Zeno` |
change is ok, but when a formspec is *not* usable then the behaviour is broken |
| 15:10 |
Zeno` |
every single formspec apart from mainmenu was broken |
| 15:10 |
sapier |
any formspec looking fine on 800x600 is supposed to still work correct |
| 15:10 |
sapier |
if not there's a bug somewhere |
| 15:12 |
sapier |
let me look for the missing patch I sent vanesse |
| 15:12 |
sapier |
for what I know that one fixed a major issue but isn't merged yet |
| 15:17 |
Zeno` |
I tested the patch you sent to VanessaE |
| 15:17 |
Zeno` |
It didn't work :( |
| 15:17 |
sapier |
can you send me that patch? I don't find it right now ;-) |
| 15:17 |
Zeno` |
I'll see if I still have it |
| 15:18 |
sapier |
what exactly doesn't work? changing font size by "font_size" setting will not be supported any longer |
| 15:18 |
sapier |
that setting is only usefull for adjusting size of your custom font to match formspec |
| 15:19 |
Zeno` |
maybe there is something in the logs around about that date? |
| 15:19 |
sapier |
I don't know when I did send it to her, and I'm quite sure it's been in private not here |
| 15:19 |
Zeno` |
I got it from somewhere... looking |
| 15:20 |
sapier |
well let's first try to make sure we're talking about same thing |
| 15:20 |
sapier |
what exactly is what you call to be "wrong"? |
| 15:23 |
Zeno` |
text not fitting, text overlapping, entire formspec unusable |
| 15:23 |
sapier |
screenshots at 800x600 resolution please |
| 15:23 |
Zeno` |
why is there no bug report any more? It was marked as blocker :/ |
| 15:23 |
Zeno` |
stupid github |
| 15:26 |
|
est31_ joined #minetest-dev |
| 15:27 |
est31_ |
(sorry reposting, wrong channel) In my opinion, encryption isn't this important for the password issue, here are two major issues: replay attacks on family members in the wlan, and replay attacks of users of other servers using the hashes from your own server. both can be solved without encryption. |
| 15:27 |
sapier |
suggestions? |
| 15:29 |
Zeno` |
I can't find the issue/bug-report anywhere :/ |
| 15:29 |
Zeno` |
this is very odd |
| 15:29 |
|
leat joined #minetest-dev |
| 15:29 |
est31_ |
sapier: was that directed to me? |
| 15:31 |
|
exio4 joined #minetest-dev |
| 15:32 |
sapier |
yes est31 if you have a good idea how to get this done with less effort I'd be glad to do it that way |
| 15:33 |
Zeno` |
sapier, ok https://github.com/minetest/minetest/issues/1896 |
| 15:33 |
Zeno` |
but I still need to find all the screenshots |
| 15:34 |
Zeno` |
I have a terrible feeling the screenshots are on the forum somewhere :( |
| 15:34 |
sapier |
ahh that's the fix I was talking about, thanks :-) I'm gonna merge it immediatly prior it's lost again |
| 15:35 |
Zeno` |
it doesn't fix all the issues though heheh |
| 15:35 |
Zeno` |
looking for the screenshots |
| 15:35 |
est31_ |
I have ideas, but transition is hard when you require that old clients are interoperable with new servers and other way round. |
| 15:35 |
sapier |
I know it's just fixing the rounding errors |
| 15:38 |
est31_ |
I'd replace the current "hash(pw) is the password" approach with a simple challenge-response protocol, where the server name gets baked into the hashed reply. |
| 15:39 |
est31_ |
I guess forum is a better place for the details? |
| 15:45 |
sfan5 |
also |
| 15:45 |
sfan5 |
est31_: what is a "server name"? |
| 15:46 |
sapier |
est31_ we don't have something as a server name especially as you could even run multiple worlds on same server with just different ports |
| 15:46 |
est31_ |
the "name" entry in http://servers.minetest.net/list |
| 15:47 |
sfan5 |
so if you decide to rename your server nobody can login anymore? |
| 15:47 |
est31_ |
no its sent at login |
| 15:47 |
est31_ |
not at setting the password |
| 15:47 |
sfan5 |
how does that help? |
| 15:48 |
sfan5 |
oh, nvm |
| 15:48 |
sapier |
hmm interesting idea, but you could't join a server entering ip address any longer |
| 15:49 |
sfan5 |
i think est31_ means that the server sends the server name |
| 15:50 |
est31_ |
the server can send the name if you want to retain that feature |
| 15:50 |
est31_ |
otherwise the client gets it from the server list |
| 15:51 |
sfan5 |
hm |
| 15:51 |
sfan5 |
hm |
| 15:51 |
sfan5 |
you can circumvent disallow_empty_password in some way by sending a hash of an empty password |
| 15:51 |
sfan5 |
instead of just no password at all (which is send for backward compat.) |
| 15:52 |
est31_ |
that needs to be thought of |
| 15:52 |
sfan5 |
that would be an interesting password |
| 15:52 |
sfan5 |
because nobody could replicate it without modifying the src |
| 15:52 |
est31_ |
:) |
| 15:53 |
sapier |
and couldn't join with a non modified version too |
| 15:53 |
sfan5 |
actually |
| 15:53 |
sfan5 |
no |
| 15:53 |
sfan5 |
that doesn't work |
| 15:53 |
sfan5 |
the client sends a plaintext password |
| 15:54 |
sapier |
are you sure? thought the hash was sent? |
| 15:54 |
sfan5 |
for this reason you can't do a replay attack with password from auth.txt |
| 15:54 |
sfan5 |
s/password/hash/ |
| 15:54 |
sfan5 |
sapier: yes |
| 15:54 |
|
ImQ009 joined #minetest-dev |
| 15:55 |
sfan5 |
m_password is std::string |
| 15:55 |
sfan5 |
and it's put into the packet using snprintf |
| 15:55 |
Zeno` |
can't do a "replay attack"? What's that mean? |
| 15:55 |
sfan5 |
both of which would be a bad idea for raw hashes |
| 15:55 |
Zeno` |
If I have auth.txt and the person uses the same password on another server I can easily log in as them |
| 15:55 |
sfan5 |
Zeno`: use the hash from auth.txt to login to the same account on another server |
| 15:55 |
sapier |
well we already know our login is about as secure as telnet login |
| 15:55 |
Zeno` |
sfan5, you can |
| 15:56 |
est31_ |
thats the second problem |
| 15:56 |
sfan5 |
ok let me try this |
| 15:56 |
sfan5 |
upQa9QdxCJzB551UjVZlO3CpDV4 |
| 15:57 |
sfan5 |
k, thats base64 |
| 15:57 |
est31_ |
people can still replicate it |
| 15:58 |
sfan5 |
thats actually a hash |
| 15:58 |
Zeno` |
you don't have to replicate it; you just change (in the source code) the hash that is sent to the server |
| 15:58 |
est31_ |
yes and they only replicate the hash |
| 15:58 |
est31_ |
Zeno yes you dont need to pre-image it |
| 15:58 |
sfan5 |
pre-what |
| 15:58 |
sfan5 |
? |
| 15:58 |
est31_ |
pre-image: thats the term |
| 15:59 |
est31_ |
a (mathematical) function always maps a value to its image. |
| 15:59 |
sfan5 |
so you want to collide sha1 |
| 15:59 |
sfan5 |
have fun |
| 15:59 |
est31_ |
if you go the other way, you want to find a pre-image for the image. |
| 15:59 |
sfan5 |
also: why are we using base64 over the wire |
| 15:59 |
est31_ |
thats quite hard for sha1. |
| 16:00 |
sfan5 |
it's not like TCP uses any kind of text encoding |
| 16:00 |
est31_ |
I think the current solution was a hack |
| 16:01 |
est31_ |
there is a certain list of allowed chars for passwords |
| 16:01 |
sfan5 |
and? |
| 16:01 |
est31_ |
and a maximum length |
| 16:01 |
sapier |
sfan5 historical reasons ;-) |
| 16:01 |
est31_ |
^ |
| 16:01 |
sfan5 |
whats so bad about a list of allowed chars and a max length? |
| 16:02 |
sfan5 |
nobody is going to type a 500 char password |
| 16:02 |
sfan5 |
(copy pasting basically doesn't actually work anywhere) |
| 16:02 |
sapier |
nothing but changing the encoding is a no go ;-) |
| 16:02 |
est31_ |
"password" means the older version of the code, which stayed same on server side. |
| 16:02 |
est31_ |
and the old version was "the client sends the password in plain text to the server" |
| 16:03 |
est31_ |
so "password"= hash in this case |
| 16:03 |
est31_ |
:) |
| 16:03 |
sapier |
well I'd prefere to only change the encoding/login mechanism if it's done correct this time ;-) |
| 16:03 |
sapier |
another interim encoding is crap |
| 16:03 |
sfan5 |
ideally minetest would encode it as utf-8 instead of converting it to ascii |
| 16:03 |
sfan5 |
anyway |
| 16:04 |
sfan5 |
est31_: what kind of challenge-response protocol do you want to use? |
| 16:04 |
sapier |
ideal :-) true but we're not living in an ideal world ;-) |
| 16:04 |
sfan5 |
sapier: thats not an argument for not correcting it |
| 16:04 |
sapier |
if you're breaking all exisiting versions it is ;-) |
| 16:05 |
sfan5 |
umm |
| 16:05 |
sfan5 |
you can't even use non-ascii chars is passwords |
| 16:05 |
sapier |
if you can do it without breaking I'm fully with you |
| 16:05 |
est31_ |
my idea would be that the client sends hash(hash(hash(pw||salt)||challenge)||servername) for login, while challenge is sent by the server |
| 16:05 |
sfan5 |
>hash(hash(hash( |
| 16:05 |
sfan5 |
my first thought: ಠ_ಠ|
| 16:05 |
est31_ |
yea :P |
| 16:06 |
est31_ |
its to prevent that challenge contains parts of the servername. |
| 16:06 |
Zeno` |
anyway, the way to do it is to change line 1897 of main.cpp to password="upQa9QdxCJzB551UjVZlO3CpDV4"; |
| 16:06 |
est31_ |
there are other methods |
| 16:06 |
Zeno` |
now, what server and username should I use? |
| 16:06 |
sapier |
still I don't see how you get a servername for games without servername ;-) |
| 16:06 |
est31_ |
but you would only save one "hash(" |
| 16:06 |
sapier |
e.g. local games |
| 16:07 |
est31_ |
the server has to send it before. |
| 16:07 |
sfan5 |
sapier: if minetest had allowed unicode passwords in the past it would be broken anyway because it is wide_to_narrow()'d before writing it to the packet |
| 16:07 |
sfan5 |
Zeno`: username=cat ip=localhost port=30000 |
| 16:07 |
Zeno` |
:P |
| 16:07 |
est31_ |
we can fall back to "localgame" or something like that |
| 16:07 |
|
exio4 joined #minetest-dev |
| 16:07 |
sapier |
wide .. narrow ... I'm getting headache on reading those words ;-) |
| 16:08 |
|
n4x joined #minetest-dev |
| 16:08 |
sapier |
well I sugges you write it down somewhere, keep in mind we need to have a way to keep old clients working |
| 16:09 |
est31_ |
so ideally all pairs old client - new server and new client - old server... |
| 16:09 |
sapier |
if that's not possible I suggest doing it right once and for all. Meaning not experiments but using a prooven challange response mechanism combined with encryption |
| 16:09 |
est31_ |
I'll write a forum post |
| 16:09 |
sfan5 |
est31_: how does the server verify that the hash is correct? |
| 16:10 |
est31_ |
it stores hash(pw||salt) in the db |
| 16:10 |
sfan5 |
sapier: if we plan to add encryption right with this it's not going to happen any soon |
| 16:10 |
sfan5 |
lolwat |
| 16:10 |
sfan5 |
est31_: you do realize that this doesn't solve a single problem |
| 16:10 |
est31_ |
why |
| 16:10 |
sfan5 |
someone could just modify the client to answer with hash(hash(hash_from_the_db||challenge)||servername) |
| 16:11 |
est31_ |
yeah, therefore the client choses the salt |
| 16:11 |
est31_ |
and the client choses it randomly |
| 16:11 |
est31_ |
(at creation) |
| 16:11 |
est31_ |
so, the salt differs for each server, and they cant do anything about it |
| 16:12 |
sfan5 |
um |
| 16:12 |
sfan5 |
so the client needs to store the salt too? |
| 16:12 |
|
shadowzone joined #minetest-dev |
| 16:12 |
est31_ |
no |
| 16:12 |
|
Selah joined #minetest-dev |
| 16:12 |
est31_ |
hash_from_db is kinda secret |
| 16:13 |
est31_ |
so evil servers wont know it |
| 16:13 |
sfan5 |
not really |
| 16:13 |
sfan5 |
hash_from_db is right in auth.txt |
| 16:13 |
sfan5 |
that not what i would define as secret |
| 16:13 |
est31_ |
secret from evil other servers |
| 16:13 |
sapier |
https://github.com/minetest/minetest/pull/1985 I'm gonna merge this in a few minutes |
| 16:13 |
sfan5 |
this would solve some of the problems |
| 16:14 |
sfan5 |
but having the server store hash(a||b) and a is as secure as it is now |
| 16:14 |
sfan5 |
sapier: do you have approval from a dev? |
| 16:15 |
sfan5 |
(right now the server stores hash(user||pw) and user) |
| 16:15 |
hmmmm |
horrible |
| 16:15 |
sapier |
"Ignoring the major flaws with the system, these changes seem good in principle." reads like an agreement |
| 16:15 |
hmmmm |
we should use a zero-knowledge authentication protocol such as SRP |
| 16:15 |
est31_ |
the "kid wiresharks password of its brother from wlan" attack is only partially mitigated |
| 16:15 |
|
exio4 joined #minetest-dev |
| 16:15 |
est31_ |
it still allows active attacks |
| 16:15 |
hmmmm |
what if a trusted minetest server gets compromised |
| 16:16 |
sfan5 |
sapier: this is not written down anywhere, but agreements have always been done on irc |
| 16:16 |
hmmmm |
in fact, without certificates, you don't even have the concept of server trust |
| 16:16 |
est31_ |
that however can only be solved by encryption |
| 16:16 |
sapier |
in this case anyone against merging a patch only affecting android by improving it's startup time by factor 10? |
| 16:16 |
hmmmm |
yes |
| 16:16 |
sfan5 |
lol |
| 16:16 |
hmmmm |
sapier, you don't really need approval anymore |
| 16:17 |
hmmmm |
we were talking about processes here https://forum.minetest.net/viewtopic.php?f=3&t=10849 |
| 16:17 |
sfan5 |
<est31_> the "kid wiresharks password of its brother from wlan" attack is only partially mitigated |
| 16:17 |
sfan5 |
why only partially? |
| 16:17 |
hmmmm |
because they can replay the hash you send |
| 16:17 |
hmmmm |
the protocol is so amatuerish |
| 16:17 |
sfan5 |
the server sends a different challange |
| 16:18 |
hmmmm |
? |
| 16:18 |
sfan5 |
<est31_> my idea would be that the client sends hash(hash(hash(pw||salt)||challenge)||servername) |
| 16:18 |
hmmmm |
the server should send a salt and the client should generate a salt too |
| 16:18 |
hmmmm |
hash(user + hash(pw) + salt + client_token + server_token) |
| 16:19 |
sfan5 |
having all of that decided by the client (pw, salt, challange) or static (servername) would be a bad idea |
| 16:19 |
hmmmm |
client_token() can be a randomly generated string and transmitted along with the auth packet, server_token is the same format and could be sent in the first server->client packet |
| 16:19 |
est31_ |
hmmm: not a good idea |
| 16:19 |
hmmmm |
why |
| 16:19 |
est31_ |
the server needs to know hash(pw) |
| 16:19 |
hmmmm |
it'll store that |
| 16:19 |
est31_ |
yes |
| 16:20 |
hmmmm |
i realize there is a mitm attack on account creation |
| 16:20 |
hmmmm |
this is unavoidable unless we do something like SRP |
| 16:20 |
sfan5 |
you want the server to store hash(password) |
| 16:20 |
sfan5 |
without salting? |
| 16:20 |
hmmmm |
hash(password + salt) i mean |
| 16:20 |
hmmmm |
i wrote hash(pw) + salt |
| 16:20 |
hmmmm |
didn't mean that |
| 16:21 |
sfan5 |
you mean hash(user + hash(pw + salt) + client_token + server_token)? |
| 16:21 |
hmmmm |
yeah |
| 16:21 |
est31_ |
you should still add servername |
| 16:21 |
sfan5 |
why? |
| 16:21 |
hmmmm |
wouldn't that function the same as salt |
| 16:22 |
est31_ |
imagine client logging in to a malicious server that relays login to third server it targets |
| 16:22 |
sfan5 |
who decides the salt? |
| 16:22 |
sfan5 |
is it dynamic? |
| 16:22 |
est31_ |
salt should be decided by client |
| 16:23 |
est31_ |
yes it is dynamic |
| 16:23 |
sapier |
https://github.com/minetest/minetest/pull/1578 anyone against merging this one? (after rebasing and removing the line shadow suggested) |
| 16:24 |
hmmmm |
nah good stuff |
| 16:24 |
Zeno` |
sapier, nope. I would have rebased it myself a few weeks ago but I was lazy ;) |
| 16:24 |
hmmmm |
the problem I have with the client deciding the salt is that it effectively becomes another portion of the password |
| 16:24 |
hmmmm |
does it not? :/ |
| 16:25 |
est31_ |
no the client doesn't need to store it |
| 16:25 |
est31_ |
and the user doesnt need to remember |
| 16:25 |
hmmmm |
true but |
| 16:25 |
hmmmm |
why doesn't the server generate the salt |
| 16:26 |
est31_ |
because otherwise that attack still works: client logging in to a malicious server that relays login to third server it targets |
| 16:26 |
sfan5 |
sapier: can you remove the lines that store the wgettext output just to make 1 function call? |
| 16:26 |
sfan5 |
hmmmm: the server could generate an empty salt |
| 16:26 |
|
MinerDad joined #minetest-dev |
| 16:26 |
hmmmm |
the client could too |
| 16:26 |
sfan5 |
solution: client & server both generate part of salt |
| 16:26 |
est31_ |
its never in the interest of the client |
| 16:26 |
hmmmm |
erm wait a minute |
| 16:26 |
sfan5 |
wait |
| 16:26 |
sapier |
what exactly do you mean? |
| 16:26 |
sfan5 |
that doesn't help |
| 16:27 |
sfan5 |
with some of the problems |
| 16:27 |
hmmmm |
the client needs to generate the salt otherwise it'd have to send the plain password hash over the wire |
| 16:27 |
sapier |
for what I know we need to do this in order to prevent memory leaks |
| 16:27 |
est31_ |
hmmm: thats another problem |
| 16:27 |
est31_ |
but true also |
| 16:27 |
sfan5 |
sapier: then you added new memory leaks |
| 16:27 |
sfan5 |
hmmmm: why? |
| 16:27 |
|
Calinou joined #minetest-dev |
| 16:28 |
hmmmm |
right |
| 16:28 |
sapier |
sfan5 what exactly are you talking about? ;-) |
| 16:28 |
hmmmm |
that way you could aggravate rainbow table attacks |
| 16:28 |
est31_ |
^ |
| 16:28 |
hmmmm |
but you're still just as vulnerable if somebody mitms your connection on account creation |
| 16:28 |
sfan5 |
sapier: you say https://github.com/minetest/minetest/pull/1578/files#diff-18513665750ef5adf42b5ec29e14162eR1190 (and the next line) is needed to prevent mem leaks |
| 16:28 |
sfan5 |
sapier: but you do it differently here: https://github.com/minetest/minetest/pull/1578/files#diff-34f48ad91ac6c202ac60b0348ae90e30R2662 |
| 16:29 |
Zeno` |
I think MITM is the least concern |
| 16:29 |
hmmmm |
guys, if we include libgmp we can implement SRP which is much better |
| 16:29 |
est31_ |
agree to Zeno |
| 16:29 |
Calinou |
does it work on Windows and OS X? |
| 16:29 |
hmmmm |
right now, having to send basically the password over the wire at any time is bad stuff |
| 16:29 |
hmmmm |
alternatively we can implement encryption |
| 16:29 |
sfan5 |
Calinou: no, libgmp only works on stallmann-approved systems |
| 16:29 |
sfan5 |
Calinou pls |
| 16:29 |
hmmmm |
BS |
| 16:30 |
sapier |
grrr thanks to the one adding the "showOverlayMessage" function especally as that name is quite non telling ... my names are bad I know but at least they tell what a function does |
| 16:30 |
hmmmm |
it's distributed under LGPL v3 |
| 16:30 |
Calinou |
heh |
| 16:30 |
Zeno` |
sapier, I did that I think |
| 16:30 |
hmmmm |
soo guys |
| 16:30 |
hmmmm |
what is it |
| 16:30 |
hmmmm |
encrypted authentication, or passwordless protocol |
| 16:30 |
sfan5 |
who decides the salt now? |
| 16:31 |
Zeno` |
sapier, at least it's an actual function now :P |
| 16:31 |
sapier |
Zeno a little bit more telling function names next time please ;-) |
| 16:31 |
hmmmm |
or a slightly stronger password scheme |
| 16:31 |
Zeno` |
sapier, in hindsight I agree |
| 16:31 |
sapier |
zeno yes having a function is a good thing indeed ;-) |
| 16:31 |
Calinou |
we could have a “remember passwordâ€Â setting, that'd incitate people to use stronger passwords |
| 16:32 |
|
MinerDad joined #minetest-dev |
| 16:32 |
sfan5 |
not really |
| 16:32 |
Calinou |
(should be per-server, to not incitate people to use the same password on all servers) |
| 16:32 |
sfan5 |
have you seen any person that uses stronger passwords just because their browser remembers them? |
| 16:32 |
hmmmm |
or we could not use passwords |
| 16:32 |
hmmmm |
certificates are better |
| 16:32 |
est31_ |
sfan5 when I look into the mirror |
| 16:33 |
hmmmm |
how often do people play minetest on other computers from the same account, seriously |
| 16:33 |
Calinou |
are certificates portable? |
| 16:33 |
Calinou |
people may play on one server using several PCs |
| 16:33 |
hmmmm |
like... platforms? |
| 16:33 |
est31_ |
yes |
| 16:33 |
Calinou |
they maybe don't want to walk around with USB drives |
| 16:33 |
est31_ |
thats the problem |
| 16:33 |
hmmmm |
password auth can be an option |
| 16:33 |
hmmmm |
maybe not the default |
| 16:34 |
est31_ |
mozilla tied basically that with sync |
| 16:34 |
est31_ |
then they realized people didnt like it |
| 16:34 |
hmmmm |
the year is now two thousand and fifteen in the year of our lord |
| 16:34 |
hmmmm |
and you're STILL using password-based auth |
| 16:34 |
est31_ |
then they made everything based on the password |
| 16:34 |
hmmmm |
whdftfuck |
| 16:34 |
hmmmm |
come on guys |
| 16:35 |
est31_ |
I know lots of people I respect (computer literate!) who use password based ssh auth. |
| 16:35 |
Calinou |
Mumble uses certificates since a while now |
| 16:35 |
sfan5 |
hmmmm: explaining users that they need to backup this file is way harder and bound to fail than telling them to remember this string+ |
| 16:35 |
sfan5 |
s/+// |
| 16:35 |
Calinou |
it hasn't been a problem, because certificates are only useful for authentication, which is optional to use it (ie. you can still talk and hear others if you're not authenticated) |
| 16:35 |
sfan5 |
especially since most people don't care to backup anything |
| 16:36 |
est31_ |
you could try to add U2F |
| 16:36 |
hmmmm |
well the whole reason why I bring this up is because that's effectively what you're doing by adding a password management feature and encouraging them to use stronger passwords |
| 16:36 |
est31_ |
U2F rules |
| 16:36 |
sfan5 |
certificates would be the perfect auth. solution |
| 16:36 |
sapier |
well hmmmm eye scans as well as fingerprints have prooven to not work for security critical things |
| 16:36 |
sfan5 |
but it doesn't "scale" well with normal people |
| 16:36 |
Calinou |
I agree, I would be OK with certificates, but probably as an option for now |
| 16:36 |
sfan5 |
(yes, I'm aware scale is the wrong verb) |
| 16:36 |
Calinou |
good for admin accounts |
| 16:36 |
hmmmm |
2FA is nice |
| 16:37 |
hmmmm |
but this is going too deep |
| 16:37 |
sfan5 |
^ |
| 16:37 |
hmmmm |
it's just a god damn video game |
| 16:37 |
est31_ |
u2f can be also used as only factor |
| 16:37 |
Calinou |
it's a video game, but an admin account could do a lot of things potentially |
| 16:37 |
Calinou |
(however, properly configured servers should not let them edit files…) |
| 16:37 |
est31_ |
thats why you should do backups |
| 16:37 |
Calinou |
but a bad server could let them do this |
| 16:38 |
sfan5 |
can we please go back to discussing how we can solve the problem of auth. being horribly insecure and bad? |
| 16:38 |
hmmmm |
the changes I perscribed would work pretty well |
| 16:38 |
est31_ |
ok its SRP vs challenge-response |
| 16:39 |
sfan5 |
est31_: it depends on what challange-response protocol? |
| 16:39 |
hmmmm |
challenge-response would be perfect if the connection were secure |
| 16:39 |
sfan5 |
<Zeno`> I think MITM is the least concern |
| 16:39 |
hmmmm |
do we want to use OpenSSL? |
| 16:39 |
est31_ |
I'd agree to the challenge-response-protocol hmmm suggested if "+" is implemented properly |
| 16:39 |
Megaf |
Hi everyone, wouldn't it be cool using this? https://en.wikipedia.org/wiki/Gobby |
| 16:39 |
hmmmm |
??? |
| 16:40 |
hmmmm |
est31_: concatenation isn't implemented properly? |
| 16:40 |
sfan5 |
the stuff he have come up with until now is insecure if either the server or the client is malicious |
| 16:41 |
est31_ |
ok sorry in this scenario concat even looks safe |
| 16:41 |
hmmmm |
I mean like |
| 16:41 |
hmmmm |
SHA512_Update(password) |
| 16:41 |
est31_ |
if your client is malicious then you are owned anyway |
| 16:41 |
hmmmm |
SHA512_Update(salt) |
| 16:41 |
hmmmm |
SHA512_Final() |
| 16:42 |
est31_ |
yea its safe |
| 16:42 |
sfan5 |
how about hash(username + hash(password + client_salt + server_salt) + client_token + server_token) |
| 16:42 |
sapier |
sfan5 you're right I really added memory leaks in that commit |
| 16:42 |
sapier |
fixing it |
| 16:42 |
hmmmm |
adding a server salt is worthless |
| 16:42 |
sfan5 |
est31_: I'm talking about another client being malicious (right now e.g. sending a hardocded password hash) |
| 16:42 |
sfan5 |
hmmmm: because? |
| 16:42 |
hmmmm |
you'd need to transmit that over the wire before the client creates that primary hash in creating the new account |
| 16:43 |
sfan5 |
hm |
| 16:43 |
sfan5 |
the client using an empty salt is the client's fault and does not hurt anyone |
| 16:43 |
sfan5 |
yep, server_salt is worthless |
| 16:43 |
hmmmm |
the client's salt should probably be randomly generated |
| 16:44 |
est31_ |
sfan5: ah ok for me its covered by "third party server" |
| 16:44 |
sfan5 |
it only hurts the person with the broken client when their salt is not random |
| 16:44 |
est31_ |
^ |
| 16:44 |
hmmmm |
we'll implement a secure random function for the cases where /dev/random isn't available |
| 16:44 |
est31_ |
server salt and client token are worthless in my opinion |
| 16:44 |
hmmmm |
really. |
| 16:44 |
est31_ |
and you need servername |
| 16:44 |
hmmmm |
why |
| 16:45 |
est31_ |
so that the client doesnt have to store the salt |
| 16:45 |
sfan5 |
new proposal: hash(username + hash(password + client_salt) + client_token + server_token); server stores hash(password + client_salt); hash is something secure like sha2-*, or sha3-* |
| 16:45 |
sfan5 |
est31_: why is the client_token worthless? |
| 16:45 |
|
Hunterz joined #minetest-dev |
| 16:46 |
hmmmm |
probably because it doesn't necessarily add any apparent enthropy to the hash |
| 16:46 |
hmmmm |
erm, wrong word choice |
| 16:46 |
est31_ |
hmmm: otherwise a bad server can make a relayed login to a targeted server |
| 16:46 |
sfan5 |
well.. if the server generates an empty token there would be a problem |
| 16:46 |
est31_ |
it only needs to pass on the salt |
| 16:47 |
hmmmm |
oh yeah |
| 16:47 |
hmmmm |
if this were a malicious server you already have the username salting that hash |
| 16:47 |
hmmmm |
so let's say you create the account on the real server |
| 16:48 |
est31_ |
oh havent thought of empty token |
| 16:48 |
hmmmm |
the malicious server comes along and figures it's going to steal your plaintext hash |
| 16:48 |
hmmmm |
erm |
| 16:48 |
hmmmm |
so it creates a non-random servertoken |
| 16:48 |
est31_ |
but the hash always incorporates the length |
| 16:49 |
est31_ |
(when its finalized) |
| 16:49 |
hmmmm |
but because the username is there it'll never be able to extract the hash |
| 16:49 |
hmmmm |
or will it |
| 16:49 |
sfan5 |
without username and client_token it would be hash(hash(password + client_salt)) anyway |
| 16:49 |
hmmmm |
right |
| 16:49 |
sapier |
https://github.com/minetest/minetest/pull/1578 merging the rebased version now |
| 16:49 |
est31_ |
yes |
| 16:50 |
hmmmm |
alright, so client token, server token, username, hash of the salted pw |
| 16:50 |
est31_ |
servername please too |
| 16:50 |
hmmmm |
and then if we add the server name, let's see |
| 16:50 |
sfan5 |
why? |
| 16:50 |
sfan5 |
sapier: don't you need to delete[] text instead of delete textK? |
| 16:50 |
sfan5 |
s/K// |
| 16:51 |
sfan5 |
est31_: the server name does not help with anything |
| 16:51 |
sapier |
hmm compiler doesn't complain but you could be right about it |
| 16:51 |
hmmmm |
est31_: do you mean the server name in place of the client salt? |
| 16:51 |
sfan5 |
hmmmm: i think est31_ menas additionally |
| 16:51 |
sfan5 |
means* |
| 16:51 |
hmmmm |
add it where though |
| 16:51 |
est31_ |
yes additionally |
| 16:51 |
sfan5 |
in the outer hash, probably |
| 16:51 |
hmmmm |
add it to the salted pw hash or to the entire digest |
| 16:51 |
est31_ |
the client salt is stored server side right? |
| 16:51 |
hmmmm |
what will that help with |
| 16:51 |
sfan5 |
est31_: yes |
| 16:52 |
est31_ |
add it to the entire digest |
| 16:52 |
hmmmm |
hrm |
| 16:52 |
sfan5 |
hash(username + hash(password + client_salt) + client_token + server_token + server_name) |
| 16:52 |
sfan5 |
what exactly does this solve? |
| 16:52 |
est31_ |
imagine a malicious server acting as client for a targeted server |
| 16:52 |
sapier |
wtf .. delete[] doesn't cause a compile error ?! :-) |
| 16:52 |
est31_ |
it gets client_salt, server_token |
| 16:52 |
est31_ |
relays it to the real client |
| 16:53 |
Krock |
sfan5, it solves all minetest login problemswhen the server name/IP changes |
| 16:53 |
hmmmm |
so the malicious server MITMs |
| 16:53 |
est31_ |
it relays client_token to the real server |
| 16:53 |
sapier |
other way round :-) |
| 16:53 |
est31_ |
and the hash is also relaye |
| 16:53 |
sfan5 |
est31_: wot |
| 16:53 |
est31_ |
d |
| 16:53 |
sfan5 |
est31_: when Zeno` said MITM was not a concern you said you agreed to him |
| 16:53 |
hmmmm |
wait |
| 16:53 |
sfan5 |
now you are talking about how mitm is problem |
| 16:53 |
est31_ |
MITM without access to the wire |
| 16:53 |
sfan5 |
it's basically the same |
| 16:53 |
est31_ |
the client wants to connect to the malicious server not to the targeted one |
| 16:53 |
hmmmm |
you can still have the same problem if you were to create the account on this compromised server |
| 16:54 |
est31_ |
and uses same password ;) |
| 16:54 |
sfan5 |
right |
| 16:54 |
hmmmm |
also this can be bypassed by compromising the DNS |
| 16:54 |
hmmmm |
this is totally screwed, just use srp |
| 16:54 |
sfan5 |
this is completely insecure |
| 16:55 |
Krock |
sapier, why do you delete text 3 times? https://github.com/sapier/minetest/commit/44082f8#diff-34f48ad91ac6c202ac60b0348ae90e30R2726 |
| 16:55 |
est31_ |
hmmmm that (DNS) was what zeno meant I guess |
| 16:55 |
sfan5 |
est31_: 1) what prevent the malicious server from using a different server_name? 2) it doesn't matter anyway when the malicious server can get hash(password + client_salt) |
| 16:55 |
sfan5 |
est31_: I'm pretty sure Zeno` meant real MITM |
| 16:55 |
Krock |
oh nvm. it's a pointer |
| 16:55 |
sfan5 |
not DNs hijacking |
| 16:55 |
est31_ |
dns hijack is real MITM |
| 16:55 |
sfan5 |
no |
| 16:56 |
sfan5 |
dns hijacking is intransparent mitm |
| 16:56 |
sfan5 |
on-the-wire mitm is transparent |
| 16:56 |
hmmmm |
so i don't get it |
| 16:56 |
est31_ |
1) the user sees server_name in the GUI 2) it doesnt get it because client_salt is randomly chosen |
| 16:56 |
hmmmm |
are you saying that minetest servers can't have different IPs? |
| 16:56 |
sapier |
dynamic dns? |
| 16:56 |
est31_ |
server_name is not its url |
| 16:57 |
est31_ |
its e.g. "VanessaE creative server" |
| 16:57 |
Krock |
you can change the server_name on the servers minetest.conf .. |
| 16:57 |
sfan5 |
est31_: 2) oh, right 1) we can have 2 servers with the same name on the server list |
| 16:58 |
sfan5 |
inb4 this is problem with the server lsit |
| 16:58 |
sfan5 |
list* |
| 16:58 |
est31_ |
1) yes then there is a problem. then the only way to solve this is to require PKI or server side passwords for the list so that the names are unique |
| 16:59 |
sfan5 |
challange-response only solves auth. it doesn't solve any kind of mitm |
| 16:59 |
est31_ |
yes. only encryption does that |
| 16:59 |
sfan5 |
incorrect |
| 16:59 |
sfan5 |
only encryption with auth. does that |
| 16:59 |
est31_ |
? |
| 16:59 |
hmmmm |
zero-knowledge verification solves mitm :) |
| 17:00 |
sfan5 |
blindly encrypting stuff doesn't solve this |
| 17:00 |
hmmmm |
and yea encryption is worthless without knowing who you're sending encrypted stuff to |
| 17:00 |
hmmmm |
exchanging keys with rather |
| 17:00 |
est31_ |
^ |
| 17:00 |
hmmmm |
so who wants to pony up the $100 for a VeriSign certificate for each minetest server |
| 17:01 |
Zeno` |
I meant MITM without access to the wire (for the record) ;) |
| 17:01 |
hmmmm |
nobody? |
| 17:01 |
hmmmm |
I see my case for SRP has been made |
| 17:01 |
sfan5 |
who said we want to solve mitm? |
| 17:01 |
hmmmm |
because it's horribly insecure if you don't solve mitm |
| 17:01 |
* est31_ |
doesn't know SRP good enough to make suggestions |
| 17:02 |
Zeno` |
sfan5, not me. I don't think it should be a major concern right now. |
| 17:02 |
Zeno` |
because ANYTHING is better than what is present right now ;) |
| 17:02 |
sfan5 |
hmmmm: this? http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol |
| 17:02 |
est31_ |
Zeno`, right |
| 17:02 |
sfan5 |
Zeno`: correct |
| 17:02 |
hmmmm |
sfan5, yea |
| 17:03 |
sfan5 |
the challange-response protocol we "drafted" solves the passive replay case |
| 17:04 |
est31_ |
challenge-response solves all replay, as the server_token changes |
| 17:04 |
sapier |
Zeno implementing a incompatible broken mechanism we'd have to change again would be worse then present |
| 17:04 |
est31_ |
incompatible?? |
| 17:04 |
sapier |
breaking old clients but not getting a more secure login |
| 17:04 |
Calinou |
<+hmmmm> so who wants to pony up the $100 for a VeriSign certificate for each minetest server |
| 17:05 |
est31_ |
ah |
| 17:05 |
Calinou |
we can use our own certificates? |
| 17:05 |
sfan5 |
sapier: it's not incompatible |
| 17:05 |
est31_ |
Calinou, yes |
| 17:05 |
Calinou |
which will be approved by the game |
| 17:05 |
sapier |
I was answering to "ANYTHING is better" ... which ain't true ;-) |
| 17:07 |
est31_ |
we can use SRP, but we shouldn't naively implement it |
| 17:07 |
est31_ |
so for example, server_name needs to be included |
| 17:08 |
Zeno` |
sapier, all I was suggesting is that MITM is probably the least concern to worry about |
| 17:09 |
Zeno` |
heck, most https:// sites are open to MITM (not saying it's good) |
| 17:09 |
est31_ |
MITM without access to the wire is easy as I've said |
| 17:09 |
Calinou |
MITM is rarely used in practice |
| 17:10 |
Calinou |
especially in a game |
| 17:10 |
est31_ |
Zeno` ?? |
| 17:10 |
Zeno` |
est31_, exactly |
| 17:11 |
Zeno` |
est31_, if I am one of the endpoints then MITM is trivial. If I have access to the wire it is trivial. Personally I don't think it should be a major concern |
| 17:11 |
hmmmm |
http://www.propublica.org/documents/item/889134-games |
| 17:11 |
Zeno` |
not for a game like minetest anyway :/ |
| 17:12 |
est31_ |
yes MITM with wire access shouldn't be a major concern |
| 17:12 |
Zeno` |
What I am more concerned about is the "rogue server" |
| 17:13 |
est31_ |
^ |
| 17:13 |
sapier |
why do you guys ignore the most common attack scenario for professionals ? |
| 17:13 |
Zeno` |
e.g. if I wanted to I could look at my server's auth.txt and probably login as most users on most other servers |
| 17:13 |
est31_ |
^ |
| 17:13 |
Zeno` |
sapier, because there is no reason for a professional to try and login as a minetest user? |
| 17:14 |
est31_ |
thats something very heavy, while professionals can find a tiny 0day in irrlicht and we are pwned |
| 17:14 |
sapier |
the most easy way to prevent yout passwords to be abused by an evil server is to use different passwords for each server |
| 17:14 |
Zeno` |
sapier, I do. Most users do not |
| 17:15 |
sapier |
anything we can do failes due to not beeing able to authenticate a server |
| 17:15 |
|
shadowzone joined #minetest-dev |
| 17:15 |
est31_ |
therefore the server_name |
| 17:16 |
est31_ |
the user verifies this themselves |
| 17:16 |
est31_ |
so we are abled |
| 17:16 |
sapier |
and what should stop a evil server from claiming to have that servername? |
| 17:17 |
sapier |
serverlist updates are not authenticated so that evil server could even be distibuted by serverlist |
| 17:17 |
hmmmm |
stop with the half assed approach |
| 17:17 |
Zeno` |
I've never really liked the evil tools... they seem to wear out too fast |
| 17:17 |
hmmmm |
we either do it the right way or no way at all |
| 17:17 |
hmmmm |
this means no challenge based response |
| 17:17 |
sapier |
I'm completly with hmmmm either do it right or don't do it at all |
| 17:17 |
hmmmm |
unless it's encrypted |
| 17:18 |
hmmmm |
and don't bother with encryption unless you have verification |
| 17:18 |
sapier |
so server certificates as well as a minetest cert |
| 17:18 |
sapier |
minetest cert could ensure no server name is used twice thus provide at least a low level of integrity |
| 17:19 |
est31_ |
minetest cert?? |
| 17:19 |
Zeno` |
stop with the DRM! |
| 17:19 |
sapier |
it's not drm |
| 17:19 |
hmmmm |
personally, though, improving security isn't a priority for me. it's been laughably horrible the entire time and very few seem to care, it's never actually been exploited, and ffs it's just a game |
| 17:19 |
Zeno` |
it basically is |
| 17:19 |
sapier |
you can still specify another ca |
| 17:19 |
est31_ |
just make a "server password" where the server authenticates to the list |
| 17:19 |
hmmmm |
all my passwords are some variation of 'asdf' |
| 17:20 |
hmmmm |
or abcd |
| 17:20 |
hmmmm |
nobody takes minetest serious enough to use a real password |
| 17:20 |
sapier |
funny thing hmmmm :-) |
| 17:20 |
|
leat joined #minetest-dev |
| 17:20 |
est31_ |
I've been taken over on Clip public server |
| 17:20 |
sapier |
me too |
| 17:20 |
Krock |
interesting idea, such a "minetest cert" but it requires more wok than it gives an use |
| 17:20 |
sapier |
krock all of this is more of work then use |
| 17:20 |
Calinou |
can a mod set up a password policy? |
| 17:20 |
hmmmm |
right |
| 17:20 |
Calinou |
or should this be done in the engine? |
| 17:20 |
Calinou |
minimal length or such |
| 17:20 |
est31_ |
password policies are worthless |
| 17:21 |
Krock |
passwords should be dome serverside |
| 17:21 |
est31_ |
dont start with things like those |
| 17:21 |
Krock |
*done |
| 17:21 |
sapier |
if you want to go without minetest cert you could make client accept a cert at first login and warn if it's changed |
| 17:21 |
hmmmm |
I can shoot the shit about authentication, and if somebody agrees to add libgmp I could throw in my homegrown tiny, good implementation of srp |
| 17:21 |
sapier |
not sure if users know how to check a cert for the first time |
| 17:21 |
hmmmm |
but I'm not willing to put in more effort beyond that |
| 17:22 |
est31_ |
I agree to srp when the "password" is hash(hash(pw|| salt)|| server_name) |
| 17:22 |
Zeno` |
first a cert for mods and now a cert for servers? |
| 17:22 |
Zeno` |
where will it end? |
| 17:22 |
hmmmm |
Security is our top concern! |
| 17:22 |
Zeno` |
I am very opposed to certs |
| 17:22 |
hmmmm |
haha |
| 17:23 |
Zeno` |
*sigh* |
| 17:23 |
hmmmm |
I do have concern for remote code execution on clients though |
| 17:24 |
Zeno` |
yes, so that should never happen |
| 17:24 |
hmmmm |
right |
| 17:24 |
hmmmm |
there are lots of people running javascript from websites every day |
| 17:24 |
hmmmm |
why should this be any different |
| 17:24 |
sapier |
zeno certificates are the only known mechanism to verify integrity ... but still they're flawed by design |
| 17:24 |
est31_ |
and its non-free!!! |
| 17:24 |
est31_ |
:) |
| 17:25 |
est31_ |
js from websites is sandboxed |
| 17:25 |
hmmmm |
so the lua would be sandboxed too |
| 17:25 |
hmmmm |
client-side lua |
| 17:25 |
est31_ |
yeah, so lets hope the sandbox is good |
| 17:25 |
sapier |
hmmmm browsers used to sandbox that code ... yet current development with full hardware access and cloud storage does render that task quite useless ... what's left to protect if all sensible information is accessible from within sandbox |
| 17:25 |
hmmmm |
the concern is that lua or luajit might be way more vulnerable than your typical js interpreter implementations |
| 17:26 |
hmmmm |
hmm |
| 17:26 |
est31_ |
... because less money has been spent making it secure |
| 17:26 |
est31_ |
the topic was auth |
| 17:26 |
hmmmm |
you shouldn't be able to do anything aside from DoS with gpu access |
| 17:27 |
sapier |
hmmm what about reading framebuffer content to get information not meant for you? |
| 17:27 |
hmmmm |
i thought that was solved with WebGL |
| 17:27 |
sapier |
well until someone finds a bug ;-) |
| 17:27 |
est31_ |
WebGL is one of the best attempts to solve it I guess |
| 17:28 |
est31_ |
idk whether its goot |
| 17:28 |
hmmmm |
it's the best we got |
| 17:28 |
T4im |
if you don't use it though, you are better off deactivating it ;) |
| 17:29 |
hmmmm |
i planned on adding some lower level APIs like client.draw_triangle_strip() |
| 17:29 |
sapier |
true but if best is still broken isn't it better not to use it? ;-) |
| 17:29 |
hmmmm |
client.draw_hud(), client.draw_text(), client.blit_texture_to_screen() |
| 17:29 |
hmmmm |
what else.. |
| 17:29 |
sapier |
well ... I know I'm not telling a majority capable opinion :) |
| 17:29 |
Calinou |
drawing triangles/boxes on HUD could be useful |
| 17:30 |
Krock |
client.disconnect() |
| 17:30 |
est31_ |
"please log in to windows" |
| 17:30 |
hmmmm |
yeah basically |
| 17:30 |
hmmmm |
i'm gonna have to reimplement the entrity of cairo or WinGDI |
| 17:31 |
hmmmm |
if minetest didn't have modding it would be like twice as small as it was right now, and everything would be very well polished |
| 17:31 |
Krock |
everything would be totally boring |
| 17:32 |
est31_ |
^ |
| 17:32 |
|
twoelk joined #minetest-dev |
| 17:32 |
Krock |
except you add 1000 different nodes and items like minetest-classic |
| 17:32 |
Krock |
*voxelands |
| 17:32 |
hmmmm |
yeah |
| 17:32 |
hmmmm |
you know |
| 17:33 |
hmmmm |
minetest seems sub-par to all the other MC-clones |
| 17:33 |
hmmmm |
but in reality that's because most of the development effort is going toward extensibility |
| 17:34 |
|
cib0 joined #minetest-dev |
| 17:34 |
Calinou |
implementing extensibility is always rewarding in the long term |
| 17:34 |
Calinou |
so do it, instead of polishing something that'll die quickly |
| 17:34 |
|
crazyR joined #minetest-dev |
| 17:34 |
hmmmm |
haha check this out https://github.com/minetest/minetest/issues/2037 |
| 17:35 |
hmmmm |
so it appears that people are putting spaces in their mod names |
| 17:36 |
sapier |
:-) |
| 17:36 |
Krock |
trololo |
| 17:36 |
hmmmm |
that's not a bad idea or anything...... naaaaaaaaaaw |
| 17:36 |
hmmmm |
should we disallow special characters in mod names or escape them? |
| 17:36 |
sapier |
isn't a space just a normal character ? ;-) |
| 17:37 |
est31_ |
just like 💩 is |
| 17:38 |
Calinou |
disallow |
| 17:38 |
hmmmm |
ironically you're able to use the latter |
| 17:38 |
Calinou |
mod names are technical anyway |
| 17:38 |
Calinou |
ideally in mod configure, description.txt should be used to show full name |
| 17:38 |
Calinou |
eg. More Blocks [moreblocks] instead of just moreblocks |
| 17:40 |
hmmmm |
anybody else? |
| 17:42 |
Krock |
the idea is good but the [moreblocks] part must be added automatically |
| 17:43 |
sapier |
any change there should be checked against dependency as well as mod enabling disabling code |
| 17:44 |
Calinou |
Krock, yes, it would, like in subgames |
| 17:45 |
est31_ |
spaces are bad, as you can have one or two or many, and there are bad fonts which make spaces very thin |
| 17:55 |
|
MinerDad joined #minetest-dev |
| 17:55 |
|
rubenwardy joined #minetest-dev |
| 17:56 |
|
prozacgod joined #minetest-dev |
| 18:05 |
est31_ |
so what do you think, should server_name be included? |
| 18:08 |
|
DuDraig joined #minetest-dev |
| 18:11 |
est31_ |
I still like it. It doesn't protect from server A claiming to be server B, but when the user wants to log in to server A, they never have to fear that server A in fact relays the login to server B. |
| 18:13 |
sapier |
why not? server a could claim to be server b and still relay communication |
| 18:13 |
sfan5 |
we can't add server_name because there is no standard definition of server_name |
| 18:14 |
sfan5 |
this also breaks connecting to IPs or hostnames |
| 18:14 |
sfan5 |
which is not something we need to discuss |
| 18:14 |
sfan5 |
(we won't remove support for direct connections) |
| 18:17 |
est31_ |
sapier that isn't met, you're right. That I think should be fixed elsewhere, like adding passwords or certs for servers. It is however better than storing the salt, which is vulnerable to typo changes, which can be fixed when the list is maintained by a human |
| 18:18 |
sapier |
sfan5's issues are valid too how do you intend to fix them? |
| 18:18 |
est31_ |
sfan5 no with server_name I don't mean ip or hostname or something like that, but the actual thing displayed in the GUI, like "VanessaE creative server" |
| 18:18 |
sfan5 |
est31_: what if you want to connect to a server that is not on the server list? |
| 18:19 |
sapier |
we don't show lan servers in serverlist |
| 18:19 |
sapier |
as we don't have lan autodiscovery |
| 18:19 |
sfan5 |
so basically we use the old vulnerable process for connecting to on IP or addr. |
| 18:20 |
est31_ |
then you enter ip and port, and get to a dialog "Connect to 'VanessaE creative server'?" and only when you press yes the credentials are sent. We have to send server_name during connection buildup of course |
| 18:20 |
sapier |
you don't get that dialog |
| 18:20 |
sapier |
server doesn't tell it's name to client |
| 18:20 |
est31_ |
it needs to be written |
| 18:20 |
est31_ |
it needs to be made to tell |
| 18:21 |
sapier |
it's a change in login mechanism, most likely incompatible |
| 18:21 |
sfan5 |
est31_: what are you going to do if i connect to a server that is not on the list |
| 18:21 |
sfan5 |
sapier: actually that change is backwards-compatible |
| 18:21 |
sapier |
if you make server send an additional message ? |
| 18:21 |
est31_ |
sapier isn't it already? |
| 18:21 |
est31_ |
sfan5, see above. |
| 18:22 |
sapier |
sfan5 only if we can add it to an existing message |
| 18:22 |
sfan5 |
est31_: server_name is not a required setting |
| 18:22 |
sfan5 |
sapier: TOCLIENT_INIT? |
| 18:22 |
sapier |
could work |
| 18:22 |
sapier |
and how is client supposed to behave if that field is missing? |
| 18:23 |
sapier |
if it just ignores it it's worth nothing, if it failes you couldn't connect to old servers |
| 18:23 |
sfan5 |
sapier: the server name would only be required by the challenge-response auth thing anyway, it could be added to the new packet |
| 18:23 |
sapier |
hmm a warning could be a solution ... ugly |
| 18:23 |
est31_ |
we can assume '' then and the server owner has to live with the problem |
| 18:23 |
sapier |
I thought we did agree on doing it right or not at all? |
| 18:24 |
sapier |
I'm against implementing another home brew broken mechanism |
| 18:24 |
sfan5 |
est31_: the server_name being empty is a potential security problem for all clients, not the server owner |
| 18:24 |
est31_ |
show me how a well-established mechanism handles distrusting the server |
| 18:25 |
sfan5 |
est31_: requiring servers to have a name is stupid |
| 18:25 |
est31_ |
sfan5, yes |
| 18:25 |
sapier |
https with client and server certificate authentication |
| 18:25 |
est31_ |
sfan5, yes |
| 18:26 |
est31_ |
sapier, we had that: its hard to convince people to backup a file |
| 18:26 |
sapier |
your server name is basically just a broken certificate |
| 18:26 |
sfan5 |
sapier: 1) who pays for the server certs? 2) most people don't care enough to backup anything |
| 18:26 |
est31_ |
the server name is human-readable |
| 18:26 |
sapier |
it's worth about nothing as you can't trust it |
| 18:26 |
sfan5 |
sapier: est31_'s idea is that the server name is retrieved from the server list |
| 18:27 |
est31_ |
and the server authenticates to the list via some mechanism |
| 18:27 |
sapier |
sfan5 if client stores a servers certificate it could at least be used to verify to connect to same server again |
| 18:27 |
est31_ |
be it cert or password |
| 18:27 |
sapier |
and our serverlist is more secure? |
| 18:27 |
est31_ |
or nothing |
| 18:27 |
sapier |
everyone can add a fake name |
| 18:28 |
sfan5 |
sapier: correct |
| 18:29 |
sfan5 |
est31_: the problem with the server_name mechanism is that there are servers not on the server list and that server names are not meant to be used for security purposes (not unique, easily spoofable) |
| 18:29 |
sapier |
imho if we want to get better (not perfect) integrity the minimum we'd have to support is self signed certificates with a well tested certificate exchange mechanism |
| 18:30 |
est31_ |
cert exchange isn't the problem here I think, as when you first-time login to a server you usually have nothing, and people start to get interested in you when you have something |
| 18:32 |
sfan5 |
"a well tested certificate exchange mechanism" |
| 18:32 |
sfan5 |
wat |
| 18:32 |
sfan5 |
i think socket.write(ceritficate.serialize("x509")) is well-tested |
| 18:32 |
|
MinerDad joined #minetest-dev |
| 18:32 |
sapier |
nope |
| 18:33 |
sfan5 |
>used by TLS >nope not well tested |
| 18:33 |
sapier |
what I meant is you have to make sure certificates are not modified in transit ... meaning |
| 18:33 |
sapier |
you need an encrypted connection prior exchanging certificates |
| 18:33 |
sfan5 |
what are you trying to solve |
| 18:33 |
sapier |
to make sure the one sending the certificate is the one you connected to |
| 18:34 |
sfan5 |
you absolutely cannot solve mitm without some kind of signature that is verifyable before you connect |
| 18:34 |
sapier |
nope |
| 18:34 |
sapier |
it's a two level connection |
| 18:34 |
sfan5 |
please tell me how |
| 18:34 |
est31_ |
signature or other mechanisms also only create a name<->cert hash mapping |
| 18:34 |
sapier |
first a encrypted connection is established between two hosts |
| 18:34 |
sfan5 |
cut! |
| 18:35 |
sfan5 |
you can mitm at this point |
| 18:35 |
sfan5 |
game over |
| 18:35 |
sfan5 |
try again? |
| 18:35 |
sapier |
nope |
| 18:35 |
sapier |
because right now no identity is verified |
| 18:35 |
sfan5 |
yeah |
| 18:35 |
sfan5 |
this means you can mitm |
| 18:35 |
sapier |
no |
| 18:35 |
sfan5 |
yes |
| 18:35 |
sapier |
you can't because this is only the envelope |
| 18:35 |
sfan5 |
why is mitm not possible? |
| 18:36 |
sapier |
because this connection is between two hosts |
| 18:36 |
sfan5 |
heard of active mitm? |
| 18:36 |
sapier |
you'r not done yet ;-) |
| 18:36 |
sfan5 |
??? |
| 18:37 |
sapier |
uppon this connection certificates are exchanged end to end |
| 18:37 |
sapier |
yoru mitm doesn't have the certificate |
| 18:37 |
sapier |
so at this point it's gonna be detected |
| 18:37 |
est31_ |
at the end we still need some sort of auth for the list |
| 18:37 |
sfan5 |
uh |
| 18:37 |
sfan5 |
I'm talking about MITM not someone redirects your traffic |
| 18:38 |
sapier |
still a mitm doesn't have the remote private key |
| 18:38 |
sfan5 |
correct |
| 18:38 |
sfan5 |
what if the mitm generates his own cert and keys? |
| 18:38 |
sapier |
so no mitm can decrypt that information |
| 18:38 |
sfan5 |
incorrect |
| 18:38 |
sapier |
doesn't help after initial cert exchange |
| 18:38 |
sfan5 |
wat |
| 18:38 |
sfan5 |
what if the mitm generates his own cert and keys? |
| 18:38 |
sfan5 |
(before the cert exchange ofc) |
| 18:39 |
sapier |
well we're talking about different things sfan5 |
| 18:39 |
sfan5 |
what are you talking about then? |
| 18:39 |
sapier |
I'm only talking about a connection once client already knows correct certificate |
| 18:40 |
sfan5 |
it's obvious that already knowing the cert would solve this |
| 18:40 |
sfan5 |
sapier: why do you want to encrypt certificate exchange? |
| 18:41 |
sapier |
to protect that information |
| 18:41 |
sapier |
see ipsec |
| 18:41 |
sfan5 |
why protect the certificates |
| 18:41 |
sfan5 |
TLS doesn't protect them either |
| 18:42 |
sapier |
are you sure about that? ;-) |
| 18:42 |
sfan5 |
very sure |
| 18:43 |
sapier |
even if it's true tls is usually used for webservers which is serving information to public |
| 18:43 |
sapier |
so anyone could connect and get the cert |
| 18:43 |
sfan5 |
<sapier> so anyone could connect and get the cert |
| 18:43 |
sfan5 |
oh, is this not true for minetest servers? |
| 18:43 |
sapier |
hmm ok ok I got it |
| 18:44 |
sapier |
still how do you wanna proove integrity of communication if you send them unencrypted/unsigned |
| 18:45 |
sapier |
at least signing of that data is required |
| 18:45 |
sfan5 |
the certificated are unsigned |
| 18:46 |
sfan5 |
if you do trust-after-first-sight the client just knows that those are the right ones |
| 18:46 |
sfan5 |
<sfan5> the certificated are unsigned -> the certificates are signed by CAs |
| 18:46 |
sfan5 |
sapier: https://cdn.mediacru.sh/8/89SfUIoQQUfz.png << here's a TLS handshake |
| 18:46 |
sapier |
certificates are always signed, at worst self signed |
| 18:47 |
sfan5 |
you know what i mean |
| 18:47 |
sapier |
what I'm talking about is making sure pakets from server are not modified till received by client |
| 18:47 |
sfan5 |
encryption does not help with that |
| 18:47 |
sapier |
partial |
| 18:48 |
sfan5 |
not even partial |
| 18:48 |
sapier |
if you make sure keys to do decryption are only known to sender and receiver noone else can send valid messages |
| 18:48 |
sfan5 |
correct |
| 18:48 |
sapier |
you'd have to add some sort of checksum or signature to detect invalid messages of course |
| 18:48 |
sfan5 |
but you need to exchange the keys over an untrusted communcation channel |
| 18:49 |
sapier |
which is a already solved task ;-) |
| 18:49 |
sfan5 |
yes |
| 18:49 |
sfan5 |
diffie-hellmann can be mitm'd |
| 18:49 |
sfan5 |
any encryption without authenticating the server<->client connection is pointless |
| 18:49 |
sfan5 |
because it can simply be reversed by an active mitm |
| 18:50 |
sapier |
see ipsec ike it's working quite fine |
| 18:50 |
est31_ |
what should the certs be mapped to? |
| 18:50 |
est31_ |
to the url? the "server_name"? |
| 18:50 |
sfan5 |
sapier: IPSec works with certs too |
| 18:50 |
sapier |
certs and diffie hellman |
| 18:50 |
sfan5 |
i don't know if they encrypt the cert exchange |
| 18:50 |
sfan5 |
if they do that is stupud |
| 18:50 |
sapier |
using a two level connection mechanism |
| 18:50 |
sfan5 |
stupid* |
| 18:51 |
sapier |
of course ipsec is stupid because it's used almost everywhere ;-) |
| 18:51 |
sapier |
ppl beeing way more experienced then both of us did design and validate that way of doing encryption sfan5 ;-) |
| 18:51 |
sfan5 |
sapier: can you provide a link to some convincing document that says ipsec encrypts the exchange of certs |
| 18:52 |
Calinou |
encryption without auth is better than nothing |
| 18:52 |
sfan5 |
Calinou: correct |
| 18:52 |
Calinou |
signing is mostly done to make lobbies happy (-: |
| 18:52 |
sfan5 |
Calinou: incorrect |
| 18:52 |
Calinou |
it's a business |
| 18:52 |
sfan5 |
against sophisticated attackers encryption without auth is worthless |
| 18:52 |
est31_ |
Calinou, yes its a business but its existence has a reason |
| 18:52 |
sfan5 |
Calinou: we are not even talking about PKI with CAs |
| 18:53 |
sfan5 |
Calinou: you were not even talking about PKI with CAs, just about authentication |
| 18:53 |
sapier |
sfan5 not right now as I have to leave but I'd point you to ipsec rfc's guess you'll find it till I have time to send it to you |
| 18:53 |
|
sapier left #minetest-dev |
| 18:55 |
sfan5 |
pff |
| 18:56 |
sfan5 |
i think I'm going to do that next time |
| 18:56 |
sfan5 |
1) make a claim |
| 18:56 |
sfan5 |
2) rtfm and prove the opposite or believe me |
| 18:57 |
sfan5 |
also knowing that encryption is pointless without auth against active mitm does not require studying security |
| 18:57 |
est31_ |
can you provide me with some background? a cert consists of more than just a keypair. what do you suggest to be the "name" that it maps to |
| 18:58 |
sfan5 |
est31_: the hostname or ip |
| 18:58 |
sfan5 |
or something else |
| 18:58 |
sfan5 |
it would be easier to just have the server have a keypair |
| 18:58 |
sfan5 |
and the client do trust-on-first-use |
| 18:58 |
est31_ |
and then the client selects the server by clicking the hostname? |
| 18:59 |
est31_ |
(or ip) |
| 18:59 |
sfan5 |
uh no |
| 18:59 |
est31_ |
so they select the server_name? |
| 18:59 |
sfan5 |
no |
| 19:00 |
sfan5 |
we can't add this |
| 19:00 |
sfan5 |
it doesn't work with existing things |
| 19:01 |
rubenwardy |
Why would you need certification and signing? You're not transacting bank details. |
| 19:02 |
Calinou |
rubenwardy, you rarely transact bank details on GitHub or reddit either ;) |
| 19:02 |
rubenwardy |
That's for keeping your code secure |
| 19:02 |
rubenwardy |
and reddit can waste money |
| 19:02 |
rubenwardy |
Also, passwords |
| 19:03 |
Calinou |
passwords are considered less and less secure as time go on; people often choose stupid ones |
| 19:13 |
est31_ |
Calinou, I agree, although "passwords are dead" is quite hyped |
| 19:14 |
est31_ |
and people tend to prefer it the password way |
| 19:14 |
est31_ |
other solutions would be eg to store a key on the computer |
| 19:15 |
est31_ |
but most ppl dont like that |
| 19:15 |
Calinou |
that's basically using self-signed certificates like Mumble does |
| 19:15 |
Calinou |
it starts being a problem when you use several devices |
| 19:15 |
Calinou |
especially mobile ones |
| 19:15 |
est31_ |
^ |
| 19:19 |
est31_ |
I think the project google does with U2F is quite cool as it gives people a solution which is connected to the physical world, giving a "key" experience. |
| 19:19 |
Megaf |
Hi all |
| 19:20 |
Megaf |
any word on my connected glass issue? |
| 19:20 |
Megaf |
^ Calinou |
| 19:26 |
sfan5 |
maybe someone cares, here's mildly-secure-challenge-response-v1.txt: http://sprunge.us/CMdH |
| 19:32 |
|
ImQ009 joined #minetest-dev |
| 19:38 |
|
cib0 joined #minetest-dev |
| 20:03 |
|
ImQ009 joined #minetest-dev |
| 20:12 |
|
casimir joined #minetest-dev |
| 20:21 |
|
roniz joined #minetest-dev |
| 21:24 |
|
UnknownSentinel joined #minetest-dev |
| 21:34 |
|
kaeza joined #minetest-dev |
| 21:39 |
|
cib_ joined #minetest-dev |
| 21:40 |
|
ImQ009 joined #minetest-dev |
| 21:57 |
hmmmm |
ah shoot |
| 21:57 |
hmmmm |
I almost forgot |
| 21:57 |
hmmmm |
laying in bed last night i thought about alternative lighting algorithms.. basically it comes down to two: |
| 21:58 |
hmmmm |
1). expand !! the size of param2 to 16 or possibly 24 bits |
| 21:58 |
hmmmm |
when spreading light, always increase the light amount |
| 21:58 |
hmmmm |
have the actual lighting value be log(param2) * some factor |
| 21:59 |
hmmmm |
the benefit to this is that unspreading light is trivial, all you'd need to do is spread to each node as if you were lighting except subtract the light contribution amount from each param2 |
| 22:00 |
hmmmm |
the huge benefit to this is that you can have light spread farther than 15 nodes |
| 22:00 |
hmmmm |
unspreadLight also becomes much faster because it's conceptually easier to calculate |
| 22:01 |
hmmmm |
2). calculate light only while making meshes |
| 22:02 |
hmmmm |
this removes the need for param2 entirely, and allows RGB light |
| 22:02 |
hmmmm |
the disadvantage is that you can never have light spread greater than the size of a mapblock |
| 22:02 |
hmmmm |
and, of course, when you're making the mapblock mesh you'd need to have all mapblock neighbors loaded as well |
| 22:02 |
nore |
that's an important problem... |
| 22:03 |
Wayward_One |
i like that idea |
| 22:03 |
nore |
about option 1, if you make > 15 nodes radius, won't update_light be slow? |
| 22:03 |
hmmmm |
update_light is always slow. |
| 22:03 |
nore |
I mean, very slow |
| 22:04 |
nore |
if you need to update (2*20)^3 nodes when placing a torch, it's a lot |
| 22:04 |
hmmmm |
it probably shouldn't be too bad since the current implementation can be optimized |
| 22:04 |
nore |
indeed |
| 22:04 |
hmmmm |
it's the implementation that's slow, since unspreadLight needs to keep a set of light sources |
| 22:04 |
hmmmm |
when I optimized lighting for map generation, I was able to remove that since spreading light doesn't require that |
| 22:05 |
nore |
btw, one thing I wanted to do about lighting if ever it is reworked: change day/night into artificial/sunlight |
| 22:05 |
nore |
that makes half as much work when updating |
| 22:05 |
hmmmm |
yeah, not only that, but I personally find the entire concept of having separate day/night lightbanks to be useless |
| 22:05 |
nore |
and you can get the raw sunlight value (useful to know whether a node is outside, etc) |
| 22:06 |
hmmmm |
in reality you never use light other than full on during daytime and full off (or full on) during nighttime |
| 22:07 |
nore |
what do you mean, full on/off? |
| 22:08 |
hmmmm |
so that could be an intermediate #3). remove the concept of day/night banks and have a range of 8 bits for light which means you can spread light much more than currently, but nowhere nearly as much as with #1) |
| 22:08 |
|
ancer joined #minetest-dev |
| 22:08 |
hmmmm |
I'm sure there are mods that actually make use of having a range in each day and night lightbank |
| 22:08 |
hmmmm |
but in general the way nodes work are: either they're a light source and stay lit regardless of day or night |
| 22:08 |
hmmmm |
or they're not a light source and their light is 0 at night |
| 22:08 |
nore |
ah, yes |
| 22:09 |
hmmmm |
(or whatever it was from the spread of a light source) |
| 22:09 |
nore |
btw, why did you say that unspreadLight would be faster with 1? |
| 22:09 |
hmmmm |
because it would be |
| 22:10 |
hmmmm |
you wouldn't need to keep track of light sources this way |
| 22:10 |
nore |
yep, but why? |
| 22:10 |
hmmmm |
currently that's how it works |
| 22:10 |
hmmmm |
the idea is to find all the light sources in the path of where the light you're unlighting spread to |
| 22:10 |
hmmmm |
and then find where that spread |
| 22:11 |
nore |
I mean: why wouldn't you need to find those lights with 1? |
| 22:11 |
hmmmm |
here there's no bookkeeping, just plain subtraction of values from a predetermined path of light bounding |
| 22:11 |
hmmmm |
^ |
| 22:11 |
hmmmm |
s/bounding/bouncing |
| 22:11 |
nore |
yep, but there can be overflows then |
| 22:11 |
hmmmm |
the range of the param2 should be high enough so there can't be |
| 22:11 |
hmmmm |
that is a problem that can't really be solved |
| 22:12 |
nore |
btw, sqrt would be more realistic that log2 |
| 22:12 |
hmmmm |
*shrug* i don't know. i haven't tried it, it's just an idea |
| 22:12 |
hmmmm |
either way |
| 22:13 |
hmmmm |
there is a real need for having a greater range of light |
| 22:13 |
nore |
didn't try it either, but it seems to me that physics would say that |
| 22:13 |
nore |
anyway, need to try |
| 22:13 |
nore |
but it looks like a promising idea |
| 22:13 |
hmmmm |
also another minor improvement: torches should be 3d so that you're able to see them lit when not near a wall |
| 22:15 |
Calinou |
3D torches is possible using meshnodes or nodeboxes |
| 22:15 |
Calinou |
no particles or animation |
| 22:15 |
Calinou |
(although animation on nodebox is possible) |
| 22:16 |
hmmmm |
annendum to method #2: we don't absolutely need to have the entire mapblock loaded, but simply their light contribution at the mapblock edge |
| 22:16 |
hmmmm |
that may or may not be a plausible thing to track |
| 22:19 |
hmmmm |
16*6 bytes |
| 22:19 |
hmmmm |
16*6*3 for RGB lights |
| 22:26 |
hmmmm |
how do other more 'graphically advanced' block games do it? |
| 22:27 |
|
Ritchie joined #minetest-dev |
| 22:29 |
Calinou |
hardware lighting? |
| 22:29 |
UnknownSentinel |
Maybe you can look at terasology, it's the only other open source block game I know. |
| 22:29 |
hmmmm |
dynamic lights are a no-go. irrlicht says they're limited to 8 per scene |
| 22:29 |
hmmmm |
i don' know if i am able to run terasology :) |
| 22:30 |
UnknownSentinel |
haha :) |
| 22:30 |
Calinou |
#terasology |
| 22:30 |
exio4 |
I don't think any computer can run terasology with a playable FPS |
| 22:30 |
Calinou |
ask there |
| 22:30 |
Calinou |
I can, exio4 ;) |
| 22:30 |
exio4 |
but you can run it easily |
| 22:31 |
exio4 |
Calinou, which settings? |
| 22:31 |
UnknownSentinel |
Terasology runs better than minecraft with shaders thougH :/ |
| 22:31 |
Wayward_One |
you also might consider manic digger |
| 22:31 |
Calinou |
fairly low ones |
| 22:31 |
exio4 |
the lowest-low settings were kind of decent here too |
| 22:31 |
Wayward_One |
irc.esper.net, #manicdigger |
| 22:31 |
exio4 |
20~ FPS with lowest stuff, but it was blob and what not |
| 22:37 |
hmmmm |
can't run terasology |
| 22:38 |
hmmmm |
http://fpaste.org/165113/42023828/ |
| 22:39 |
exio4 |
psh, that happens when you don't use a systemd-powered system like fedora 20! |
| 22:40 |
Wayward_One |
Manic Digger runs pretty well on my laptop, much better than Terasology |
| 22:40 |
hmmmm |
i thought java ran on anything! |
| 22:42 |
hmmmm |
in any case check this terasology screenshot out: http://blog.movingblocks.net/wp-content/uploads/Bildschirmfoto-2011-06-07-um-21.16.04.png |
| 22:42 |
hmmmm |
is this a really old terasology version? |
| 22:42 |
hmmmm |
regardless, it demonstrates that we won't find our answer here |
| 22:47 |
hmmmm |
this is awesome |
| 22:47 |
hmmmm |
i need an Oracle Account to download a freaking JDK |
| 22:50 |
kahrl |
really? doesn't seem to be the case when I go to http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html |
| 22:51 |
hmmmm |
i need a very specific version |
| 22:51 |
hmmmm |
hehe i got it from a non-oracle website |
| 22:57 |
hmmmm |
we won't find the answer from manic digger either: http://mdgallery.strangebutfunny.net/uploads/b245b97ef29f503c5503be6676cb6c13.png http://mdgallery.strangebutfunny.net/uploads/be6488917a62dc602e988c0cdd7e2a79.png |
| 22:57 |
hmmmm |
it seems like state-of-the-art block games cannot into alternative light source algorithms |
| 23:04 |
|
Wayward_One joined #minetest-dev |
| 23:32 |
hmmmm |
holy crap |
| 23:33 |
hmmmm |
terasology is even slower than anybody could imagine |
| 23:33 |
hmmmm |
they compress their equivalents of MapBlocks in memory |
| 23:33 |
hmmmm |
a MapBlock is split up into separate arrays for content, sunlight, light, etc. |
| 23:34 |
hmmmm |
sunlight is only white, while 'light' is RGB |
| 23:52 |
|
Wayward_One joined #minetest-dev |
| 23:52 |
|
cib0 joined #minetest-dev |
