• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EDT 08:49
CEST 14:49
KST 21:49
  • Home
  • Forum
  • Calendar
  • Streams
  • Liquipedia
  • Features
  • Store
  • EPT
  • TL+
  • StarCraft 2
  • Brood War
  • Smash
  • Heroes
  • Counter-Strike
  • Overwatch
  • Liquibet
  • Fantasy StarCraft
  • TLPD
  • StarCraft 2
  • Brood War
  • Blogs
Forum Sidebar
Events/Features
News
Featured News
[ASL19] Finals Recap: Standing Tall9HomeStory Cup 27 - Info & Preview18Classic wins Code S Season 2 (2025)16Code S RO4 & Finals Preview: herO, Rogue, Classic, GuMiho0TL Team Map Contest #5: Presented by Monster Energy6
Community News
Flash Announces Hiatus From ASL62Weekly Cups (June 23-29): Reynor in world title form?13FEL Cracov 2025 (July 27) - $8000 live event21Esports World Cup 2025 - Final Player Roster16Weekly Cups (June 16-22): Clem strikes back1
StarCraft 2
General
Program: SC2 / XSplit / OBS Scene Switcher The SCII GOAT: A statistical Evaluation Statistics for vetoed/disliked maps Weekly Cups (June 23-29): Reynor in world title form? PiG Sty Festival #5: Playoffs Preview + Groups Recap
Tourneys
RSL: Revival, a new crowdfunded tournament series Sparkling Tuna Cup - Weekly Open Tournament WardiTV Mondays FEL Cracov 2025 (July 27) - $8000 live event Korean Starcraft League Week 77
Strategy
How did i lose this ZvP, whats the proper response Simple Questions Simple Answers
Custom Maps
[UMS] Zillion Zerglings
External Content
Mutation # 480 Moths to the Flame Mutation # 479 Worn Out Welcome Mutation # 478 Instant Karma Mutation # 477 Slow and Steady
Brood War
General
Player “Jedi” cheat on CSL SC uni coach streams logging into betting site Flash Announces Hiatus From ASL Practice Partners (Official) ASL20 Preliminary Maps
Tourneys
[BSL20] Grand Finals - Sunday 20:00 CET [Megathread] Daily Proleagues Small VOD Thread 2.0 [BSL20] GosuLeague RO16 - Tue & Wed 20:00+CET
Strategy
Simple Questions, Simple Answers I am doing this better than progamers do.
Other Games
General Games
Path of Exile Stormgate/Frost Giant Megathread Nintendo Switch Thread What do you want from future RTS games? Beyond All Reason
Dota 2
Official 'what is Dota anymore' discussion
League of Legends
Heroes of the Storm
Simple Questions, Simple Answers Heroes of the Storm 2.0
Hearthstone
Heroes of StarCraft mini-set
TL Mafia
TL Mafia Community Thread Vanilla Mini Mafia
Community
General
Russo-Ukrainian War Thread US Politics Mega-thread Summer Games Done Quick 2025! Trading/Investing Thread Things Aren’t Peaceful in Palestine
Fan Clubs
SKT1 Classic Fan Club! Maru Fan Club
Media & Entertainment
Anime Discussion Thread [Manga] One Piece [\m/] Heavy Metal Thread
Sports
2024 - 2025 Football Thread Formula 1 Discussion NBA General Discussion TeamLiquid Health and Fitness Initiative For 2023 NHL Playoffs 2024
World Cup 2022
Tech Support
Computer Build, Upgrade & Buying Resource Thread
TL Community
Blogs
Culture Clash in Video Games…
TrAiDoS
from making sc maps to makin…
Husyelt
Blog #2
tankgirl
StarCraft improvement
iopq
Trip to the Zoo
micronesia
Customize Sidebar...

Website Feedback

Closed Threads



Active: 624 users

The Big Programming Thread - Page 913

Forum Index > General Forum
Post a Reply
Prev 1 911 912 913 914 915 1031 Next
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
Last Edited: 2017-10-27 22:47:07
October 27 2017 22:04 GMT
#18241
On October 28 2017 06:07 Blisse wrote:
If it's just passing around the password as a string parameter then it's fine.

If the password is persisted in any way then no.

"data stays inside the app" means lots of things. Just because data is saved to app storage doesn't mean malicious users can't easily access the data.


Right, it's just a string field in an object that doesn't get saved. Thanks for the answer.


On October 28 2017 06:12 tofucake wrote:
salting the hash costs next to nothing and is far more secure than not.

you not wanting to salt means you either don't care (bad), don't think it matters (bad), don't want to do it because you don't understand salt (bad, but not as bad as the others), or "need" every possible byte of storage you can get for some other reason (bad)

tl;dr just fucking salt the password

It's a proof of concept app(not on the app store) and I didn't want to spend the time implementing it, though I probably will now just for learning's sake.

On October 28 2017 02:40 Blitzkrieg0 wrote:
Show nested quote +
On October 28 2017 02:05 WarSame wrote:
My database is on the phone, so they can't use a rainbow table against it I think. I was thinking more of concerns surrounding passing the hashed value around.

Also, I'm using SHA-256, so I should be fine on that end.


The database being on your phone doesn't protect you against a rainbow table. If you have a million users and you hash all the passwords then you're going to have a bunch of duplicate entries in your database as anyone with the same password will have an identical entry after the hash. You add the salt so that each of those will hash to a different value and if an adversary brute forces one password they don't have everyone else's password who was using that same value.

Salts protect the collective. They're useless if the adversary is brute forcing one password. The rainbow table is just a list of what common passwords hash to with various algorithms. By utilizing a salt the adversary has to generate a rainbow table for every salt instead of having a master copy.


Thanks, I'd misunderstood what a rainbow table actually was and your info makes me a lot more wary of it.

EDIT: After more reading, WOW, hashing without salting is awful.
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
phar
Profile Joined August 2011
United States1080 Posts
October 28 2017 01:58 GMT
#18242
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)
Who after all is today speaking about the destruction of the Armenians?
tofucake
Profile Blog Joined October 2009
Hyrule19030 Posts
October 28 2017 03:33 GMT
#18243
On October 28 2017 07:04 WarSame wrote:
Show nested quote +
On October 28 2017 06:07 Blisse wrote:
If it's just passing around the password as a string parameter then it's fine.

If the password is persisted in any way then no.

"data stays inside the app" means lots of things. Just because data is saved to app storage doesn't mean malicious users can't easily access the data.


Right, it's just a string field in an object that doesn't get saved. Thanks for the answer.


Show nested quote +
On October 28 2017 06:12 tofucake wrote:
salting the hash costs next to nothing and is far more secure than not.

you not wanting to salt means you either don't care (bad), don't think it matters (bad), don't want to do it because you don't understand salt (bad, but not as bad as the others), or "need" every possible byte of storage you can get for some other reason (bad)

tl;dr just fucking salt the password

It's a proof of concept app(not on the app store) and I didn't want to spend the time implementing it, though I probably will now just for learning's sake.

Show nested quote +
On October 28 2017 02:40 Blitzkrieg0 wrote:
On October 28 2017 02:05 WarSame wrote:
My database is on the phone, so they can't use a rainbow table against it I think. I was thinking more of concerns surrounding passing the hashed value around.

Also, I'm using SHA-256, so I should be fine on that end.


The database being on your phone doesn't protect you against a rainbow table. If you have a million users and you hash all the passwords then you're going to have a bunch of duplicate entries in your database as anyone with the same password will have an identical entry after the hash. You add the salt so that each of those will hash to a different value and if an adversary brute forces one password they don't have everyone else's password who was using that same value.

Salts protect the collective. They're useless if the adversary is brute forcing one password. The rainbow table is just a list of what common passwords hash to with various algorithms. By utilizing a salt the adversary has to generate a rainbow table for every salt instead of having a master copy.


Thanks, I'd misunderstood what a rainbow table actually was and your info makes me a lot more wary of it.

EDIT: After more reading, WOW, hashing without salting is awful.


Implementing salt is like 3 steps: generate salt, concat with password when hashing, tack it on to the hashed password

you've spent more time saying you don't want to implement it than it would have taken to just implement it
Liquipediaasante sana squash banana
Manit0u
Profile Blog Joined August 2004
Poland17243 Posts
Last Edited: 2017-10-28 11:13:21
October 28 2017 11:12 GMT
#18244
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.
Time is precious. Waste it wisely.
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
Last Edited: 2017-10-29 02:26:47
October 28 2017 17:52 GMT
#18245
On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)

This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that.

On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.


Yeah I did sha-256 which seems secure.
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
October 29 2017 02:26 GMT
#18246
For the app I want to be able to store the user's private ethereum key(if this is stupid/if there is a better way to do it please let me know). I need to be able to store and retrieve, but I want to encrypt it(for security). In order to encrypt/decrypt I need a key. However, that key can't be encrypted(because I need it to do so), so it must presumably be stored in plain text. If I store it in the DB then if they have DB access they can just decrypt. If I store it in a secrets file and they have server access they can just decrypt. What am I missing about this? Is it worth it to encrypt, and if so where do I store this key?

Apologies for my lack of knowledge, but I'm obviously not experience with implementing encryption.
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
Manit0u
Profile Blog Joined August 2004
Poland17243 Posts
October 29 2017 03:14 GMT
#18247
First of all, hashing algorithms like bcrypt make several (as in several hundred or thousand even) passes of hashing. They often also store the salt inside the hash (so you only ever need 1 place to store it).

You really should not roll out your own hashing if there are tried and true algorithms that have been battle tested for years.

As a side note: You should never be able to retrieve someone's password (it indicates a weak hashing algorithm). And you should never play around with it in plain text format or use it much in your classes (there's a reason why in Java you should use char array for passwords instead of String).

Typical password flow:
1. User sets their password, you use bcrypt to hash it and store it like that.
2. To validate user password you compare the hashes (you never decrypt your passwords).
3. If the user forgets the password, they have to reset it as you shouldn't be able to decipher them.
Time is precious. Waste it wisely.
Deleted User 3420
Profile Blog Joined May 2003
24492 Posts
October 29 2017 03:48 GMT
#18248
Can arrays in python only hold basic shit like strings and ints and floats?

If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
October 29 2017 04:01 GMT
#18249
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.

As I think about this more... is the key to encrypt supposed to just be a password the user remembers?
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
Blisse
Profile Blog Joined July 2010
Canada3710 Posts
Last Edited: 2017-10-29 05:21:29
October 29 2017 04:36 GMT
#18250
On October 29 2017 12:48 travis wrote:
Can arrays in python only hold basic shit like strings and ints and floats?

If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?


use a list not an array.

avoid premature optimizations. use a list that points to keys in a map if you want to constrain your list size (don't do this, just use a regular list, you don't need this optimization unless you're hitting your hardware limitations and you know what and why you're doing it, in which case you would know to not do this).
There is no one like you in the universe.
Silvanel
Profile Blog Joined March 2003
Poland4725 Posts
October 29 2017 09:01 GMT
#18251
On October 29 2017 12:48 travis wrote:
Can arrays in python only hold basic shit like strings and ints and floats?

Thats what they say. https://docs.python.org/3/library/array.html

On October 29 2017 12:48 travis wrote:
If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?

Use list? Or perhaps OrderedDict ? I dont know what exactly You want to do and what You need. Anyway i dont think i ever used array in python code oher than during learning.
Pathetic Greta hater.
tofucake
Profile Blog Joined October 2009
Hyrule19030 Posts
October 29 2017 13:01 GMT
#18252
On October 29 2017 02:52 WarSame wrote:
Show nested quote +
On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)

This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that.

Show nested quote +
On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.


Yeah I did sha-256 which seems secure.

why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good"

just use argon2. not using that is negligent
Liquipediaasante sana squash banana
tofucake
Profile Blog Joined October 2009
Hyrule19030 Posts
Last Edited: 2017-10-29 13:04:50
October 29 2017 13:04 GMT
#18253
On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.

As I think about this more... is the key to encrypt supposed to just be a password the user remembers?

no

public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that
Liquipediaasante sana squash banana
Deleted User 3420
Profile Blog Joined May 2003
24492 Posts
October 29 2017 13:21 GMT
#18254
Alright cool

Yeah I just ended up using a 2d list. I wanted to use an array for speed of random access. But it looks like python list still has random access of O(1), which is interesting. So I guess lists in python are arrays as well?
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
October 29 2017 15:01 GMT
#18255
On October 29 2017 22:01 tofucake wrote:
Show nested quote +
On October 29 2017 02:52 WarSame wrote:
On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)

This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that.

On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.


Yeah I did sha-256 which seems secure.

why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good"

just use argon2. not using that is negligent

I knew what a salt does(in general) the whole time. My particular question was whether you needed to do it when you had a SQLite database on each phone. I'd forgotten how rainbow tables worked. I'll look into the other algorithms, but I picked SHA-256 based on some articles I was reading which suggested it.

On October 29 2017 22:04 tofucake wrote:
Show nested quote +
On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.

As I think about this more... is the key to encrypt supposed to just be a password the user remembers?

no

public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that

Right, I don't expect them to memorize their private key. But if our security stuff is based off the assumption that they can get access to our DB, how is it any more secure to encrypt with a keyfile if they could get access to that, too? Are we just making the assumption that if they have access to both of those then we're fucked?
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
phar
Profile Joined August 2011
United States1080 Posts
October 29 2017 16:23 GMT
#18256
General workflows for this sort of thing:

1) blob of whatever you're going to store exists on client
2) use client-known password as key to encrypt
3) send server encrypted blob for storage
4) never decrypt on server
5) new client can retrieve and decrypt blobs they know password for
6) issue any queries you need from client, not server

Or

1) have an existing storage that you can secure on server side
2) use this to store credentials
3) now you can decrypt on server side.


Hard to say without knowing your architecture.


And again a plea to not hook this up for real to anyone's actual money (just doing it as a test thing is fine). Don't roll your own crypto, probably don't roll your own security.
Who after all is today speaking about the destruction of the Armenians?
Hanh
Profile Joined June 2016
146 Posts
October 29 2017 16:27 GMT
#18257
I don't know why you guys say sha-256 isn't safe. I'm not aware of any collision or pre-image attack that is successful but if you have a reference I'm very interested.

If people use a crypto wallet on their phone, they must assume that it can be stolen. That's just trade-off between convenience and security. A wallet can be more secure than cash though. What you do (and any good wallet does), is encrypt the private key with AES256 with another key which is obtained from applying a key stretching algorithm such as pkdf2 on the short password or pin that the user must provide in order to unlock his wallet. After a few failures, your app can even delete all the keys.
The only way for an attacker to get access is to root the phone, grab the encrypted passwords and try every pin number. With a good key stretching algo, he should be occupied long enough for the rightful owner to use his backup on another device and transfer everything to a new account.
Acrofales
Profile Joined August 2010
Spain17971 Posts
October 29 2017 18:12 GMT
#18258
On October 29 2017 12:14 Manit0u wrote:
First of all, hashing algorithms like bcrypt make several (as in several hundred or thousand even) passes of hashing. They often also store the salt inside the hash (so you only ever need 1 place to store it).

You really should not roll out your own hashing if there are tried and true algorithms that have been battle tested for years.

As a side note: You should never be able to retrieve someone's password (it indicates a weak hashing algorithm). And you should never play around with it in plain text format or use it much in your classes (there's a reason why in Java you should use char array for passwords instead of String).

Typical password flow:
1. User sets their password, you use bcrypt to hash it and store it like that.
2. To validate user password you compare the hashes (you never decrypt your passwords).
3. If the user forgets the password, they have to reset it as you shouldn't be able to decipher them.

Is my app secure? I store the passwords in plain text in MySQL database.

This is true. I do exactly that. But security is far far far less important than being able to tell 12-yo kids what password they used to register. And resetting 5-10 passwords every class would just take way too much time.
tofucake
Profile Blog Joined October 2009
Hyrule19030 Posts
October 29 2017 19:58 GMT
#18259
On October 30 2017 00:01 WarSame wrote:
Show nested quote +
On October 29 2017 22:01 tofucake wrote:
On October 29 2017 02:52 WarSame wrote:
On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)

This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that.

On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.


Yeah I did sha-256 which seems secure.

why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good"

just use argon2. not using that is negligent

I knew what a salt does(in general) the whole time. My particular question was whether you needed to do it when you had a SQLite database on each phone. I'd forgotten how rainbow tables worked. I'll look into the other algorithms, but I picked SHA-256 based on some articles I was reading which suggested it.

Show nested quote +
On October 29 2017 22:04 tofucake wrote:
On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.

As I think about this more... is the key to encrypt supposed to just be a password the user remembers?

no

public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that

Right, I don't expect them to memorize their private key. But if our security stuff is based off the assumption that they can get access to our DB, how is it any more secure to encrypt with a keyfile if they could get access to that, too? Are we just making the assumption that if they have access to both of those then we're fucked?

"I temporarily forgot how salt works" is the same as not knowing how salt works. Maybe you learned it before, but you don't know it.

And because keyfiles are stored on disk and not in a database, and have different security. So even if an account is compromised, the keyfile is still safe. You assume both are, but you make it as difficult as possible to get both with 1 attack (e.g., don't store the keyfile in the database)
Liquipediaasante sana squash banana
WarSame
Profile Blog Joined February 2010
Canada1950 Posts
October 29 2017 23:23 GMT
#18260
On October 30 2017 01:23 phar wrote:

And again a plea to not hook this up for real to anyone's actual money (just doing it as a test thing is fine). Don't roll your own crypto, probably don't roll your own security.

But how?!? If I could get away without doing this, and also make it more secure I would love to do that. Or are you talking about just hiring someone for the security side of things?
Can it be I stayed away too long? Did you miss these rhymes while I was gone?
Prev 1 911 912 913 914 915 1031 Next
Please log in or register to reply.
Live Events Refresh
WardiTV European League
12:00
Swiss Groups Day 2
WardiTV744
TKL 431
Liquipedia
FEL
12:00
Cracov 2025: Qualifier #2
IndyStarCraft 310
CranKy Ducklings79
Liquipedia
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
TKL 431
IndyStarCraft 310
Rex 119
MindelVK 39
StarCraft: Brood War
Sea 11032
Calm 9514
Rain 7180
Bisu 2849
Horang2 2292
Hyuk 1365
Jaedong 1317
Shuttle 516
Rush 430
EffOrt 300
[ Show more ]
Stork 282
Leta 270
Last 240
PianO 210
Mini 206
ToSsGirL 156
Hyun 140
ZerO 95
Movie 79
hero 55
TY 53
Sea.KH 41
JYJ40
Killer 35
JulyZerg 29
ajuk12(nOOB) 22
HiyA 20
GoRush 19
Free 19
zelot 19
Terrorterran 18
Sacsri 17
Barracks 16
Icarus 6
ivOry 2
Stormgate
NightEnD21
Dota 2
qojqva3057
XcaliburYe452
canceldota102
League of Legends
singsing2904
Counter-Strike
x6flipin739
zeus453
Heroes of the Storm
Khaldor315
Other Games
Gorgc2822
B2W.Neo1375
DeMusliM540
Happy390
Fuzer 389
crisheroes369
Pyrionflax337
XaKoH 263
Hui .243
RotterdaM147
ArmadaUGS70
KnowMe60
ZerO(Twitch)17
Organizations
StarCraft: Brood War
CasterMuse 25
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
sctven
[ Show 14 non-featured ]
StarCraft 2
• StrangeGG 38
• iHatsuTV 6
• AfreecaTV YouTube
• intothetv
• Kozan
• IndyKCrew
• LaughNgamezSOOP
• Migwel
• sooper7s
StarCraft: Brood War
• BSLYoutube
• STPLYoutube
• ZZZeroYoutube
Dota 2
• WagamamaTV749
• Ler42
Upcoming Events
BSL: ProLeague
5h 11m
Dewalt vs Bonyth
Replay Cast
1d 11h
Sparkling Tuna Cup
1d 21h
WardiTV European League
2 days
The PondCast
2 days
Replay Cast
3 days
RSL Revival
3 days
ByuN vs SHIN
Clem vs Reynor
Replay Cast
4 days
RSL Revival
4 days
Classic vs Cure
FEL
5 days
[ Show More ]
RSL Revival
5 days
FEL
5 days
FEL
6 days
Sparkling Tuna Cup
6 days
RSL Revival
6 days
Liquipedia Results

Completed

BSL 2v2 Season 3
HSC XXVII
Heroes 10 EU

Ongoing

JPL Season 2
BSL Season 20
Acropolis #3
KCM Race Survival 2025 Season 2
CSL 17: 2025 SUMMER
Copa Latinoamericana 4
Jiahua Invitational
Championship of Russia 2025
RSL Revival: Season 1
Murky Cup #2
BLAST.tv Austin Major 2025
ESL Impact League Season 7
IEM Dallas 2025
PGL Astana 2025
Asian Champions League '25
BLAST Rivals Spring 2025
MESA Nomadic Masters
CCT Season 2 Global Finals
IEM Melbourne 2025

Upcoming

2025 ACS Season 2: Qualifier
CSLPRO Last Chance 2025
2025 ACS Season 2
CSLPRO Chat StarLAN 3
K-Championship
uThermal 2v2 Main Event
SEL Season 2 Championship
FEL Cracov 2025
Esports World Cup 2025
StarSeries Fall 2025
FISSURE Playground #2
BLAST Open Fall 2025
BLAST Open Fall Qual
Esports World Cup 2025
BLAST Bounty Fall 2025
BLAST Bounty Fall Qual
IEM Cologne 2025
FISSURE Playground #1
TLPD

1. ByuN
2. TY
3. Dark
4. Solar
5. Stats
6. Nerchio
7. sOs
8. soO
9. INnoVation
10. Elazer
1. Rain
2. Flash
3. EffOrt
4. Last
5. Bisu
6. Soulkey
7. Mini
8. Sharp
Sidebar Settings...

Advertising | Privacy Policy | Terms Of Use | Contact Us

Original banner artwork: Jim Warren
The contents of this webpage are copyright © 2025 TLnet. All Rights Reserved.