Old 17th September 2011, 14:04   #1
SUNSCREEN99
Junior Member
 
Join Date: Sep 2011
Posts: 21
just something for future releases..

implement the following:

code:

/* dumb ass source gone wrong or we are possibly being attacked */
If (!ascii(passwd) || !ascii(username)) { boot_source_connection(); }

If (userlength >32 || passwd > 32) { boot_source_connection(); } /* more than fair */

SUNSCREEN99 is offline   Reply With Quote
Old 17th September 2011, 14:19   #2
jaromanda
Forum King
 
Join Date: Jun 2007
Location: Under the bridge
Posts: 2,289
Quote:
Originally Posted by SUNSCREEN99 View Post
implement the following:

code:

/* dumb ass source gone wrong or we are possibly being attacked */
If (!ascii(passwd) || !ascii(username)) { boot_source_connection(); }

If (userlength >32 || passwd > 32) { boot_source_connection(); } /* more than fair */

not sure what language uses uppercase I for If

anyway ... why not allow passwords greater than 32 characters? I routinely use 50 or more characters for passwords

also, if long usernames/passwords are causing issues, the above code will do nothing to stop those issues

Is it just me or are shoutcast users getting dumber?
jaromanda is offline   Reply With Quote
Old 17th September 2011, 14:56   #3
SUNSCREEN99
Junior Member
 
Join Date: Sep 2011
Posts: 21
Does this look like my Integrated development environment? er no it looks like a forum for winamp? where i have to type into some little text input on a html form .. not my development editor.. so there for If i want to write IF or if or iF, i will, to make a suggestion.

At present its blatantly clear there is no cceck on that ..
Soo don't bother trying to auth GIBBERISH is all am saying.. which is what it does now

So Ok Then set the limit it to 50 then .. thats preferable to what ever they have the max as now
its aleast 100! really secure code would take the longest passwd and set that as the at runtime anyway but what ever..

yes that code when implemented correctly, will do something .. stop client attacks.. save machine resources and network bandwidth.


thanks.
SUNSCREEN99 is offline   Reply With Quote
Old 17th September 2011, 16:02   #4
DrO
 
Join Date: Sep 2003
Posts: 27,873
ok i must be missing something from the initial post (which will teach me to get up at silly o'clock to watch rugby)... implement for what, the Transcoder, the DNAS, all 3rd party SHOUTcast sources?

SHOUTcast passwords have always been based on a check for what was set in the config for the tool(s) being used and will generally only accept ascii passwords of any length anyway as long as it will fit in the http header. the only variance is that transcoder dj passwords reserve the use of : . so if someone wants to use something outside of a-z,A-Z,0-9 then they can do so.

Quote:
yes that code when implemented correctly, will do something .. stop client attacks.. save machine resources and network bandwidth.
didn't see that when i first started to reply, if that's what you're getting at, then there's not much which can be done since anything which gets through as a valid source connection will be processed until something does not match up, otherwise how else can it be checked that it's valid or not if it's claiming to be a source?

if it's an issue for you, then only 'portbase' should be opened and a local source should be used instead - since all v1 sources connect on portbase+1. otherwise there's not much which is going to change unless you can make every single SHOUTcast setup be updated to a newer DNAS / Transcoder version along with all sources which were made more 'secure' (though i don't see limiting password lengths, etc is a good idea).

-daz
DrO is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Shoutcast > Shoutcast Technical Support

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump